Сегодня хочу рассказать о нашем кейсе в процессах тестирования. Разумеется, старалась коротко, но получилось как всегда.

Как выглядел процесс на старте: Продакт-менеджер как-то пишет ТЗ, отдает дизайнеру ➡️ Дизайнер разрабатывает макеты. ➡️ ПМ приносит ТЗ и макеты команде разработки, команда дает примерную оценку ➡️ Разработчик берет задачу в работу, по готовности отдает тестировщику ➡️ Тестировщик тестирует, заводит баги, по своему усмотрению выясняет у дизайнеров и ПМ как должна работать фича в различных сценариях, параллельно пишет тест-кейсы ➡️ По полной готовности фича приходит на аппрув ПМ, и либо цикл разработки повторяется, либо фича считается готовой к релизу.

Какие проблемы этого флоу мы хотели решить в первую очередь: 1️⃣Срыв сроков 🔸Недоработки в ТЗ и дизайне выявлялись в лучшем случае только на этапе фактического тестирования и фикс таких багов стоил дорого и срывал сроки: фиче приходилось проходить цикл почти с самого начала, увеличивалась незапланированная нагрузка на всех участников, включая дизайнеров, какие-то части фичи приходилось буквально переписывать заново. 🔸Каждый участник разработки фичи понимал задачу по-своему из-за недостаточной информации в ТЗ и в итоге эти нестыковки обнаруживались поздно, когда фича уже завершена и попала на аппрув к ПМ. 2️⃣Огромное количество багов на регрессе и на проде 🔸Многие из пропущенных багов даже не были покрыты тест-кейсами: исследовательское тестирование требует определенной квалификации и умения применять ряд техник, чтобы проводить его действительно качественно. 3️⃣Некорректная оценка фичи 🔸И разработчики, и тестировщики оценивали объем и сроки фичи “экспертно”, без понимания картины целиком, из-за чего в эту оценку команда, разумеется, попадала слабо.

Как теперь поступаем: 1️⃣Еще до разработки берем ТЗ и макеты в анализ: визуализируем функционал в Miro через составление блок-схемы, скрупулезно отражая в ней все переходы и состояния. Выявляем, где фича пересекается с существующим функционалом, какие корнер-кейсы могут быть и т.д. 2️⃣Подсвечиваем все, чего не хватает в ТЗ и макетах, чтобы завершить схему. 3️⃣Собираем короткие синки с дизайнером и ПМ, в рамках которых проходимся по схеме, убеждаемся, что нами все понято верно, задаем вопросы по недостающим кейсам и получаем на них ответы. 4️⃣Пишем тест-кейсы на основе блок-схемы. 5️⃣Разработчики знакомятся не только с макетами, но и со схемой и кейсами, техпроектируют фичу, подсвечивают тестировщикам, какой еще функционал может быть затронут и что еще стоит включить в проверки, дают оценку по разработке на основе этой схемы.

Что получилось: 🔥Стали находить ошибки в ТЗ и дизайне до начала разработки, фиксим их дешево. 🔥Снизили количество багов на регрессе: то, что мы не учитывали и пропускали раньше, теперь учитывается, обрабатывается и согласовывается заранее. 🔥Дизайнерам и ПМ стало удобнее отвечать на вопросы пакетно в контексте фичи целиком, а не по одному в разное время. 🔥Продакт-менеджеры стали использовать нашу визуализацию для последующего расширения или изменения функционала. 🔥Тестировщики начали писать тест-кейсы до разработки, что позволяет тестировать задачи по готовым кейсам. 🔥Разработчикам стало удобнее техпроектировать и оценивать, опираясь на блок-схему, так как объемы фичи стали более наглядными. То же касается самих тестировщиков. 🔥Наблюдается закономерная бОльшая вовлеченность всех участников в фичу и ее качество, все компетенции стали больше взаимодействовать друг с другом.

В каком-то из следующих постов расскажу о минусах этого подхода и о том, как мы их нивелируем 🤫

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