В предыдущих публикациях ( первый И второй ) мы рассмотрели основные понятия о качестве, четырехуровневом процессе управления и обеспечении качества, увидели, что требования и качества тесно связаны друг с другом, попытались получить ответы на вопросы: какое мышление должно быть у команды должны встроить качество в продукт? Какова пирамида тестирования продукта? Как быстрее получать обратную связь при разработке программного обеспечения? Большой.
Мы поняли, осознали и приняли мышление «Тестирование прежде всего», концепцию «Сдвиг влево» тестирования и определили пирамиду тестирования.
Теперь возникает вопрос, как начать генерировать качественные тест-кейсы? Поскольку качество и требования тесно связаны, логично предположить, что тестовые примеры можно генерировать на основе требований.
Давайте возьмем бизнес-функцию, которую необходимо реализовать.
Очень важно, чтобы функция описывалась по шаблону — название функции, в чем проблема, какую гипотезу проверяет функция для решения проблемы, критерии приемки.
Шаблон описания бизнес-функций Такое описание возможности позволяет сделать работу с ней понятной всем заинтересованным сторонам — клиенту, РО, разработке, тестированию, бизнесу.
Далее функцию следует разбить на пользовательские истории и специальные истории, направленные на исследования, архитектуру или инфраструктуру.
Пользовательская история — это основное средство выражения требуемой функциональности.
Более того, пользовательские истории должны быть ориентированы на ценность для клиента.
те.
Не нужно писать пользовательскую историю ради пользовательской истории.
User Story лучше писать по шаблону — Как (роль) я хочу (деятельность) (ценность бизнеса).
Описывая пользовательскую историю с помощью шаблона, мы получаем, кто или что появляется в пользовательской истории, что произойдет и, конечно же, какую ценность мы получим от реализации этой пользовательской истории.
Пользовательская история должна иметь критерии приемлемости INVEST. При описании User Story лучше руководствоваться принципами INVEST. При этом критерии приемлемости User Story должны быть описаны в соответствии с принципами INVEST.
- Мы пишем User Stories, которые можно разрабатывать отдельно.
- Пишем User Story, рамки которой можно согласовать
- Мы пишем пользовательские истории, которые ценны для клиента
- Мы пишем пользовательские истории, которые можно оценить
- Пишем пользовательские истории, которые можно решить за одну итерацию
- Мы пишем пользовательские истории, которые проходят тестирование.
Критерий приемлемости можно рассматривать как приемлемое поведение системы в конце истории.
Но как поведет себя система в разных ситуациях? Каким должно быть поведение, чтобы критерии приемлемости были соблюдены? Есть много способов ответить на этот вопрос, но один из самых эффективных — проанализировать поведение системы с разных точек зрения.
Понимание поведения предполагает рассмотрение этого поведения с разных точек зрения.
Более того, только когнитивно разные точки зрения (мысли) могут способствовать лучшему пониманию.
РО (Клиент) – что бы вы хотели сделать? Разработчик - как это технически реализовать? Тестер - как сделать все стабильно? Работая над функцией User Story, троица (или триада, или три амиго) начинают генерировать так называемые сценарии и варианты использования.
Один сценарий – одно поведение системы.
И таких сценариев может быть много.
Сценарии также имеют собственный формат описания.
Одним из наиболее распространенных является «Дано, когда, тогда».
Но есть и другие варианты описания сценариев, главное, чтобы было начальное состояние, действие и конечное состояние.
Давайте посмотрим на небольшой пример.
История пользователя — Установка круиз-контроля.
Возьмем пока один критерий приемки – скорость машины должна быть близка к заданной.
Один из сценариев из критерия приемки: Учитывая, что машина находится в движении и когда задана скорость, то скорость близка к заданной.
Но, если начать рассматривать разные варианты, сценариев становится больше! 
Сценарии также могут появляться при рассмотрении вариантов использования.
Также существуют методы генерации сценариев — CRC-карты, динамические модели, модели состояний, использование персон и т. д. После того, как все сценарии записаны, их нужно превратить в тесты.
Критерии приемки (и, следовательно, сценарии) определяют приемлемое поведение системы.
Приемочные тесты наследуют критерии приемки и определяют конкретное поведение «пройдено/не пройдено».
Приемочные испытания Как видно из примера, в скрипт добавлены данные «пройден/не пройден».
И появился первый тест. Тест, который был сформирован на основе критериев приемки.
Тест, практически написанный на Gherkin. Корнишон имеет разные формы подачи.
Различные формы представления Используя эти BDD-тесты Gherkin в связке с Cucumber или FitNess, мы получим хорошую автоматизацию, которая покроет значительную часть требований к функциональности продукта.
Но мы должны понимать и осознавать, что и BDD, и TDD не реализуются по щелчку пальцев.
Для этого нужно менять процессы и внедрять практики.
Как это можно организовать, описано в статья .
Подводя итог, хотелось бы сказать, что в статье описан один из подходов к формированию мощной базы автоматических тестов.
Но есть много нюансов и подходов при разработке e2e-тестов, UI-тестов, определении SUT (System Under Test) и т. д. Теги: #Управление разработкой #qa #Тестирование ИТ-систем #тестирование качества #процессы в ней #качество от #автоматизация качества #управление качеством #qc #процессы разработки
-
Nuc, Лего, Суперклей
19 Oct, 24 -
Скромный Комплект №3 Запущен.
19 Oct, 24 -
Srl — Простой Язык Регулярных Выражений
19 Oct, 24 -
Бесконтактный Тачпад
19 Oct, 24
