Home

Автор: Ноэми Феррера (Noemi Ferrera)
Оригинал статьи
Перевод: Ольга Алифанова

Я заметила, что во множестве компаний, в которых разработка и тестирование разделены, тестировщики чересчур доверяют разработчикам. Даже там, где разработка сильно интегрирована с тестированием, это может вылиться в пропущенные тесты, некоторые из которых могут быть критичными для поиска важных багов в разрабатываемом ПО.

Один из явных примеров такой ситуации связан с CI/CD. Обычно это настраивается администратором или DevOps. Тут очень важно подключить к процессу тест-эксперта этой области, потому что он умеет проектировать нужные для валидации билдов автоматизированные тесты. Я видела варианты, где тестирования не было вообще, или же была группа недостаточных или нерелевантных тестов.

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

Расскажу историю, как я чересчур доверилась опытному разработчику: на стейдж-окружении был очевидный баг. Я создала репорт о нем. Кто-то другой завел дубликат. Мы опаздывали к релизу. Я сказала, что не могу дать отмашку, пока этот баг присутствует.

Назначенный на фичу разработчик вызвал менеджера проекта и меня, и оба они пытались убедить меня передумать. Я внятно описала риск. Он сказал, что на баг вряд ли кто-то наткнется, и у него нет времени его исправлять. Я поверила ему – я была всего лишь джуниором, а он был сениором и дольше работал в компании. Мои инстинкты шептали, что сеньорство не делает его провидцем, но я все равно сказала "ОК, я согласна, если вы меня в случае чего прикроете". Он уверил меня в этом и согласился, сказав, что возьмет на себя всю ответственность в случае чего. Это нигде не фиксировалось письменно.

Когда на ошибку наткнулись пользователи на проде, и ПМ, и разработчик обвинили меня. Письменно. Оба. Мой менеджер винил меня. Все они говорили, что я упустила очевидный баг. Я объяснила, что на самом деле произошло, предоставив логи дефекта, который все еще был открыт, как и его дубликат – и все нужные люди были об этом проинформированы. Менеджер вызвал меня в офис. Он сказал, что я не должна была соглашаться, и мое поведение было непрофессиональным, потому что "мы не должны искать виноватого". Иными словами, я должна была взять на себя вину, даже не пытаясь объяснить происходящее. Он не прислушался ко мне, и это повлияло на мое ревью, которое состоялось через неделю.

Он сказал, что я получила два очень плохих "анонимных" ревью (сложно догадаться, кто их автор, правда?), а остальные, хоть и хорошие, были нерелевантными.

В начале этого же ревью-периода я нашла фикс для очень важного дефекта другой команды, который стоил компании больших денег, и менеджер этой команды сказал, что если бы дефект исправил разработчик, его бы сразу повысили. Я нашла этот фикс – но это ничего не значило.

Даже из самых плохих ситуаций можно извлечь пользу, неважно, произошли ли они с вами или с кем-то другим. Что я вынесла из этой:

• Следуйте своим инстинктам – если что-то вам кажется важным, настаивайте на этом. Не доверяйте коллегам слепо лишь на основании их опыта и ваших хороших отношений. Знайте себе цену, знайте, что вы даете компании: я решила довериться разработчику на основании только лишь его опыта после того, как разобралась с проблемой, над которой безуспешно бились опытные разработчики.
• Хорошо, если вы пришли к согласию, но лучше фиксировать это письменно, чтобы все вспомнили и пересмотрели этот факт позднее.
• Если вам надо выпускать фичу с дефектом – ОК, но планируйте для худшего сценария и думайте, что делать, чтобы встретившиеся с багом пользователи пострадали как можно меньше.
• И, наконец, если ваш менеджер вас не поддерживает, подумайте об увольнении. Лидеры и менеджеры должны помогать вам расти и учиться, бросать вам вызов, вдохновлять вас, но ни в коем случае не унижать. Вы должны ощущать, что они прикладывают усилия, чтобы понять вас и защитить – как минимум, я делаю именно так, когда руковожу или тренирую.

Надеюсь, эта история поможет вам, если вы окажетесь в похожей ситуации. Помните, что каждое препятствие может вас чему-то научить.

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

Обсудить в форуме