Привет, Хабр! 

С вами Галина Чупрова, главный инженер по тестированию в Рунити. Сегодня расскажу, как мы в компании пришли к тестированию документации — и почему этот шаг повысил эффективность тестирования и сэкономил команде нервы.

Навигация по тексту:

1. Как выглядел процесс «до»

2. Почему старый подход не работал

3. Что поменяли в тестировании

4. Как мы тестируем документацию и макеты

5. С какими трудностями столкнулись

6. Что изменилось после внедрения

7. Вместо заключения
   

Как выглядел процесс «до»

Когда команда только формировалась, процесс выглядел довольно стандартно.

Фича → бизнес-требования → архитектура → дизайн-макеты → разработка → тестирование → релиз.

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

Но с ростом продукта и команды всё изменилось.

Почему старый подход не работал

Когда документации стало больше, а сценарии сложнее, начали накапливаться проблемы:

• тестировщики погружались в контекст «урывками», только в момент финальной проверки;

• у разработчиков появлялся поток уточняющих вопросов от QA, хотя им уже нужно было двигаться дальше;

• приходилось дорабатывать макеты и архитектуру после передачи задачи в разработку;

• на подготовку тестовых сценариев уходило больше времени;

• возрос риск пропустить важные проверки и баги;

• сроки релизов могли сдвигаться.

Что мы изменили в тестировании

Мы решили перестроить процесс и подключать тестирование раньше — ещё на этапе требований и макетов.

Теперь QA-инженеры участвуют в ревью документации, обсуждают ключевые фичи вместе с аналитиками и разработчиками, готовят сценарии до того, как код попадает в работу.

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

Как мы тестируем документацию и макеты

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

Например, полнота. Документ должен описывать не только «как это должно работать», но и что именно получит клиент, что будет при ошибке, какие уведомления прилетят, как считается цена. Если этого нет — на этапе тестирования появляются белые пятна, и задача снова откатывается назад.

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

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

Ещё важны осуществимость и тестируемость: сможем ли вообще реализовать требование и проверить его тестом. Здесь подключаются разработчики, чтобы отсеять нереалистичные идеи. 

И, конечно, актуальность: если во время разработки что-то меняется, изменения должны попасть в документацию сразу, иначе на ревью снова всплывут рассинхроны.

С макетами история похожая. Мы смотрим:

• соответствует ли макет требованиям;

• учтены ли все сценарии (уведомления, ошибки, мобильная версия);

• удобно ли это конечному пользователю;

• не устарели ли макеты после правок;

• и можно ли это реально реализовать.

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

С какими трудностями столкнулись

Конечно, на бумаге всё выглядело красиво. Но когда начали внедрять, реальность быстро внесла коррективы.

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

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

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

Четвёртая история — дублирование тест-кейсов. Иногда мы описывали одно и то же в разных проектах. Решили перестроить структуру и обновлять существующие кейсы вместо написания новых.

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

Что изменилось после внедрения 

После внедрения нового подхода мы довольно быстро заметили эффект.

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

Во-вторых, время тестирования задач заметно сократилось. Например, раньше одна задача занимала 32 часа, теперь — 10. В другом кейсе — 17 против 8 часов.

В-третьих, стали точнее оценки сроков. Когда тестировщики подключаются заранее, они лучше понимают функционал и закладывают реалистичное время.

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

Вместо заключения

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

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