Почему разрабатывать продукты без тестировщика — плохая идея

Иногда разработчики и даже лиды считают, что тестировщик не нужен: они и сами могут все проверить и пофиксить. QA кажется им лишним звеном между продом и программистом, которое тратит время на бессмысленное прокликивание кнопок.

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

Мария Смирнова

Руководитель отдела тестирования

Как доказать, что тестировщик — полезный специалист

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

Но нам удалось его переубедить, что мы проверяем работоспособность, и если что-то не работает, это не мы сломали, это где-то недоработали.

Вот какие аргументы мы приводили.

Тестировщик помогает нейтрализовать человеческий фактор

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

Был случай, когда разработчики не заметили ошибку в логике переводов, и в итоге клиентам выдавали лишние 10 копеек. Вроде мелочь, но потом она складывается в большую сумму, которую теряет компания. Баг незаметный, но критичный, разработчики получили много жалоб от менеджеров, которые его обнаружили. Будь на проекте тестировщик, который организовал бы хороший список тестов, всем было бы спокойнее.

Освобождает время, которое можно потратить на код, а не на поиск ошибок

Тестирования силами разработчиков бывает достаточно до тех пор, пока багов с прода не наберется слишком много. Тогда программисты отвлекаются от текущих задач и выполняют срочно-таски. В итоге разработчики постоянно латают там, где сломалось, а проект стоит на месте.

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

Экономит деньги компании, отлавливая баги на ранних этапах

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

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

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

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

Он следит за тем, чтобы этапы создания приложения не погрузились в хаос

На одном из наших крупных проектов процесс тестирования не был отлажен. Почти все доработки выкатывались сразу, а на тестовый стенд сливали абсолютно все, что хотят улучшить в будущем. Из-за этого туда нельзя было залить критическую доработку, фичи не матчились друг с другом. Работа строилась в режиме «вылили на прод, там что-то сломалось, починили», и так по кругу. При этом нужно было выполнять и новые задачи. Многие из-за этого выгорали.

Вдобавок не было контакта между командами: ни установленных созвонов, ни общей базы данных по проекту. Конечно, разбираться с этим должен не тестировщик, а менеджер, но когда люди работают в аврале, нужен взгляд со стороны, подсказка, как перестроить работу. Тестировщик может взять на себя эту ответственность и всех разгрузить.

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

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

Так, работа команды стала более структурированной.

Что в итоге

Если тестировщика на проекте нет, то все может слететь, особенно в сложных системах, где много взаимосвязанных инструментов. Разработчики смотрят локально на свой кусок кода: в одном месте все может быть идеально даже после автотестов. А как только обновление объединяется с остальным проектом, все ломается в неожиданном месте.

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