Зачем и как тестируют документацию? Представьте ту редкую ситуацию, когда в требованиях ошибка или документация составлена неверно. Что дальше? Требование уходит в разработку, программист неверно его истолкует и реализует фичу с искаженной функциональностью. Далее это заметит тестировщик, отправит баг-репорт, который пройдет весь life cycle (пофиксен, проверен, исправлен, закрыт). И это ещё хороший сценарий!
В реальной жизни не все баги исправляют с первого раза, а порой они попадают в прод с печальными последствиями. На вопрос «зачем» ответил. Ответ на вопрос «как» — ниже.
Отношения команды с документацией можно определить, в зависимости от психологической зрелости компании. Как известно, зрелость вовсе не определяется биологическим возрастом – все как в жизни.
Меня зовут Михаил Тимофеев, это моя первая статья, занимаюсь по большей части нагрузочным тестированием в команде Test IT. Нашей компании 2 года, мы разрабатываем систему управления тестированием. Наша система помогает QA-командам работать с ручными и автотестами, привести в порядок тестовую модель, поддерживать и хранить ее в одном месте, упрощает коммуникацию внутри команды. Но это не значит, что мы боги тестирования. Мы тоже люди и совершаем ошибки. Главное — это вовремя их обнаружить и пофиксить =)
Flow тестирования документации
Для нас Agile не равно отсутствие документации. Мы фиксируем все обсуждения с помощью комментариев к уже созданной документации. Поэтому наши записи четко структурированы и отражают суть, что облегчает работу с документацией на регрессе. Мы приняли следующую иерархию документации:
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
Полное изображение по ссылке.
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 - примеры использования данной функциональности в использовании фичи.
Полное изображение по ссылке.
Воспользоваться API для экспорта тест-планов на инстансе 1, указать проект целиком, или конкретные тест-планы,
Получить выгрузку,
Воспользоваться API для импорта тестов на инстансе 2, отправить полученную выгрузку,
На инстансе 2 появился проект с секциями и тестами, которые были экспортированы, с сохранением структуры секций. В тест-кейсах содержатся, названия, описания системные и пользовательские атрибуты, пред-, пост- условия тестов и секций, ссылки и общие шаги.
7. Definition of Done - требования к реализуемой фиче
Есть возможность экспортировать тест-планы с помощью API
При экспорте тест-планов есть возможность выбрать проект целиком, либо конкретные тест-планы
При экспорте планов, пользователь получает выгрузку в JSON формате в файле. Файл имеет следующее название: Test IT — {имя_проекта} - {имя_плана} - {datetime}.
Стандартизация по пунктам дает полное понимание разрабатываемой функциональности. Прочитав этот документ, разработчик точно будет знать, кто пользователи и для какой цели им нужна данная фича. Для аналитика, владельца продукта и тестировщика будет сформирована единая сетка требований. Разработчики точно будут знать, куда смотреть во время технической экспертизы при постановке подзадач, а пункты Use Case и Definition of Done позволят лучше понять бизнес-задачи.
Применение паттернов из пирамиды тестирования к юзер-стори
Полное изображение по ссылке.
1) юнит-тесты:
Удостовериться в наличии;
Белый ящик.
2) компонентное тестирование:
Функциональные требования;
Не функциональные требования;
Белый ящик;
Проектные риски — зная своих коллег, можно заранее прикинуть реальное время на выполнение задачи. Позволит скорректировать время на reject US;
Тех. долг команды — позволит учесть в тестировании узкие места и ссылаться на существующую проблематику.
3) интеграционное тестирование:
Не функциональные требования;
Цели: для чего нужна фича, какие аспекты вашего ПО будут затронуты;
Имидж продукта. Насколько фича отвечает общей концепции, не затрагивает ли общий вектор развития продукта;
Технологии, использованные при создании продукта;
Черный ящик;
Цели качества (критерии — запрос должен выполняться за 1 секунду);
Тех. долг команды — позволит учесть в тестировании узкие места и ссылаться на существующую проблематику.
4) e2e:
Пользовательские сценарии (примени к каждому сценарию CRUD);
Различные окружения — железо, ОС, приложения, конфигурация, языки;
Объемное тестирование;
Функциональные требования;
Негативные сценарии;
Процесс внедрения:
Разработать и принять форму написания юзер-стори;
Подход к тестированию: 1 юз.стори = 1 QA;
Разработка тестовых сценариев в соответствии с паттернами тестовых сценариев пирамиды тестирования;
Контроль за покрытием тестовыми сценариями каждой User Story.
Результат:
Стандартизированная документация, в которой легко находить нужную информацию. В юзер-стори указаны бизнес-требования (кому и для чего это нужно), они составлены с учетом возможных сценариев использования, четко определены пункты, которые должны быть выполнены;
Глубокое понимание процессов взаимодействия конкретной фичи с остальным проектом;
Покрытие юзер-стори с учетом различных уровней тестирования. Специалист, только что пришедший на проект, сможет покрыть от 60% юзер-стори тестовой документацией;
Недвусмысленное понимание того, какие именно части юзер-стори покрыты тестовыми сценариями.
Дисклеймер: впервые тема была изложена в рамках доклада на конференции SQADays-28 в апреле 2021 года.
Библиография при подготовке:
37 Sources for Test Ideas, авторы Rikard Edgren, Martin Jansson and Henrik Emilsson
Тестовое покрытие по Бейзеру, автор видео Анастасия Асеева-Нгуен — эксперт по инженерным практикам в Tinkoff Group