Пытался протиснуться с фичой поперёк релизного процесса, но в итоге всё равно пошёл тем же путём, что и все остальные

Что делать, если после тестирования на проде нашлись баги? 🪲🐞

Ситуация, в которой может оказаться любой тестировщик. Вы выполнили регресс, отдали продукт, а затем в нем обнаружились баги. Пользователи стали заводить обращения с проблемами в ключевом функционале. Разберем эту неприятную ситуацию.

1️⃣ Стоит разделить чувство вины и ответственность. Не нужно себя винить и сомневаться в своей компетентности. Это не продуктивно и точно никак не поможет вам в работе. Ошибки допускают все. Как минимум, кроме вас их допустили разработчики, и они вылились в дефекты, которые не были обнаружены в ходе тестирования.

Но и списывать это на принцип "исчерпывающее тестирование невозможно и баги будут находиться всегда" тоже не стоит. Нужно признать, что причиной пропуска багов в ключевом функционале является наличие проблем в процессе тестирования.

2️⃣ Важна не ошибка, а реакция на нее. Подобная ситуация - это сигнал к тому, что имеющиеся тесты не справляются со своей задачей. Поэтому нужно разобраться почему.

Исследуйте баги, попробуйте их локализовать и выявить причины возникновения. Затем соотнесите их с имеющимися в регрессе тестами, которые покрывают требования к фиче, где возникли проблемы. Причины, почему тесты не позволили обнаружить баги, могут быть разными:
🔺 проблемная область в целом не тестировались
🔺 нет достаточного понимания работы фичи, из-за чего требования к ней покрыты не полностью
🔺 тесты есть, но тестовые данные в них отличаются от реальных и выявить проблему не смогли
🔺 ошибка у пользователя возникает на другом окружении, на котором тесты не проводились
🔺 ...

Затем, когда причины будут ясны, принимайте соответствующие меры. Изучите дополнительно работу компонента, где обнаружились баги, восполнив тем самым пробелы в знаниях и понимании ее работы. Пересмотрите и модифицируйте уже имеющиеся тесты, с учетом полученных данных. И обязательно дополните набор тестами проблемных кейсов, которые будете выполнять для проверки исправлений и последующих регрессий.

Если вы заинтересованы в профессиональном росте и в улучшении качества продукта, используйте подобную ситуацию как реальную обратную связь, касающуюся эффективности ваших тестов и реагируйте, предпринимая адекватные меры для ее улучшения.

Как обычно LinkedIn рекомендует мне замечательные материалы.

Сегодня делюсь с вами чит-листом с командами не только для SQL СУБД, но и NoSQL.

Красочный, с учетом специфики разных систем. Вам понравится.

Автор