Текст книги "Agile-тестирование. Обучающий курс для всей команды"

Глава 10. Расширение мысленных установок тестировщика: моя ли это работа?

В предыдущей главе мы затронули тему пересечения бизнес-аналитики и тестирования. Оба эти направления призваны помочь клиенту понять, чего он хочет для каждой конкретной функции. Однако существуют и другие цели. Например, экспертам по созданию пользовательского интерфейса необходимо понимать, как будут использовать продукт люди, какую пользу надеются извлечь из новых возможностей представители бизнеса. Составители технической документации должны знать, как будут работать с системой разные пользователи, чтобы отразить, насколько продукт отвечает их коммерческим и техническим требованиям. Однако члены команды или сотрудники организации могут не обладать необходимыми навыками, поэтому иногда нужно уметь перенять опыт использования полезных методов и техник у других специалистов.

КТО ВООБЩЕ ДОЛЖЕН ЭТО ДЕЛАТЬ?

Как мы говорили в главе 3, Agile-разработки поощряют специалистов широкого профиля с Т-образными навыками. Часто для выявления коммерческих потребностей требуются специалисты с определенными знаниями в конкретной области.

БИЗНЕС-АНАЛИТИКА

Мы все больше осознаем важность навыков, которыми обладают бизнес-аналитики. Они поддерживают диалог с экспертами бизнеса, задают вопросы о критериях продукта. Они понимают все области предпринимательской деятельности, а не только те, что связаны с использованием софта. Традиционно именно бизнес-аналитики помогают коммерческим экспертам донести свои пожелания до разработчиков. Бернис Рухланд рассказала о своем опыте руководящей работы в команде тестировщиков и бизнес-аналитиков. Обычно эти две роли исполняют одни и те же люди. Владение подобными навыками идет на пользу всему коллективу и помогает учитывать как нужды тестирований, так и необходимые требования.

Как и тестировщики, бизнес-аналитики умеют задавать правильные вопросы. Начинают они с вопроса «Зачем?». Многие умеют интерпретировать тесты, основанные на примерах клиента, и, как правило, владеют инструментами, недоступными большинству тестировщиков. Первым делом нужно думать о бизнес-задачах, и, с точки зрения тестировщиков, мы можем слишком рано фокусироваться на их решении. Будучи тестировщиками, мы можем начать думать иначе, чем бизнес-аналитики.

В шкуре бизнес-аналитика

Майк Токс, тестировщик из Новой Зеландии, рассказывает, что когда впервые попробовал записать требования, то концентрировался в большей степени на решении, чем на бизнес-задачах.

Что я действительно поощряю, так это следование идеалам киви[10]10
  Национальное прозвище новозеландцев и часто используемое самоназвание жителей Новой Зеландии. Сформировалось в годы Первой мировой войны в отношении новозеландских военнослужащих на фронтах Европы. Прим. ред.


[Закрыть]. Мне нравится, когда люди пытаются выходить из зоны комфорта внутри своего коллектива. Эта традиция уходит корнями в начало истории Новой Зеландии как колонии. В то время ощущался очевидный недостаток ресурсов и навыков, благодаря чему и зародилась культура воспитания специалистов широкого профиля. Звучит знакомо?

Для одного из проектов, над которым я работал, требовалась предварительная бизнес-аналитика. В своей жизни я протестировал достаточно бизнес-требований, поэтому решил, что это будет просто. Обошел всех по очереди, поговорил с представителями бизнеса и все записал. К сожалению, мои записи должным образом не отражали проблему и были чересчур подробны. За неделю работы, возможно, я научился большему, чем за годы нахождения по другую сторону коммерческих требований. Это помогло мне куда лучше понять моих коллег.

Бизнес-аналитики нашего проекта потом помогли мне и с тестированием. Как и я, они прошли тернистый путь, прежде чем добились нужных результатов. Этот опыт и понимание позволили нам работать более слаженно и осознать, как пересекаются наши обязанности. По моему опыту, самое трудное – достичь верного уровня детализации. Концентрируйтесь на том, что необходимо, старайтесь не притягивать решения за уши. Иначе вы ограничиваете возможности своей команды.

Если ваш коллектив состоит только из тестировщиков, в нем нет бизнес-аналитиков (или наоборот), подумайте, как вы можете восполнить недостающие навыки работников. Команда Лайзы не могла позволить себе бизнес-аналитика, поэтому они создали сообщество по интересам, где все сотрудники во время встреч делились знаниями о бизнес-анализе, которые почерпнули из книг, статей или конференций. Они научились вести диалог с представителями бизнеса и расширили свои представления о критериях качества. (Эту историю полностью читайте в главе 5.)

Обсуждение требований и целей тестирования

Пит Волен делится своими мыслями о связи между выяснением требований и тестированием.

Хорошо знать все требования. Хорошо знать, какие существуют тесты, какие из них запланированы, какие уже проведены. Однако от всего этого будет мало толку, если вы не в курсе, какую задачу должен решить проект. Необходимо понимать, какие бизнес-цели должна решать система.

Порой нет другого способа выяснить некоторые моменты, как только сесть и проговорить все с представителями бизнеса. Если вы подходите к вопросу не глядя свысока, а как бы говоря: «Пожалуйста, помогите мне понять, чтобы я мог помочь вам», – стены рушатся и происходят удивительные вещи: люди начинают более открыто делиться информацией.

Когда программисты, дизайнеры или тестировщики ведут себя как эксперты, точно знающие, как решить проблему, с которой сталкиваются представители бизнеса, это может выглядеть высокомерно. Когда мы подходим к вопросу как коллеги, то можем найти способ объяснить свои решения другим.

Что насчет бизнес-аналитиков?

Хороший бизнес-аналитик может собрать информацию и доступно сообщить ее команде. Однако с каждым уровнем, который проходят те или иные данные, они будут меняться. Иногда что-то упускается или добавляется. «Прояснения» могут в корне изменить суть сообщения. Когда я вникаю в работу других, то часто черпаю для себя что-то, что важно мне как тестировщику, что другие просто отметают за ненадобностью.

Если мне лучше удастся разобраться в требованиях клиента, я смогу более эффективно протестировать ПО. И если тесты, которые я пишу и провожу, не отвечают в полной мере требованиям, нужны ли они вообще? Что они такое: необходимость, моя интерпретация или отголосок чьих-то слов?

Конечно, важнейшие мысли будут отражены в письменных запросах. Могут быть и другие пункты, например: «Не повредить базу данных», «Это должно быть отражено в зависшей системе», «Значение должно соответствовать тому, что появляется на другом экране». Входит ли все это в список ожиданий пользователя? В полной ли мере отражены нужды бизнеса? Ответы я могу получить только из обсуждений.

Совет: практикуйте как требования, так и истории. Если это невозможно, используйте истории, а потом попросите представителей бизнеса пройтись по результатам вместе с вами.

СОЗДАНИЕ ПОЛЬЗОВАТЕЛЬСКОГО ИНТЕРФЕЙСА

Такие компании, как Apple, доказали, насколько важен дизайн продукта. Как заметил Энди Бад (Traynor, 2011), «привлекательные элементы», типа смахивания для разблокировки в айфоне, «заставляют людей влюбляться в продукт». Сегодня дизайнеры пользовательского интерфейса – одни из ключевых фигур в командах разработчиков, работающих по методам Agile.

Тестировщики плодотворно сотрудничают с дизайнерами с самых ранних стадий, особенно те, что непосредственно контактируют с конечными пользователями или сами используют продукт, дают дельные советы относительно моделей пользовательского интерфейса, рабочих процессов и других вопросов дизайна. Хорошие дизайнеры знают, как извлечь пользу из юзабилити-тестирования, и всегда рады поработать с тестировщиками. Некоторые действия, связанные с юзабилити, одинаковы как для дизайнеров, так и для тестировщиков. Среди них A/B-тестирование, создание фокусных групп и моделей на бумаге.

Методы планирования, например схемы влияния, помогают лучше понять, что нужно бизнесу. Мы не знаем, как был создан айфон, но можем представить пример схемы влияния для его разработки.

• Зачем (цель): получить 70 % рынка.

• Кто (люди): будущие и существующие пользователи айфонов.

• Как (характеристики): простой способ разблокировки телефона, в который влюбятся пользователи.

• Что (действия/свойства): создание смахивания для разблокировки.

После этого команда (включая тестировщиков, конечно) может устроить мозговой штурм для определения других действий и характеристик, которые поспособствуют достижению цели.

История Лайзы

У нас в команде был один дизайнер пользовательского интерфейса. Он работал удаленно и был нарасхват в коллективе из двадцати разработчиков. Когда мы наняли второго специалиста в офис в Денвере, перед тестировщиками открылись новые возможности.

Один из тестировщиков как-то предложил собраться на мозговой штурм троим его коллегам и обоим дизайнерам и обсудить тему «Необходимость дизайна до начала производства».

Мы стали пытаться применять некоторые решения, к которым пришли. В их числе были:

• Совместное рассмотрение функций дизайна в историях. Заострение внимания на произошедших изменениях (например, из-за внедрения ограничений) в комментариях историй.

• Совместная работа дизайнеров и тестировщиков над приемкой историй, включающих внедренные свойства.

• Большее вовлечение тестировщиков в проверку взаимодействий и выбор дизайна.

Эти эксперименты помогли сократить время, которое тратилось на переделывание пользовательского интерфейса после начала программирования. Если мы работаем сообща, UAT проходит более гладко, поскольку дизайнеры могут сразу заметить ошибки в шрифте или цвете. Даже когда мы не работаем непосредственно вместе, дизайнеры всегда сразу отвечают на вопросы, так что мы никогда не буксуем.

Мы, тестировщики, со своей стороны помогли дизайнерам доработать скрипты их практичных тестов. Благодаря опыту и экспертному мнению дизайнеров в области тестирования простоты использования мы получили полезную обратную связь от пользователей нашего продукта на ранней стадии процесса разработки. С дизайнерами было проще тестировать пользовательский интерфейс. Как только мы выпустили бета-версию, сразу получили позитивный отклик от клиентов.

Если у вас в команде нет специалистов по дизайну пользовательского интерфейса или юзабилити-тестированию, вы можете овладеть этими навыками в достаточной степени, чтобы получать ценную обратную связь от пользователей. Примеры юзабилити-тестирования вы найдете в главе 13.

СОСТАВЛЕНИЕ ДОКУМЕНТАЦИИ

Многие команды по-прежнему нуждаются в ведении пользовательской документации в электронном формате или на бумаге. Если вы один из тех счастливчиков, чья команда плотно сотрудничает с разработчиками технической документации, возможно, вам известно, насколько ценны эти специалисты. Разработчики технической документации находятся в том уникальном положении, что могут критиковать идеи, когда бывает не так просто проговорить концепцию, как казалось.

Если у вас нет специалиста по технической документации, но ее разработка входит в ваши обязанности, не забывайте добавлять задачу «Создать контент» для каждой истории. С этим может справиться любой сотрудник. На уровне функционала задача может быть сформулирована так: «Заполнить пользовательскую документацию». К этому моменту пользовательский интерфейс стабилен, так что при необходимости можно сделать скриншот. Контент может быть собран, отредактирован любым человеком из команды или разработчиком технической документации.

Можно скооперироваться с другими членами коллектива. Например, когда я тестировала всестороннюю онлайн-документацию для программного интерфейса, Лайза работала не с разработчиком технической документации, а с дизайнерами пользовательского интерфейса.

ПРОЯВИТЕ ИНИЦИАТИВУ

Прелесть размытых ролей внутри Agile-команд в том, что это делает работу более интересной. Если вы чувствуете, что ваша команда или клиенты изо всех сил пытаются определиться со свойствами, влезьте в шкуру другого человека. Что из области другой профессии вы могли бы применить?

История Лайзы

Много лет я работала в команде, которая производила ПО для финансового обслуживания. С помощью нашего софта можно было управлять нюансами пенсионной программы 401(k). Система изначально была смоделирована так, чтобы только один человек от каждого работодателя – участника программы мог авторизоваться как администратор. Это «ответственное лицо» подтверждало отчисления в пенсионный фонд, вносило в программу новых сотрудников, одобряло распределение доходов и займы.

Термин «ответственное лицо» применялся на сайте. С одной стороны, мы запустили эту опцию, чтобы позволить нескольким пользователям выступать в качестве ответственного лица. Однако по закону ответственное лицо – это работодатель. Мы много раз обсуждали терминологию и никак не могли прийти к единому мнению.

Наконец, чтобы принять окончательное решение относительно терминологии, я назначила встречу с представителями всех заинтересованных сторон. Разве собирать людей с такой целью – это работа тестировщика? А почему бы и нет? Наш специалист по Scrum был болен, а руководитель продукта постоянно завален работой. Разработка уже началась, а мы все еще прозябали в неопределенности и только трепали языками.

Через пятнадцать минут руководители бизнеса согласились с термином «ответственный администратор» для обозначения всех пользователей от конкретного работодателя, которые будут авторизоваться и действовать как ответственное лицо. По-прежнему для каждой программы оставался лишь один администратор, имя которого отображалось во всех документах.

Поскольку руководитель продукта был слишком занят, я смоделировала изменения на всех страницах сайта, где до того времени использовалось выражение «ответственное лицо». Я внесла все изменения в вики-страницу, чтобы наш удаленный программист (работающий в Индии) увидел их и добавил карточки задач в соответствующие ряды историй на доске. К следующему утру программист внес большинство изменений, а другой завершил его работу. Я проверила изменения, показала их клиентам и запустила автоматизированное регрессионное тестирование.

Да, было бы лучше определиться с терминологией перед тем, как запустить историю. После этого и еще нескольких подобных случаев мы начали активнее требовать конкретики во всех правилах и примерах, которые должны быть готовы до запуска соответствующего этапа. Если у нас не было достаточной информации, мы откладывали историю до следующего этапа. Мы понимаем, что вопросы и изменения во время разработки неизбежны. Но если мы можем найти способ двигаться дальше, сэкономить время и повысить качество, нужно передать инициативу тому, кто способен протолкнуть подобные действия.

Многие навыки, которыми обладают бизнес-аналитики и дизайнеры пользовательского интерфейса, на самом деле относятся к тому, что мы называем «тестирование бизнес-ценности». Критика идей, их тестирование и проверка предположений приближают нас к разработке именно тех свойств, которые нужны клиенту. В следующей главе мы поговорим о том, где взять примеры для выражения общего понимания. Она посвящена правильной разработке.

РЕЗЮМЕ

Размытие границ между ролями может сделать нашу работу интереснее. В этой главе мы говорили о расширении кругозора и способности учиться у других.

• Проведите мозговой штурм с командой, чтобы определиться, каких навыков вам, возможно, не хватает.

• Попробуйте поэкспериментировать. Освойте новые навыки, чтобы заполнить пробелы. Попробуйте себя в роли другого специалиста, если это необходимо.

• Навыки бизнес-аналитиков пересекаются с умениями тестировщиков. Если в вашей команде есть и те и другие, позвольте им работать вместе для повышения качества продукта.

• Тестировщики могут объединиться с дизайнерами пользовательского интерфейса для юзабилити-тестирования, создания прототипов и получения быстрой обратной связи от пользователей. Это экономит время и помогает оставаться в курсе происходящего.

• Все члены команды могут примерить обязанности разработчика технической документации, если в этом есть необходимость, могут создавать контент, пытаться изложить концепции словами и, возможно, даже редактировать и тестировать пользовательскую и техническую документацию.

• Учитесь у других профессионалов, таких как бизнес-аналитики и дизайнеры пользовательского интерфейса, чтобы учитывать множество критериев качества при создании софта.

• Когда сталкиваетесь с проблемой, проявляйте инициативу. Собирайте вместе нужных людей и обсуждайте возможные решения.

Глава 11. Примеры

По нашему опыту, получение примеров от клиентов помогает в разработке как с технологической стороны, так и с точки зрения бизнес-ориентированных тестов. Примеры составляют суть квадратов 1 и 2, будь то прототипы на бумаге, диаграммы потоков, нарисованные на доске, или листки с вводными и ожидаемыми результатами. Один из любимых вопросов, который мы задаем, если не совсем понимаем, о чем идет речь, это: «Можете ли привести пример?». Надеемся, вы поступаете так же.

СИЛА ПРИМЕРОВ

Впервые о разработке, основанной на примерах, мы узнали от Брайана Марика еще в 2003 году. В первой книге мы говорили, как важно работать с клиентом для получения примеров желательных и нежелательных характеристик системы, чтобы знать, что именно нужно заказчику.

Примеры в реальной жизни

История Шерри Хейнц, тестировщика из Канады, показывает, как мы можем пользоваться примерами каждый день.

Я работала над штатным расписанием для одного клиента, контора которого во время праздников закрывалась на четыре полных дня и на два дня частично. Руководство выслало расписание на выходные в формате таблицы. Один из менеджеров, в чьем подчинении были как сотрудники, так и подрядчики, прислал мне копию расписания с пометкой помочь людям правильно отметить их время окончания работы.

Записка: «Обычно компания работает по 7,5 часа каждый день с понедельника по четверг и 7 часов по пятницам.

При вводе времени в праздничные дни, пожалуйста, ознакомьтесь с таблицей ниже. В дни, когда офис закрыт (не считая общенациональных выходных), будьте добры отмечать время согласно этому административному коду. В противном случае будет считаться, что вы в отпуске или часы будут оплачиваться по стандартной ставке.

Если вы подрядчик, пожалуйста, вводите время только в офисе и не используйте административный код. В часы, когда офис закрыт, введенное время для подрядчиков должно быть 0».

Учет времени

Я посмотрела на таблицу и задала пару уточняющих вопросов, поскольку начинала работать в 7:00 и была подрядчиком.

• Значит ли это, что мне не оплатят обычные 6 часов 24 декабря?

• Если так, то должна ли я уйти с работы в 11:30, чтобы отработать лишь 4,5 часа?

• Вы хотите, чтобы 24 декабря все пришли на работу к 9:00?

• Значит ли это, что я не могу работать дома в этот день, как я обычно делаю, если школы закрыты?

• Что, если я сотрудник, который работает в группе поддержки и должен начинать раньше, чтобы принимать телефонные звонки?

Так я выяснила, что человек, составивший эту таблицу, руководствовался тем, что все начинают работу в 9:00 и работают только в офисе.

История Шерри показывает, как простая таблица может стать отправной точкой для вопросов, которые помогут достичь понимания тех или иных функций.

Функциональные тесты стали куда более продвинутыми за последние несколько лет, и теперь с их помощью легче выявить и автоматизировать примеры. Это хорошо, конечно, но можно компьютеризировать кучу тестов и все равно не учесть истинные желания клиента.

В своих записях к Agile-testing Days в 2003 году Джей Би Рейнзбергер заметил, что многие команды до сих пор не «проговаривают примеры» (Rainsberger, 2013). С ним согласна и Лиз Кеог (Keogh, 2012):

Говорить

важнее, чем собирать данные,

важнее, чем автоматизировать общение.

Многие команды для описания характеристик свойств без углубления в детали их реализации используют понятный бизнесу специфический язык (Domain-specific Language, DSL), зачастую в формате given_when_then. Эту технику можно использовать в скриптах автоматизированных тестов, но еще более полезна она как аналитический инструмент. Сотрудничество с клиентами в создании примеров в стиле given_when_then помогает определить полезные истории подходящего размера, которые по завершении образуют нужные свойства. Автоматизация становится полезным побочным эффектом использования этого инструмента.

Если ваша команда пока не готова работать с представителями заинтересованных сторон для получения примеров желательных и нежелательных характеристик системы, начните применять этот метод. Посмотрите, поможет ли он скорее определить, чего хотят клиенты, и разработать то, что нужно, с меньшими потерями и за более короткий срок. Джанет сравнивает это с правилом большого пальца: если у вас больше одного примера желаемых характеристик, может понадобиться и более одной истории.

Мы решили посвятить целую главу поиску примеров, потому что это невероятно действенный метод, до сих пор не использующийся многими командами. К сожалению, так же мало употребляется и термин «разработка на основе примеров». Подобные названия обычно применяют для обозначения:

• разработки на основе приемочного тестирования (Acceptance-test-driven development, ATDD);

• разработки через поведение (Behavior-driven development, BDD);

• спецификации на основе примеров (Specification by example, SBE).

В «Гибком тестировании» мы говорим об этих тестах как о бизнес– или клиентоориентированных, которые направляют разработку по пути, схожему с TDD, но только применяются на уровне коммерческой деятельности. Они помогают определить внешние качества на основе необходимых клиенту свойств. Здесь мы обобщенно называем этот метод «разработкой на основе примеров». Вы можете использовать любой из терминов, принятый в команде. Мы пытаемся объяснить разницу, но на самом деле начинать следует с примеров и их обсуждения.

Выбор того или иного инструмента определяет метод, который вы применяете. Поэтому мы рекомендуем выяснить, чего же вы хотите, до того как приступать к выбору инструмента. Например, в приложениях рабочих процессов могут быть полезны описания характеристик. Если приложение предназначено для расчетов, больше толку будет от электронных таблиц или тестов в виде таблиц с конкретными примерами. Мы приводим примеры обоих форматов в главе 16.

РАЗРАБОТКА НА ОСНОВЕ ПРИМЕРОВ

Разработка на основе примеров

Пусть вас не сбивают с толку термины и жаргонные выражения. Как бы вы ни назвали свои процессы (ATDD, BDD, SBE), цель одна – достичь взаимопонимания для создания того, что нужно. Все они протекают по схожей схеме, показанной на рисунке выше. Правда, есть некоторые отличия в названиях. Главное, о чем следует помнить: всегда начинайте с конца.

РАЗРАБОТКА НА ОСНОВЕ ПРИЕМОЧНОГО ТЕСТИРОВАНИЯ (ATDD)

Дженнита Андрэа описала ATDD (Andrea, 2010) следующим образом:

«…Метод выражения функциональных характеристик истории на конкретных примерах или ожиданиях до запуска в разработку. Во время разработки истории процесс сотрудничества подразумевает запись и автоматизацию примеров, разработку гранулированных автоматизированных модульных тестов, написание и интеграцию системного кода в действующее рабочее ПО. История «завершена» – условно готова к исследовательскому и другим видам тестирования, когда эти автоматизированные проверки определены и пройдены».

Проблема формулировки «разработка на основе приемочного тестирования» состоит в том, что термин «приемочное тестирование» довольно размытый и для каждого имеет свое значение. Его можно спутать с пользовательским приемочным тестированием (User Acceptance Testing, UAT), когда продукт принимает конечный пользователь или внешний поставщик. Оно также может быть связано с оплатой работ подрядчика.

Мы определяем приемочные тесты как описывающие бизнес-цели, которые должны быть достигнуты. В зависимости от того, как ваша команда применяет метод, приемочные тесты могут включать только ожидаемые характеристики высокого уровня и пару примеров сбоев. Однако они также могут содержать широкий спектр тестов, охватывающих все, кроме разработки на основе тестов на уровне модулей и компонентов. Сюда могут входить качественные свойства, такие как юзабилити и производительность, хотя мы и предпочитаем рассматривать их как условия, применимые ко всем историям. Говоря о разработке на основе приемочного тестирования, многие имеют в виду функциональные тесты.

Повышение эффективности через диалог в Paddy Power

Августо Евангелисти, профессиональный разработчик софта в Ирландии, рассказывает о том, как строится диалог в его компании.

Я устроился в Paddy Power ведущим инженером-тестировщиком в 2012 году, и мои задачи были ясны с первого разговора с руководителем. В тот день он фактически сказал мне что-то типа: «Гус, ты должен повысить качество, не снижая объемов производства». Хотя задача была непростой, мне и раньше приходилось сталкиваться с подобным, поэтому я не испугался (глупец!).

Я начал изучать коллектив, чтобы понять, что где можно улучшить. Команды состояли из превосходных разработчиков, использующих отличные методы. У них было очень высокое покрытие кода юнит-тестами, замечательная система непрерывной интеграции (CI), проводились код-ревью, парное программирование.

Они даже применяли разработку на основе приемочного тестирования (ATDD). И вот тогда я испугался. Я продолжал изучать тему, копал глубже, чтобы понять, чего же не хватает. Первым моим предложением было взять в команду бизнес-аналитика. Раньше эти специалисты работали отдельно. Это было маленькое изменение, которое немного помогло, но я все еще совершенно не понимал, что могло быть не так.

Прошло еще несколько недель. Медленно, но верно я начал понимать, в чем проблема, почему у нас довольно много сбоев в приемочном пользовательском тестировании и даже в живой среде. Ключевым моментом стало изучение того, как осуществлялась разработка на основе приемочного тестирования. На доске Kanban записывалась колонка «Ожидает подтверждения бизнес-аналитиков», и после этого начиналось проектирование. Фактически пользовательские истории передавались от бизнес-аналитиков разработчикам посредством простого подтверждения, в то время как аналитики переходили к работе над следующей пользовательской историей. Диалога не было. Разработчики брали пользовательские истории и переводили их в то, что, как они полагали, было приемочными тестами или соответствующим кодом.

Мне повезло, что я нашел верного союзника в лице Мэри, тоже инженера-тестировщика, желающего улучшить положение вещей. Мы вместе работали над определением масштабов проблемы и составляли схемы влияния в поисках возможных выходов из ситуации. Мы решили провести мастер-классы для разработчиков по настоящему проекту на основе приемочного тестирования.

Мы адаптировали наш метод к условиям компании, используя советы Элизабет Хендриксон и спецификацию, руководствуясь примерами Гойко Аджича. Главной целью было подчеркнуть важность некоторых критериев.

Диалог об автоматизации

Мы сказали командам, что главное в ATDD – это люди, общение, сотрудничество и достижение бизнес-целей.

Мы направили все усилия в это русло и объяснили, что автоматизированные регрессионные наборы тестов, созданные по ходу процесса, – не что иное, как естественный результат. Все дело в совместном определении пользовательских историй, общем понимании сути приложения и донесении бизнес-ценности до клиентов.

Чтобы прийти к общему определению пользовательских историй, мы заменили колонку «Ожидает подтверждения бизнес-аналитиков» колонкой «Обсуждение», где «три друга» сидели вместе и говорили о пользовательских историях, выявляя примеры, которые позднее станут приемочными тестами, кодом и бизнес-ценностями. Я думал, это прекрасный пример совместной работы с клиентом над обсуждением условий.

Мастер-классы оказались продуктивными и действительно помогли изменить подход. Уже через несколько недель разработчики внедряли новый метод, который давал моментальные измеримые результаты.

Спустя год достижения были превосходными. Проблем с UAT, как и с продакшн, почти не возникало. Команды действительно понимали, что за продукт они производят. Бизнес-аналитики, инженеры-тестировщики и разработчики работали слаженно, как единое целое. Нам даже удалось нарастить объемы производства, потому что отпала необходимость переделывать что-то из-за ненадлежащего качества. Недопонимания, которые раньше возникали на этапе UAT, теперь обнаруживались и устранялись еще до того, как была написана хотя бы одна строка кода.

Да, чуть не забыл: работа доставляла нам невероятное удовольствие!

РАЗРАБОТКА ЧЕРЕЗ ПОВЕДЕНИЕ (BDD)

BDD использует обычный язык, чтобы передать примеры клиента в специфических терминах. Суть в том, чтобы обсудить важные вопросы и создать сценарий given_when_then, который отражал бы характеристики свойств, включая ожидания для определенных условий и действий, в тестах, доступных для понимания всей команде.

Определение BDD Дэна Норта несколько сложнее (North, 2006), но мы привыкли использовать слово «характеристики» вместо «тестов» и применять метод given_when_then для описания начальных условий, ограничений и постусловий того, что важно, до начала программирования. В сообществе Agile-тестировщиков на Yahoo Лиз Кеог объяснила (Keogh, 2010):

«Суть BDD в том, чтобы изучить неизвестное. Особенно это касается сценариев и примеров. Именно здесь появляются слова вроде «должно» и «поведение» вместо обычного «тесты», потому что для большинства людей «тесты» подразумевают, что мы знаем, какое поведение ожидаем от системы. “Должно” позволяет задать вопрос: “Должно ли?”. Существуют ли обстоятельства, которые мы упустили, в которых система будет вести себя иначе?»

Как таковой ответ для TDD и BDD трансформировался в анализ и автоматизированные тесты на приемочном уровне. Внедрение свойств – это фреймворк процессов бизнес-аналитики, который направляет TDD и BDD на объяснение бизнес-ценности (Matts and Adzic, 2011). Команды начинают с определений и проговаривания бизнес-ценностей, создают список необходимых элементов для их обеспечения, а потом расширяют масштаб этих свойств, изучая примеры высокого уровня, которыми пользуется клиент. Чуть дальше в этой главе мы приведем примеры тестов BDD.

СПЕЦИФИКАЦИЯ НА ОСНОВЕ ПРИМЕРОВ (SBE)

После мастер-класса AA-FTT в 2010 году Деклан Уилан, Гойко Аджич и еще несколько специалистов в попытке достичь единого мнения в вопросе спецификации на основе примеров представили диаграмму.

Посмотрев на нее внимательно, вы заметите, что здесь ни разу не упоминается тестирование как таковое. SBE начинается с постановки цели о создании функционала. Техники вроде составления схем влияния для начала позволяют определить правильные цели. Чтобы добраться до ключевых примеров, которые бы всесторонне объясняли условия, команда должна работать сообща. Возможно проведение специальных мастер-классов или похожих мероприятий. Ключевые примеры становятся высокоуровневым приемочным тестированием. Мы пересматриваем их, извлекаем минимальные наборы свойств, чтобы должным образом обозначить бизнес-стандарты. Это превращается в тестирование историй. На данном этапе мы проводим автоматизацию, не прибегая к подмене понятий, и эти автоматизированные тесты становятся проверками, которые дают быструю обратную связь в обычных условиях. В результате мы получаем выполнимые спецификации или документацию, описывающую функционирование системы на любом отрезке времени.