Что должен делать ваш тестировщик / Habr

Привет, Хабр! Меня зовут Евгений Сабиров, я развиваю тестировщиков в Точка Банк. Много лет занимаюсь подготовкой докладчиков к конференциям, грейдирую и собеседую тестировщиков. И за это время не мог не заметить, насколько размыта зона ответственности этой роли: где-то тестировщик отвечает за коммуникацию с клиентами и проработку дизайна, где-то — только за написание автотестов, при этом про анализ требований даже не вспоминают. Такая размытость сама по себе нормальна: разным командам нужны разные навыки.

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

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

О чём в статье не будем говорить

Речь в этом тексте пойдёт только о контроле качества. Об обеспечении качества можно поговорить в другой статье. А о том, что работа тестировщика (контроль качества) и обеспечение качества — разные вещи, я говорю здесь и здесь.

Цель тестирования

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

• Цель тестирования — выпустить качественный продукт.
  Это задача всей команды, а не только тестирования.

• Цель тестирования — найти дефекты.
  Смысл этой формулировки разбивается об вопрос: «Если на тестировании не найдены дефекты, то цель тестирования не выполнена?»

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

В чём же тогда цель тестирования?

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

Цель тестирования – информирование ответственных за выпуск ПО о соответствии продукта предъявляемым требованиям.

Хороший тестировщик должен фокусироваться именно на этой цели и для ее достижения делать следующее: 

1. Тестировать новую функциональность.

2. Проверять, что не сломались функциональности, работавшие раньше.

3. Сообщать о результатах тестирования заинтересованным лицам — команде, продакту, лидам.

А теперь разберём подробнее от простого к сложному. По тексту можно даже отследить рост ответственности тестировщика от младших к старшим грейдам.

Тестирование новой функциональности

Чтобы качественно протестировать новую функциональность, хороший тестировщик

• Пишет тест-кейсы:

  • пользуется техниками тест-дизайна;

  • составляет тестовую модель (определяет, где, что и каким образом проверять).

• Выполняет проверки по тест-кейсам:

  • знает, для каких проверок какой инструмент использовать: например, для тестирования API — Postman, а для тестирования UI — PixelPerfect или DevTools.

  • умеет пользоваться этими инструментами;

  • знает, как оптимально решать задачу проверки — например, пользуется переменными и скриптами в Postman, знает, на что обращать внимание при просмотре запросов в DevTools и т.д.

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

• Тестирует требования.

• Пишет тест-кейсы до разработки.

• Стремится к тому, чтобы обратная связь от тестирования была максимально быстрой — например, с помощью автотестов, которые написаны до или параллельно с разработкой фичи.

Регрессионное тестирование 

Релиз без регресса — это лотерея. Поэтому перед каждым релизом нужно проводить регрессионное тестирование, чтобы убедиться, что внесение изменений в код не сломало то, что работало раньше. Качественное тестирование не проводится «по памяти», поэтому хороший тестировщик:

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

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

• Инициирует автоматизацию регрессионного тестирования там, где это рентабельно

Формулировка неслучайно выбрана именно такая, ведь важно помнить, что автоматизацией тестирования может заниматься не только тестировщик. Честно говоря, человек, который умеет писать код (программист), справляется с задачей автоматизации тестирования куда лучше, чем тестировщик.

Что касается слова «рентабельно» — важно помнить, что не всегда автоматизация приводит к удешевлению тестирования. Помимо затрат на создание автотестов, нужно помнить и о затратах на их поддержку. Писать автотесты на функциональность, в которой планируются частые функциональные изменения, вероятнее всего, плохая идея. 

Поэтому так важно сравнивать стоимость ручного тестирования с расходами на автоматизацию, считать ROI автоматизации тестирования.

Помимо автоматизации затраты на регресс можно оптимизировать и другими способами — например, проводя импакт-анализ или ротацию тест-кейсов.

Отчёт о результатах тестирования 

Этот пункт обязанностей тестировщика пусть и формальный, но очень важный. Для начала тестировщику нужно знать ответы как минимум на два вопроса – кому предоставлять отчёт о результатах тестирования и какая информация в нём должна быть.

Я рекомендую включать в отчёт о тестировании следующую информацию: 

• сведения о выполненных требованиях (зелёные тесты);

• информацию об обнаруженных дефектах (красные тесты);

• данные о требованиях, выполнение которых не удалось подтвердить (непроведённые тесты).

Чем тестировщик НЕ должен заниматься

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

Второе, не менее важное — тестировщик не принимает решения о том, можно ли релизиться. Лидеры команды не должны по умолчанию перекладывать эту ответственность на тестировщика. Да, внутри команды можно об этом договориться, но, как и в предыдущем пункте, принимать решение должен тот, у кого есть и нужные компетенции, и достаточная информация. В большинстве случаев тестировщик не располагает ни тем, ни другим. В продуктовых командах логичнее всего, если решение о релизе с дефектами принимает Product Owner — именно он лучше всех понимает, принесёт ли фича больше пользы, чем вреда от дефекта.

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

Итого

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

Важно помнить: тестировщик не «сторож релиза» и не «поставщик багов». Его задача — быть источником информации, который помогает делать разработку предсказуемой, дешёвой и быстрой.

Идеальный процесс контроля качества строится именно вокруг этого:

1. Требования тестируются ещё до разработки.

2. Проверки новых функций проводятся быстро и максимально рано.

3. Регрессионное тестирование прогнозируемо по времени и усилиям, оптимизируется за счёт автоматизации и импакт-анализа.

4. Отчёт о тестировании полезен для ролей, принимающих решение о релизе.

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

Подготовка и проведение тест-кейсов

Разребем, что важно учесть при подготовки и проведении тест-кейсов. 

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

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

• В процессе тестирования не забывай быстро давать обратную связь. Разработчик, который получит баг сразу после завершения задачи (пока контекст свеж), исправит его гораздо быстрее, чем после переключения на новую задачу. 

• Не забывай использовать corner-кейсы. Если ты их подготовишь и отдашь разработки еще до того, как они возьмут задачу в работу, это сильно их ускорит. Глядя на такие тесты разработчики будут понимать, что именно им нужно учесть, чтобы готовые тесты точно прошли. 

• По-хорошему, вместо написания ручных тест-кейсов — или параллельно с ними — можно сразу писать автотесты. Представь: к завершению разработки у тебя уже готовы автотесты, проверяющие написанный программистом код. Схема работает следующим образом: функциональность и автотесты для неё создаются параллельно. Когда разработка окончена, код пушат в main-ветку, запускают автотесты, и, если они проходят,  — релиз можно деплоить. Это и есть Continuous Delivery/Continuous Deployment. Так вы вообще избежите ручного тестирования: всё будет покрыто автотестами, которые постоянно запускаются на актуальном коде и гарантируют безопасный деплой.

Как организовать процессы, чтобы повысить четкость и прозрачность своей работы

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

Первое — требования

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

Второе — время на написание тест-кейсов

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

Третье — регресс

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

Четвертое — учитывай время на дефекты как в новом функционале, так и в регрессе

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

Пятое — отчетность

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

Выводы 

Для достижения максимальной прозрачности и результативности своей работы нужно:

1. Чётко понимать цель: твоя роль — информировать команду и лиц, принимающих решения (ЛПР), о реальном состоянии продукта.

2. Систематизировать процессы:

   • активно участвовать в анализе требований на ранних этапах;

   • готовить тест-кейсы до начала разработки/тестирования (включая corner-кейсы);

   • планировать и оптимизировать регрессионное тестирование (импакт-анализ, автоматизация);

   • чётко планировать время на регресс, перетесты и отчётность.

3. Обеспечивать прозрачность:

   • Предоставлять понятные и своевременные отчеты ЛПР о результатах тестирования (статус требований, найденные дефекты, риски).

   • Формировать чёткие баг-репорты.

   • Документировать процессы (тест-кейсы, тест-план регресса). 

4. Договариваться о правилах: четко определять, кто и на каких основаниях принимает решение о релизе. Твоя роль в этом — предоставить данные, а не принимать решение (если нет явных, согласованных правил блокировки).

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