Привет, Хабр! На связи Галина Чупрова, главный инженер по тестированию в Рунити. Сегодня расскажу, как мы в компании пришли к тестированию документации — и почему этот шаг повысил эффективность тестирования и сэкономил команде нервы.
Навигация по тексту:
Как выглядел процесс «до»
Когда команда только формировалась, процесс выглядел довольно стандартно.
Фича → бизнес-требования → архитектура → дизайн-макеты → разработка → тестирование → релиз.
Пока продукт был маленьким, схема работала. Тестировщик получал задачу, погружался в документацию, уточнял детали у архитекторов и дизайнеров, составлял чек-листы и сценарии, проводил проверки. Задержки были минимальными.
Но с ростом продукта и команды всё изменилось.
Почему старый подход не работал
Когда документации стало больше, а сценарии сложнее, начали накапливаться проблемы:
тестировщики погружались в контекст «урывками», только в момент финальной проверки;
у р��зработчиков появлялся поток уточняющих вопросов от QA, хотя им уже нужно было двигаться дальше;
приходилось дорабатывать макеты и архитектуру после передачи задачи в разработку;
на подготовку тестовых сценариев уходило больше времени;
возрос риск пропустить важные проверки и баги;
сроки релизов могли сдвигаться.
Что мы изменили в тестировании
Мы решили перестроить процесс и подключать тестирование раньше — еще на этапе требований и макетов.
Теперь QA-инженеры участвуют в ревью документации, обсуждают ключевые фичи вместе с аналитиками и разработчиками, готовят сценарии до того, как код попадает в работу.
Важный шаг — ревью тестовой документации внутри команды. Каждый тестировщик обладает экспертизой в своей части продукта, поэтому мы проверяем кейсы друг друга, убираем дубли и неточности.
Как мы тестируем документацию и макеты
Когда мы только начали думать о тестировании документации, быстро стало ясно: если не задать рамки, процесс расползется и будет непонятно, что именно проверять, и кто из сотрудников за какой этап отвечает. Поэтому мы разработали универсальные критерии тестирования, которые помогают команде QA и разработке говорить на одном языке.
Например, полнота. Документ должен описывать не только «как это должно работать», но и что именно получит клиент, что будет при ошибке, какие уведомления прилетят, как считается цена. Если этого нет — на этапе тестирования появляются белые пятна, и задача снова откатывается назад.
Или однозначность. Тут всё просто: если один термин каждый понимает по-своему, дальше жди сюрпризов. Поэтому мы договорились фиксировать термины и формулировки так, чтобы и аналитик, и разработчик, и тестировщик читали документ одинаково.
Непротиворечивость тоже звучит очевидно, но на практике это про то, что нельзя одно требование описывать в двух местах. Иначе можно обновить в одном месте, но забыть об этом в другом — и тогда команда идет по разным сценариям.
Еще важны осуществимость и тестируемость: сможем ли вообще реализовать требование и проверить его тестом. Здесь подключаются разработчики, чтобы отсеять нереалистичные идеи.
И, конечно, актуальность: если во время разработки что-то меняется, изменения должны попасть в документацию сразу, иначе на ревью снова всплывут рассинхроны.
С макетами история похожая. Мы смотрим:
соответствует ли макет требованиям;
учтены ли все сценарии (уведомления, ошибки, мобильная версия);
удобно ли это конечному пользователю;
не устарели ли макеты после правок;
и можно ли это реально реализовать.
На выходе у нас есть набор артефактов: тест-планы, чек-листы и сценарии, которые учитывают типы и методы тестирования. Все эти документы помогают командам работать по единым для всех стандартам.
С какими трудностями столкнулись
Конечно, на бумаге всё выглядело красиво. Но когда начали внедрять, реальность быстро внесла коррективы.
Первое, что почувствовали, — банально не хватало времени. Документации становилось больше, а времени в спринте никто не добавил. Решением стало заведение отдельных задач на тестирование документации, чтобы ничего не терялось.
Вторая проблема — ревью кейсов. Если каждый тестировщик пишет сценарии, а потом еще должен проверять чужие, ресурс тратится огромный. Мы сделали обязательным минимум: ревью от тимлида и еще одного QA. Так баланс между качеством и скоростью оказался рабочим.
Третье — актуализация кейсов по ходу разработки. Сначала кейсы писались рано, требования менялись, и сценарии теряли актуальность еще до тестирования. После нескольких неудачных итераций мы выбрали оптимальное время — начинать работу с документацией после оценки ее осуществимости разработкой.
Четвертая история — дублирование тест-кейсов. Иногда мы описывали одно и то же в разных проектах. Решили перестроить структуру и обновлять существующие кейсы вместо написания новых.
И пятое — пожалуй, самое болезненное: слишком раннее подключение. На старте мы хватали документ сразу после написания, когда он еще «сырой». Это оборачивалось переделками. Теперь берем документ только после того, как его посмотрели разработчики.
Что изм��нилось после внедрения
После внедрения нового подхода мы довольно быстро заметили эффект.
Во-первых, мы начали ловить ошибки на ранних этапах. Исправить недочет в документе в разы дешевле, чем чинить баг в продакшене.
Во-вторых, время тестирования задач заметно сократилось. Например, раньше одна задача занимала 32 часа, теперь — 10. В другом кейсе — 17 против 8 часов.
В-третьих, стали точнее оценки сроков. Когда тестировщики подключаются заранее, они лучше понимают функционал и закладывают реалистичное время.
И, наконец, команда стала работать спокойнее. QA глубже понимает продукт, меньше рискует пропустить баг, а у разработчиков и аналитиков нет ощущения, что тестирование откладывает сроки релиза.
Вместо заключения
Для нас тестирование документации перестало быть формальностью. Это стало рабочим инструментом, который экономит время, снижает риски и позволяет выпускать продукт в срок.
Лучше задать неудобный вопрос на этапе требований, чем потом чинить баг в продакшене или переделывать готовую реализацию. А как у вас устроено тестирование документации? Поделитесь опытом в комментариях — интересно сравнить подходы.
