Зачем и как тестируют документацию? Представьте ту редкую ситуацию, когда в требованиях ошибка или документация составлена неверно. Что дальше? Требование уходит в разработку, программист неверно его истолкует и реализует фичу с искаженной функциональностью. Далее это заметит тестировщик, отправит баг-репорт, который пройдет весь life cycle (пофиксен, проверен, исправлен, закрыт). И это ещё хороший сценарий!

В реальной жизни не все баги исправляют с первого раза, а порой они попадают в прод с печальными последствиями. На вопрос «зачем» ответил. Ответ на вопрос «как» — ниже.

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

Меня зовут Михаил Тимофеев, это моя первая статья, занимаюсь по большей части нагрузочным тестированием в команде Test IT. Нашей компании 2 года, мы разрабатываем систему управления тестированием. Наша система помогает QA-командам работать с ручными и автотестами, привести в порядок тестовую модель, поддерживать и хранить ее в одном месте, упрощает коммуникацию внутри команды. Но это не значит, что мы боги тестирования. Мы тоже люди и совершаем ошибки. Главное — это вовремя их обнаружить и пофиксить =)

Flow тестирования документации

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

Состав эпика в Test IT

PM, собравшись с мужеством, пишет «Epic» и «User Story»

Эти сущности в Test IT начинается со слова «Хочу», которое является вектором развития ПО. Например: «Хочу иметь возможность импортировать/экспортировать тест-планы», «Хочу переносить тест-кейсы с одного инстанса Test IT на другой» и т.д. Тут можно посмотреть пример нашей стори.

Эпики и стори содержат: требования, юзкейсы и критерии выполнения; задачи, подзадачи и дефекты. 

Связка эпика и юзер-стори

Затем QA тестируют User Story на:

Завершенность: User story представляет собой полноценную, логично завершенную новую или усовершенствованную старую функциональность.

Последовательность: Данная User Story логично продолжает развитие «Epic», который она реализует, или закономерно продолжает общее развитие продукта в текущей версии.

Непротиворечивость: Реализуемый функционал не противоречит самому себе, и не противоречит логике работы интегрируемых с ним компонентов ПО.

Атомарность: Каждое требование, описанное в User Story, является целостным и неделимым на подзадачи. Оно само является подзадачей.

Отслеживаемость: Каждая User Story, Task, SubTask, Bug должны быть слинкованы между собой для возможности отслеживания работы по User Story.

Актуальность: Вся информация после обсуждений вносится либо в комментарии, либо правится непосредственно Product Owner.

Выполнимость: Совершенно не зря проводятся analytical review -> frontend review -> backend review -> QA review. Здесь мы обсуждаем возможность и особенности при выполнении.

Недвусмысленность: Перекликается с принципом «Атомарности», каждое требование должно иметь единственную трактовку во избежание двусмысленности и отсутствия понимания.

Обязательность: Каждое требование, описанное в User Story- является обязательным к выполнению.

Проверяемость: Наличие обоснованных и выполнимых критериев завершения задачи. У нас эту роль играет раздел «Definition of Done».

Перед тем как User Story попала в разработку, она должна пройти через analytical review -> frontend review -> backend review -> QA review. Над User Story работают разные люди, с разными специальностями и специализациями что позволяет сформулировать более точные требования и подумать заранее о возможных проблемах. 

После тестирования юзер-стори пишем Test Cases в соответствии с пунктами Use Case и Definition of Done. 

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

Пирамида тестирования

Unit у нас их пишут разработчики. И да, на это выделяется на планировании спринта как отдельная задача, и на них уже в самом начале закладывается время. 

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

Integration: проводим с отделом разработки. Здесь важно отследить взаимодействие с ближайшими компонентами в системе или с компонентами, на которые влияет данная функциональность.

E2E: для них мы берем информацию из пользовательских сценариев. 

Тест кейсы обеспечивают атомарную документацию по конкретной фиче в рамках User Story. На каждый вопрос от члена команды «А что если?..» QA может составить минимум один тест. От количества заданных вопросов «А что если?..», и уровня профессионализма тестировщика зависит качество выпускаемого продукта, стоимость найденных дефектов и их исправления.

User Story идеальная, ​а багов +100500

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

В Test IT мы сформировали свой подход к решению подобных проблем.

Мы используем:

  • Специалиста фича-тестера 

  • Стандартизацию юзер-стори

  • Пирамиду тестирования

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

Feature tester

Специалист, который комплексно работает над задачей. В зоне его ответственности находится: тестирование документации, написание тестовых сценариев, тестирование frontend и backend компонентов. Тесная работа с командой разработчиков в рамках пользовательской истории, которую ему передали в работу в начале релиза.

Контроль качества по пользовательской истории сосредоточен на одном специалисте, как следствие: 

  • Глубокое знание продукта;

  • Качественные сообщения о дефектах содержащие исчерпывающую информацию со стороны backend и frontend разработки;

  • Сокращение времени работ по исправлению дефектов;

  • Постоянное повышение квалификации;

  • Возможность влиять на юзер-стори на протяжении всего процесса разработки более оперативно и централизованно;

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

Стандартизация US

Пример User Story

Полное изображение по ссылке.

1. Description — общее описание к US, коротко передаем основную идею.

«Как пользователь, управляющий тестированием на проектах и использующий разные инстансы Test IT, я хочу переносить тест-планы с одного инстанса на другой».

2. User personas - кто будет пользоваться функциональностью. Здесь можно сделать вывод о том какие смежные компоненты будут задействованы в системе.

«Администратор Test IT, координатор/руководитель проектов, Тест-менеджер».

3. User problem - какие проблемы решает новая функциональность.

«Существует два инстанса Test IT не синхронизированные между собой. Есть потребность частично или полностью перенести тест-планы одного и того же проекта с одного инстанса на другой, с возможностью просмотра что было изменено.»

4. Business value - какую бизнес ценность несет данная функциональность.

Возможность импорта/экспорта тест-планов в собственном формате, возможность актуализации тест-планов и кейсов, находящихся в тест-плане с помощью импорта/экспорта.;

5. What should be done - что должно быть выполнено - раздел, декомпозирующий и уточняющий требования юзер-стори.

  • Реализовать возможность выполнения импорта и экспорта тест-планов в проекте.

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

  • Реализовать возможность актуализации тест-планов с помощью импорта, с отображением изменений в журнале изменения тестов, истории прохождения тестов и отображением актуальной версии тестов на момент их прохождения.

6. Use case - примеры использования данной функциональности в использовании  фичи.

Полное изображение по ссылке.

Test Case

  1. Воспользоваться API для экспорта тест-планов на инстансе 1, указать проект целиком, или конкретные тест-планы,

  2. Получить выгрузку,

  3. Воспользоваться API для импорта тестов на инстансе 2, отправить полученную выгрузку,

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

7. Definition of Done - требования к реализуемой фиче

  1. Есть возможность экспортировать тест-планы с помощью API

  2. При экспорте тест-планов есть возможность выбрать проект целиком, либо конкретные тест-планы

  3. При экспорте планов, пользователь получает выгрузку в JSON формате в файле. Файл имеет следующее название: Test IT — {имя_проекта} - {имя_плана} - {datetime}.

Стандартизация по пунктам дает полное понимание разрабатываемой функциональности. Прочитав этот документ, разработчик точно будет знать, кто пользователи и для какой цели им нужна данная фича. Для аналитика,  владельца продукта и тестировщика будет сформирована единая сетка требований. Разработчики точно будут знать, куда смотреть во время технической экспертизы при постановке подзадач, а пункты Use Case и Definition of Done позволят лучше понять бизнес-задачи.

Применение паттернов из пирамиды тестирования к юзер-стори

Полное изображение по ссылке.

1) юнит-тесты:

  • Удостовериться в наличии;

  • Белый ящик.

2) компонентное тестирование:

  • Функциональные требования;

  • Не функциональные требования;

  • Белый ящик;

  • Проектные риски — зная своих коллег, можно заранее прикинуть реальное время на выполнение задачи. Позволит скорректировать время на reject US;

Тех. долг команды — позволит учесть в тестировании узкие места и ссылаться на существующую проблематику.

 3) интеграционное тестирование:

  • Не функциональные требования;

  • Цели: для чего нужна фича, какие аспекты вашего ПО будут затронуты;

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

  • Технологии, использованные при создании продукта;

  • Черный ящик;

  • Цели качества (критерии — запрос должен выполняться за 1 секунду);

Тех. долг команды — позволит учесть в тестировании узкие места и ссылаться на существующую проблематику.

4) e2e:

  • Пользовательские сценарии (примени к каждому сценарию CRUD);

  • Различные окружения — железо, ОС, приложения, конфигурация, языки;

  • Объемное тестирование;

  • Функциональные требования;

  • Негативные сценарии; 

Процесс внедрения:

  1. Разработать и принять форму написания юзер-стори;

  2. Подход к тестированию: 1 юз.стори = 1 QA;

  3. Разработка тестовых сценариев в соответствии с паттернами тестовых сценариев пирамиды тестирования;

  4. Контроль за покрытием тестовыми сценариями каждой User Story.

Результат:

  1. Стандартизированная документация, в которой легко находить нужную информацию. В юзер-стори указаны бизнес-требования (кому и для чего это нужно), они составлены с учетом возможных сценариев использования, четко определены пункты, которые должны быть выполнены;

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

  3. Покрытие юзер-стори с учетом различных уровней тестирования. Специалист, только что пришедший на проект, сможет покрыть от 60% юзер-стори тестовой документацией;

  4. Недвусмысленное понимание того, какие именно части юзер-стори покрыты тестовыми сценариями.

Дисклеймер: впервые тема была изложена в рамках доклада на конференции SQADays-28 в апреле 2021 года.

Библиография при подготовке: