Привет, Хабр! Меня зовут Евгений Сабиров, я развиваю тестировщиков в Точка Банк. Много лет занимаюсь подготовкой докладчиков к конференциям, грейдирую и собеседую тестировщиков. И за это время не мог не заметить, насколько размыта зона ответственности этой роли: где-то тестировщик отвечает за коммуникацию с клиентами и проработку дизайна, где-то — только за написание автотестов, при этом про анализ требований даже не вспоминают. Такая размытость сама по себе нормальна: разным командам нужны разные навыки.
Проблемы начинаются тогда, когда тестировщик меняет работу или сталкивается с грейдами внутри компании. То, что ценилось в одной команде, может оказаться невостребованным в другой. Возникает естественный вопрос: какие знания и навыки должен иметь тестировщик, чтобы быть полезным в любой более-менее типовой команде?
В этой статье я попробую очертить роль тестировщика, выделить её ключевые обязанности и показать, как эти активности вписываются в процесс разработки. Это поможет самим тестировщикам яснее понимать ценность своей работы, а руководителям — более чётко распределять зоны ответственности внутри команды.
О чём в статье не будем говорить
Речь в этом тексте пойдёт только о контроле качества. Об обеспечении качества можно поговорить в другой статье. А о том, что работа тестировщика (контроль качества) и обеспечение качества — разные вещи, я говорю здесь и здесь.
Цель тестирования
Начать имеет смысл с главного — цели тестирования. Насчёт неё есть несколько типичных заблуждений, вот самые популярные из тех, что слышал:
Цель тестирования — выпустить качественный продукт.
Это задача всей команды, а не только тестирования.Цель тестирования — найти дефекты.
Смысл этой формулировки разбивается об вопрос: «Если на тестировании не найдены дефекты, то цель тестирования не выполнена?»Цель тестирования — не допустить релиза с дефектами.
Бытует мнение, что если тестировщик нашёл дефект, то он должен предпринять все возможные действия, чтобы не пустить релиз в прод. Однако, дефект дефекту рознь, и с некоторыми из них релизиться можно и даже нужно. По умолчанию тестировщик не обладает достаточной информацией о том, с какими дефектами можно релизиться, а с какими нет.
В чём же тогда цель тестирования?
Она заключается в предоставлении команде и бизнесу — лицам, принимающим решения о выпуске — информации о качестве продукта. Под качеством в данном случае подразумевается степень соответствия действительного результата запланированному. Развёрнутая формулировка звучит так:
Цель тестирования — информирование ответственных за выпуск ПО о соответствии продукта предъявляемым требованиям.
Хороший тестировщик должен фокусироваться именно на этой цели и для её достижения делать следующее:
Тестировать новую функциональность.
Проверять, что не сломались функциональности, работавшие раньше.
Сообщать о результатах тестирования заинтересованным лицам — команде, продакту, лидам.
А теперь разберём подробнее от простого к сложному. По тексту можно даже отследить рост ответственности тестировщика от младших к старшим грейдам.
Тестирование новой функциональности
Чтобы качественно протестировать новую функциональность, хороший тестировщик:
Пишет тест-кейсы:
пользуется техниками тест-дизайна;
составляет тестовую модель (определяет, где, что и каким образом проверять).
Выполняет проверки по тест-кейсам:
знает, для каких проверок какой инструмент использовать: например, для тестирования API — Postman, а для тестирования UI — PixelPerfect или DevTools;
умеет пользоваться этими инструментами;
знает, как оптимально решать задачу проверки — например, пользуется переменными и скриптами в Postman, знает, на что обращать внимание при просмотре запросов в DevTools и т.д.
Это необходимый минимум для того, чтобы качественно выполнять контроль качества. Но этот процесс можно исполнять ещё и оптимально, для этого хороший тестировщик:
Тестирует требования.
Пишет тест-кейсы до разработки.
Стремится к тому, чтобы обратная связь от тестирования была максимально быстрой — например, с помощью автотестов, которые написаны до или параллельно с разработкой фичи.
Регрессионное тестирование
Релиз без регресса — это лотерея. Поэтому перед каждым релизом нужно проводить регрессионное тестирование, чтобы убедиться, что внесение изменений в код не сломало то, что работало раньше. Качественное тестирование не проводится по памяти, поэтому хороший тестировщик:
Составляет тест-план регресса
Для прогнозируемости стоимости и времени разработки ещё на этапе планирования реализации какой-либо функциональности команда уже должна знать, в каком объёме потребуется регресс и сколько времени он займёт. К сожалению, очень часто команды про это забывают и перед релизом либо жертвуют регрессионным тестированием, либо вынуждены откладывать релиз.
Если говорить не только о качестве, но и о скорости тестирования, то нельзя не упомянуть про то, что хороший тестировщик:
Инициирует автоматизацию регрессионного тестирования там, где это рентабельно
Формулировка неслучайно выбрана именно такая, ведь важно помнить, что автоматизацией тестирования может заниматься не только тестировщик. Честно говоря, человек, который умеет писать код (программист), справляется с задачей автоматизации тестирования куда лучше, чем тестировщик.
Что касается слова «рентабельно» — важно помнить, что не всегда автоматизация приводит к удешевлению тестирования. Помимо затрат на создание автотестов, нужно помнить и о затратах на их поддержку. Писать автотесты на функциональность, в которой планируются частые функциональные изменения, вероятнее всего, плохая идея.
Поэтому так важно сравнивать стоимость ручного тестирования с расходами на автоматизацию, считать ROI автоматизации тестирования.
Помимо автоматизации затраты на регресс можно оптимизировать и другими способами — например, проводя импакт-анализ или ротацию тест-кейсов.
Отчёт о результатах тестирования
Этот пункт обязанностей тестировщика пусть и формальный, но очень важный. Для начала тестировщику нужно знать ответы как минимум на два вопроса – кому предоставлять отчёт о результатах тестирования и какая информация в нём должна быть.
Я рекомендую включать в отчёт о тестировании следующую информацию:
сведения о выполненных требованиях (зелёные тесты);
информацию об обнаруженных дефектах (красные тесты);
данные о требованиях, выполнение которых не удалось подтвердить (непроведённые тесты).
Чем тестировщик НЕ должен заниматься
Первое и самое важное — тестировщик не должен решать, как должна работать функциональность. Его задача — проверить, совпадает ли реальный результат с ожидаемым. В тот момент, когда тестировщик сам придумывает, каким должен быть результат, он перестаёт быть тестировщиком и превращается в продакта или аналитика. И тут важно, чтобы человек, который действительно выполняет эти роли, обладал нужными для этого навыками.
Второе, не менее важное — тестировщик не принимает решения о том, можно ли релизиться. Лидеры команды не должны по умолчанию перекладывать эту ответственность на тестировщика. Да, внутри команды можно об этом договориться, но, как и в предыдущем пункте, принимать решение должен тот, у кого есть и нужные компетенции, и достаточная информация. В большинстве случаев тестировщик не располагает ни тем, ни другим. В продуктовых командах логичнее всего, если решение о релизе с дефектами принимает Product Owner — именно он лучше всех понимает, принесёт ли фича больше пользы, чем вреда от дефекта.
Из этого логично вытекает следствие: тестировщик не должен расставлять приоритеты между дефектами — какие важнее, а какие можно подождать. Разворачивать тему не буду, предлагаю обсудить это в комментариях.
Итого
Мы разобрали основные активности тестировщика: проверку новой функциональности, регрессионное тестирование и предоставление прозрачной информации о результатах. Всё это сводится к одной ключевой цели — дать команде и бизнесу достоверную картину качества продукта, чтобы они могли принимать осознанные решения о релизе.
Важно помнить: тестировщик не «сторож релиза» и не «поставщик багов». Его задача — быть источником информации, который помогает делать разработку предсказуемой, дешёвой и быстрой.
Идеальный процесс контроля качества строится именно вокруг этого:
Требования тестируются ещё до разработки.
Проверки новых функций проводятся быстро и максимально рано.
Регрессионное тестирование прогнозируемо по времени и усилиям, оптимизируется за счёт автоматизации и импакт-анализа.
Отчёт о тестировании полезен для ролей, принимающих решение о релизе.
Если команда и сам тестировщик держат в фокусе именно эти принципы, процесс разработки становится устойчивым: меньше сюрпризов, меньше задержек, больше уверенности в релизах.
