Идея данной статьи пришла ко мне когда я начал работать в новом стартапе chous.ai. Так как, у нас объеденен отдел ручного и автоматизированного тестирования, остро стал вопрос унификации тестовой документации. Так как в автоматизации мы используем BDD, возникла идея перенести этот опыт и на ручное тестирования, заменив тест-кейсы сценариями. Так как найти серьезной документации по этой теме на русском языке я не смог, написал данную статью, подробно описывающую имплементацию подходов TDD и BDD к QA процессу.
Тестирование на ранней стадии, например, во время написания кода – это когда-то инновационная идея, все больше приживается в массах, так как приводит к значительному повышению качества кода. Напишите тесты заранее – и вы имеете шанс выиграть "кристаллическую звезду" победителя галактического первенства. Кроме того, возможности для проверки функционирования кода и его предварительной отладки, без всякого сомнения, повышают скорость разработки.
Но даже зная все это, мы еще очень далеки от того времени, когда написание тестов до-написания кода станет общим стандартом. Точно так же как TDD стало следующим этапом эволюции развития экстремального программирования (eXP) и выдвинуло на первый план инфраструктуру для unit-тестирования, следующий скачок эволюции был сделан с того уровня, где находится TDD. В этом случае эволюционировали от TDD к его интуитивному родственнику: behavior-driven development (BDD) – разработке, основанной на функционировании. Но давайте обо всем по порядку.
Разработка через тестирование - TDD
Разработка через тестирование (англ. test-driven development, TDD) - это современный стандарт разработки программного обеспечения, который основывается на повторении очень коротких циклов разработки: сначала пишется тест, покрывающий желаемое изменение, затем пишется код, который позволит пройти тест, и под конец проводится рефакторинг нового кода к соответствующим стандартам. Кент Бек, считающийся изобретателем этой техники, утверждал в 2003 году, что разработка через тестирование позволяет быть уверенным продкутивности своего кода, что в конечном счете уменьшает общее время разработки. В 1999 году при своём появлении разработка через тестирование была тесно связана с концепцией «сначала тест» (англ. test-first), применяемой в экстремальном программировании, однако позже выделилась как независимая методология. В основе лежит unit-Тест это программная процедура, которая позволяет либо подтвердить, либо опровергнуть работоспособность кода. Технику TDD легко представить данной схемой:
Теперь я более подробно объясню как это работает:
1. На основе спецификации, мокапов и другой исходной документации пишется тест. Для программы которая еще даже не написана. Если запустить такой тест, логично, что он упадет.
2. Программист пишет код, создает программу, при этом тест будет индикатором. Как только тест будет пройден - код готов.
3. Рефакторинг. Тест доделывается/переделывается в результате изменившихся требований, добавляются новые параметры если нужно. Редко когда фича принимается с первого раза.
Данный цикл может повторятся n раз, до того как программа не достигнет желаемого состояния.
Разработка, основанная на поведении
После того как мы узнали, что современные методики разработки объединяются с тестированием образуя TDD. Далее TDD эволюционировало образовав BDD (behavior-driven development) или разработка через поведение. Скорее всего вас уже запутали эти аббревиатуры и все слилось в сплошное BDSM.
Но давайте обратимся к мнению экспертов.
Мэтт Уинн, один из разработчиков интерпретатора BDD для фреймворка Cucumber Limited передает суть технологии так:
«Практикующие BDD исследуют, обнаруживают, определяют, а затем воплощают это поведение программного обеспечения, используя общение, конкретные примеры и автоматизированные тесты».
Спустя большое количество проб и ошибок команды пришли к пониманию, что нужен подход который объединит тестировщиков, программистов, продактов, бизнес-аналитиков, заказчиков и даст им документацию которую использует и понимает каждый. Давай посмотрим как это BDD интегрируется в схему TDD.
В подходе BDD нет ничего революционного. Это просто эволюционное ответвление подхода TDD, где слово "тест" заменено словом "должен". Если отложить в сторону слова, то многие найдут понятие "должен" более естественным для процесса разработки, чем понятие "тест". Мышление в терминах функциональности (того, что код должен делать), приводит к подходу, когда сначала пишутся классы для проверки спецификации, которые, в свою очередь, могут оказаться очень эффективным инструментом реализации.
Как вы уже сам выяснили, подход BDD состоит в том, чтобы попытаться выяснить, что ваш клиент или бизнес хочет от программного обеспечения, прежде чем начать работать над ним. Первый способ сделать это - фактически сотрудничать с этими людьми.
Как только мы получим это сотрудничество, нужно как-то записать то, что имеет смысл для любого, кто его просматривает, так чтобы любой мог прийти и посмотреть на него позже, понять, и если он захочет, прокомментировать его. Чтобы достичь этого, нужно использовать общепонятный язык.
Люди часто используют слова "Given", "When", "Then", "And" (рус. "Дано", "Когда", "Тогда", "И"), для того чтобы построить цепочку логических рассуждений. Так давайте же применять эти слова, как ключевые для построение наших тестов понятных всем.
Итак, наш тестовый документ будет будет называться сценарием и будет использовать только ключевые фразы для каждого шага. В начале мы дадим перевод, но далее будет использовать только английские фразы. Наш сценарий будет строится по такой структуре:
GIVEN <context> Дано <контекст или исходное состояние>
WHEN <event> Когда <событие>
THEN <outcome> Тогда <результат>
Как это работает:
Дано <я привожу тестируемую систему в исходное состояние для теста>
Когда <Я произвожу действие>
Тогда <Я проверяю результат>
А теперь пример:
GIVEN Я залогинен в систему как пользователь
WHEN Я открываю список входящих сообщений
THEN Я вижу 20 последних сообщений.
Спасибо, за внимание, более полную версию темы вы можете найти в уровне 16 системы обучения Galaxy QA Academy. Возможно отдельное приобретение доступа к теме. Для этого свяжитесь с нами.