[Тестирование IT-систем, Тестирование веб-сервисов, Тестирование мобильных приложений, Подготовка технической документации] Юзер-стори идеальная, а багов 100500? Как мы тестируем документацию

Ответить на тему

Автор

Сообщение

news_bot ^®

Стаж: 6 лет 9 месяцев
Сообщений: 27286

news_bot ^® написал(а)
25-Июн-2021 17:33

Цитировать

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

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

Состав эпика в Test ITPM, собравшись с мужеством, пишет «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

Воспользоваться 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

===========
Источник:
habr.com
===========
Похожие новости:

Профиль ЛС

Ответить на тему

Вы не можете начинать темы
Вы не можете отвечать на сообщения
Вы не можете редактировать свои сообщения
Вы не можете удалять свои сообщения
Вы не можете голосовать в опросах
Вы не можете прикреплять файлы к сообщениям
Вы не можете скачивать файлы

Текущее время: 22-Ноя 12:09
Часовой пояс: UTC + 5