Rivalry2

HTML Diff

0 added 0 removed

Original 2026-01-01

Modified 2026-02-21

1 <a>#статьи</a>

2 <ul><li>9 июн 2020</li>

3 <li>0</li>

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

5 vlada_maestro / shutterstock

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

7 <a></a>об авторе

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

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

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

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

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

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

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

15 <ul><li>Идеальный product-manager создает максимально детализированный спек продукта и передаёт его идеальному дизайнеру.</li>

16 <li>Идеальный дизайнер, в свою очередь, рисует продуманные до мельчайших деталей UI- и UX-мокапы.</li>

17 <li>Техлид компании распределяет работу между разработчиками.</li>

18 <li>Идеальные разработчики в кратчайшие сроки (и, разумеется, без багов) имплементируют спек, тщательно проверяя и документируя свой код.</li>

19 <li>Идеальные QA-инженеры пишут тест-план на основе детального спека и сверяются с UI-диаграммами, полученными от дизайнера.</li>

20 <li>Проверка продукта становится тривиальной задачей и он выходит в продакшн.</li>

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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