Почему вам не обойтись без QA и зачем вообще нужны тестировщики
2026-02-21 00:32 Diff
https://skillbox.ru/media/code/pochemu_vam_ne_oboytis_bez_qa_i_zachem_voobshche_nuzhny_testirovshchiki/

#статьи

  • 9 июн 2020
  • 0

Зачем в команде тестировщик, если проверить продукт могут сами программисты и менеджеры? Оказывается, всё не так однозначно.

 vlada_maestro / shutterstock

За последние 17 лет прошёл весь путь от начинающего программиста до CTO в крупных проектах. Специализируется на стартапах и работе с удалёнными командами.

об авторе

За последние 17 лет прошёл весь путь от начинающего программиста до CTO в крупных проектах. Специализируюсь на стартапах и работе с удалёнными командами.

Как-то раз ко мне обратился руководитель одного криптовалютного стартапа и попросил проконсультировать по проверке их сети перед запуском первого публичного тестнета. Кроме главы компании на первой встрече присутствовали три разработчика. На мой вопрос: «А где же ваш QA-инженер, ведь речь пойдёт именно о тестировании?» — они переглянулись и сказали, что у них нет QA, а разработчики сами проверяют свой код.

Эта ситуация встречается довольно часто. Не только стартапы, но и большие компании иногда не видят необходимости в QA-отделе, отдавая его задачи разработчикам или максимально автоматизируя. Я хочу рассказать, почему это не самая лучшая идея и как я лично отношусь к роли QA в организации.

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

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

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

Чтобы понять эту мысль, давайте разберём, как в теории должен происходить процесс разработки.

  • Идеальный product-manager создает максимально детализированный спек продукта и передаёт его идеальному дизайнеру.
  • Идеальный дизайнер, в свою очередь, рисует продуманные до мельчайших деталей UI- и UX-мокапы.
  • Техлид компании распределяет работу между разработчиками.
  • Идеальные разработчики в кратчайшие сроки (и, разумеется, без багов) имплементируют спек, тщательно проверяя и документируя свой код.
  • Идеальные QA-инженеры пишут тест-план на основе детального спека и сверяются с UI-диаграммами, полученными от дизайнера.
  • Проверка продукта становится тривиальной задачей и он выходит в продакшн.

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

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

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

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

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

От редакции: На наш взгляд не стоит говорить о QA-специалистах как о некой единой группе. Во-первых, в сложных проектах обычно есть системный архитектор, который видит проект в целом. А во-вторых, у тестировщиков может быть разный уровень задач. Часто тестирование сводится к прогону типовых и небольшого количества нетиповых пользовательских сценариев. Понятно, что занимающиеся этим специалисты не будут стоить дорого. Но такого шаблонного тестирования зачастую достаточно (особенно для обновляющихся продуктов, а не создаваемых с нуля) либо оно снимает основной объём проблем. Нам кажется, что потому профессия и не становится более заметной на рынке, что основной объём задач тестирования покрывается, так сказать, «минимальными версиями специалистов».

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

Это очень важный момент. Если в организации нет QA-отдела, для того чтобы понять, как ведёт себя конкретный элемент системы, надо найти разработчика, который его писал, и надеяться на то, что он помнит, что и как он делал пару месяцев назад. Это в том случае, если он всё ещё работает в компании.

От редакции: Отметим, что чаще всего документация, независимо от этапа разработки, пишется на основе кода, а тесты — уже на основе документации. Далее, в зависимости от уровня компетентности тестировщиков, документация может пополняться. Утверждать, что тестировщик берёт код, тестирует и на основе своих опытов пишет доки, — всё же слишком категорично.С утверждением «если нет QA, то и не понять, как ведёт себя элемент» тоже можно поспорить. Правила разработки требуют, чтобы программисты комментировали и документировали код. Если код не задокументирован — проблема не в отсутствии QA-службы, а в том, что весь процесс разработки построен криво и неуправляемо.

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

Но и это ещё не всё. Тестировщик обязан заметить, если каким-то функционалом неудобно пользоваться. Что он непонятен или не соответствует существующим стандартам. Нужно уметь думать как пользователь и смотреть на продукт его глазами и свободно ориентироваться в предметной области продукта.

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

Если бы Супермен работал в IT, он был бы тестировщиком.

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

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

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

«У нас все проверяют продукт, даже CEO занимается этим», — часто слышу я. Прекрасно! Но CEO не всегда может правильно открыть баг в системе, перепроверить его, когда он будет закрыт, и проследить, что именно входит в каждый конкретный релиз. Разработчики сами проверяют свой код? Несомненно, так и должно быть. Но просить программиста найти то, о чём он не подумал на стадии написания кода, — по меньшей мере чересчур оптимистично. У вас автоматизированы QA-процессы? Прекрасно. Это может упростить жизнь тестировщику, но никакое автотестирование не сможет заменить человека.

В конце концов, именно тестировщики несут ответственность за качество продукта, отсюда и название этой профессии — Quality Assurance. Не надо забывать, что именно они и есть та последняя линия обороны, которая стоит между вами и большими проблемами.

Бесплатный курс по Python ➞
Мини-курс для новичков и для опытных кодеров. 4 крутых проекта в портфолио, живое общение со спикером. Кликните и узнайте, чему можно научиться на курсе. Смотреть программу