В прошлых публикациях (первая и вторая) рассмотрели основные понятия про качество, четырехуровневый процесса управления и обеспечения качества, увидели что требования и качества тесно связаны друг с другом, попробовали получить ответы на вопросы какое мышление должно быть у команды для встраивания качества в продукт? Какая на продукте пирамида тестирования? Как ускорить получение обратной связи при разработке программного обеспечения?
Отлично. Разобрались, осознали и приняли мышление Test-First, концепцию Shift Left Testing, определили пирамиду тестирования. Теперь возничкает вопрос, а как начать качественно генерировать качественные тест кейсы?
Так как качество и требования тесно связаны, то логично предположить, что тест кейсы можно сгенерировать из требований. Возьмем бизнес фичу, которую надо реализовать. Очень важно, чтобы фича была описана по шаблону - Название фичи, какая есть проблематика, какую гипотезу фича проверяет для решения проблематики, критерии приемки.
Такое описание фичи, позволяет сделать работу с ней понятной всем заинтересованным сторонам - клиенту, РО, разработке, тестированию, бизнесу.
Дальше фича должна быть разобрана на User Story и специальные story, которые направлены на исследования, архитектуру, или инфраструктуру. User Story - это основное средство выражения необходимой функциональности. Причем user story должны быть сфокусированы на ценности для клиента. т.е. не надо писать user story ради user story. Писать User Story лучше так же писать по шаблону - Как (роль), Я хочу (активность), чтобы (бизнес ценность). Описывая User Story с использованием шаблона, мы получаем кто или что фигурирует в user story, что будет происходить и, конечно же, какую ценность мы получаем, реализуя эту User Story.
При описании User Story лучше рукодствоваться принципами INVEST. При этом и критерии приемки User Story должны быть описаны по принципам INVEST.
Пишем User Story, которые можно разрабатывать отдельно
Пишем User Story, о рамках которых можно договориться
Пишем User Story, которые ценны заказчику
Пишем User Story, которые можно оценить
Пишем User Story, которые можно решить за одну итерацию
Пишем User Story, которые тестируемы.
А теперь, когда удалось расписать несколько User Story, давайте посмотрим на критерии приемки. Критерий приемки можно рассматривать как примлемое поведение системы при завершении истории. Но как система будет себя вести в разных ситуациях? Каким должно буть поведение, чтобы критерии приемки соблюдались? Чтобы получить ответ на этот вопрос есть можество способов, но один из самых действенных - это анализ поведения системы с разных точек зрения. Понимание поведения предполагает рассмотрение этого поведения с множества точек зрения. Причем только когнитивно различные точки зрения (мышлений) могут способствовать лучшему пониманию. РО (Клиент) - что хотелось бы сделать? Разработчик - как это технически реализовать? Тестировщик - как сделать все стабильным?
Работая над фичей, User Story, троица (или триада или три амиго), начинают генерировать, так называемые, сценарии и Use Case-ы. Один сценарий - одно поведение системы. И таких сценариев может быть много.
У сценариев так же есть свой формат описания. Один из самых распрастраненных - Дано, когда, тогда (Given, When, Then). Но существуют и другие варианты описания сценариев, главное, чтобы было начальное состояние, действие и финальное состояние.
Давайте рассмотрим небольшой пример. User Story - Установка круиз контроля. Критерий приемки возьмем пока один - Скорость машины должна быть близка к установленной скорости.
Один из сценариев из критерия приемки - Дано, что машина в движении и, когда устанавлена скорость, тогда скорость близка к установленной скорости. Но, если начать рассматривать разные варианты, сценариев становится больше!
Сценарии могут появиться и при рассмотрении use case-ов.
Есть еще методы генерации сценариев - CRC карты, динамические модели, модели состояний, применение персон и т.д.
После того как записаны все сценарии, их надо превращать в тесты. Критерии приемки (и соответсвенно сценарии) определяют приемлемое поведение системы. Тесты приемки унаследованы от критериев приемки и определяют конкретные pass/fail поведения.
Как видно из примера, к сценариию добавились pass\fail данные. И появился первый тест. Тест, который был сформирован из критериев приемки. Тест, который практически написан на Gherkin. Gherkin имеет разные формы представления.
Используя эти Gherkin BDD тесты в связке с Cucumber или FitNess, получим хорошую автоматизацию, которая будет покрывать значительную часть требований к функционалу продукта.
Но надо понимать и осозновать, что как BDD так и TDD не внедряются по щелчку пальцев.
Для этого нужно менять процессы и внедрять еще и пракатику. О том, как это можно организовать, описано в статье.
Резимируя хочется сказать, что в статье описан один из подходов к генерации мощной базы автоматизированных тестов. Но есть множество нюансов и подходов при разработке е2е тестов, UI тестов, в определении SUT (System Under Test) и т.д.
