Статья публикуется от имени Трубанова Вадима, @vonaburt
Методология BDD все чаще завоевывает внимание IT-индустрии как логически верная ступень развития традиционных подходов к тестированию проектов, в том числе подходов к автоматизации тестирования. Текущая эпоха информационных технологий диктует свои правила, и в этой гонке технологий выигрывает тот, кто умеет реагировать на любые изменения быстро и качественно. Особенно это касается компаний связанных с банковской деятельностью, например таких, как наш банк, где каждый отложенный час до релиза может повлиять на общую картину качества сервисов, составляемую нашими клиентами. При правильном использовании методология BDD позволяет сократить время, затрачиваемое на тестирование выпускаемых продуктов, повышать качество проводимого тестирования и делать сам процесс прозрачным и понятным для всех, что и подтолкнуло нас к её использованию. На данный момент методология BDD внедряется на двух наших web-продуктах, активно развивается и уже приносит свои плоды. Хочется поделиться нашим опытом внедрения BDD со стороны автоматизации тестирования и рассказать об основных принципах, которые позволят вам внедрить эту методологию безболезненно, быстро и, самое главное, сделать её использование эффективным.
1. Стройте хороший и удобный фреймворк
Фреймворк, на котором впоследствии будут писаться BDD-кейсы — это сердце всей методологии, её главный элемент. Именно поэтому фреймворку должно быть отведено повышенное внимание. Это ваша стартовая точка. Наше решение написано на Java и основывается на библиотеке jBehave. Так как BDD используется на web-проектах, без Selenium WebDriver никуда. При использовании PageObject-паттерн большая роль отводится работе с элементами и страницами. В качестве генератора отчетов выбран Serenity. Назовем три очевидных главных принципа, которые обязательно должен соблюдать ваш фреймворк. Во-первых, он должен быть надежным. Не пожалейте времени и напишите хорошее ядро проекта. Непотраченные 30 минут работы могут обернуться вам часами простоя вашей BDD-команды. Во-вторых, фреймворк должен быть максимально удобен для использования. Основные пользователи фреймворка не вы, и не команда автоматизаторов! Фреймворк должен быть дружелюбен, приятен и понятен тем, кто собирается писать на нем свои BDD-кейсы. В-третьих, фреймворк должен быть гибок. Возвращаясь к реагированию на быстрые изменения, понимаешь —неизвестно, как тестируемый проект изменится завтра. Изначально стройте свой BDD-фреймворк так, чтобы всегда сохранялась возможность перестроить основные механизмы работы фреймворка.
Хороший фреймворк BDD-автоматизации связан со следующими понятиями:
- механизм написания BDD-кейсов;
- механизм запуска BDD-кейсов;
- работа с тестовыми данными.
Все три перечисленных пункта должны быть максимально удобными для пользователей фреймворка. Помните, что пользователи — не разработчики, и очевидные для вас, разработчиков, вещи, могут быть далеко не очевидными для них.
Механизм написания BDD-кейсов довольно прост. Каждому пользователю фреймворка устанавливается IDEA Intellij CE, к ней устанавливается плагин, дающий пользователю возможность автодополнения имеющихся BDD-инструкций. Практически каждой инструкции прописаны свои алиасы, позволяющие пользователям писать свой кейс так, как им удобно.
Большинство инструкций имеют параметры: наименования страниц, элементов, сохраненные ранее значения, функции. Все они позволяют сделать кейсы гибкими и эффективными.
Наверняка многие задавались вопросом, как сделать работу с элементами, их локаторами, коллекциями элементов, страницами с элементами удобнее и прозрачнее. Мы остановились на описании полной иерархии страниц и их элементов. Такой подход должен быть знаком всем, кто использовал в своих проектах паттерн PageObject. Весь портал делится на страницы, внутри которых описываются все находящиеся на них элементы. Повторяющиеся блоки страниц вынесены в «виджеты» или «подстраницы», например, такие как «Меню» или «Правый борд». На данный момент мы храним более 2200 локаторов элементов главного портала банка и более 1000 элементов портала для юридических лиц, и эти цифры неугомонно растут с выходом все нового и нового функционала. Автоматизаторы и функциональные тестировщики, задействованные в методологии, задаются вопросом — как работать с таким большим количеством элементов? Выход был найден: написать свой плагин для IDEA Intellij, распарсивающий файл с данными в древовидную структуру и дающий возможность добавлять и редактировать новые страницы и элементы.
Инструкции построены таким образом, чтобы предварительно «загрузив» определенную страницу, пользователь мог работать со всеми элементами загруженной страницы. Благодаря этому пользователи нашего фреймворка избегают путаницы с выбором необходимого элемента, страницы или виджета.
Для увеличения возможностей BDD-инструкций нами реализован следующий функционал:
- возможность писать собственные маленькие вспомогательные скрипты (например, для получения рандомного значения, вычисления математических операций и тд.) как в теле инструкции, так и в переменных блока «Meta»;
- возможность сохранять необходимые значения в переменные и далее эти переменные использовать.
<!-- генерация рандомных значений и их сохранение в переменных >
Meta:
@profile #{AutoPayments}
@region г. Москва
@code 916
@phone #{random{1000000,9999999}}
@sum #{random{100,200}}
@sum2 #{random{100,200}}
@level 150
@level2 600
@limit #{random{650,999}}
@limit2 #{random{650,999}}
@dateStamp #{now(ddMMyy HHmmss)}
@preName EditMAP
<!--использование скрипта получения значения>
When в переменной "name" сохранено значение "#{script{ String temp = "#{preName}" + " " + "#{dateStamp}"; RESULT = temp}}"
<!-- использование сохраненных переменных>
When нажатием на кнопку "Наименование" загружена страница "Платеж"
When заполняются поля:
|field|value|
|Номер телефона с определенным провайдером|#{code} #{phone}|
|Название платежа|#{name}|
|Сумма|#{sum}|
|Нижний уровень баланса|#{level}|
|Месячный лимит|#{limit}|
Запуск BDD-кейсов реализован с помощью Apache Maven и доработанного стандартного StoryRunner`a, позволяющего запускать BDD-кейсы в многопоточном режиме. Функциональщики могут запустить необходимые тесты прямо со своих рабочих машин и просматривать ход выполнения тестов. Все автотесты запускаются через TeamCity, вручную — довольно редко.
Тестирование и автотестирование тесно связаны с тестовыми данными (ТД). Это один из фундаментальных столпов любого процесса обеспечения качества. Качественные тестовые данные и их грамотное использование позволит вывести тестирование на новый уровень. Возвращаясь к BDD-инструкциям: именно через них пользователь BDD-фреймворка будет передавать тестовые данные. «Хардкодить» тестовые данные прямо в инструкциях — моветон, обрекающий на сложности в актуализации ТД. В итоге, перед нами стояла задача:
— вынести хранение ТД в единое место хранения;
— реализовать возможность удобной работы с хранящимися ТД в BDD-инструкциях;
— реализовать возможность удобной актуализации ТД и контролем над ними;
Как мы ее решили:
— все тестовые данные занесли в БД;
— реализовали внутреннее тестовое API, позволяющее работать с данными в БД;
— реализовали механизм работы с тестовым API внутри BDD-фреймворка в формате инструкций;
— создали web-портал, дающий пользователям фреймворка интерфейс для непосредственной работы над актуализацией, пополнением и редактированием тестовых данных;
Web-портал для работы с тестовыми данными написан на скаловском Play, разделен на наши web-проекты, в которых применяется BDD-автоматизация. Также есть внутреннее деление по категориям тестовых данных: поля, значения, их параметры корректной/некорректной валидации, тестовые пользователи.
Тестовые пользователи пополняются за счет реализованного механизма генерации тестовых данных, о деталях которого, возможно, будет отдельная статья. Механизм позволяет проводить тестирование на клиентах с любым набором продуктов и с любыми необходимыми параметрами.
Именно так, на наш взгляд, выглядит краткое описание необходимых технических элементов удобного и эффективного BDD-фреймворка. Кратко резюмируя: не забывайте о том, для кого вы пишете BDD-фреймворк, как вы будете работать с элементами страниц, как пользователь будет взаимодействовать с инструкциями и тестовыми данными.
Возможно, мы расскажем подробнее о фреймворке отдельной статьей.
2. Настраивайте environment у сотрудников
После того, как фреймворк написан или находится в завершающей стадии написания, пора задуматься о том, как пользователи вашего BDD-фреймворка будут работать с ним. Выдача необходимых прав для установки ПО и сетевых доступов может обернуться эпопеей с туманным будущим во многих крупных компаниях. Благо, бюрократические проволочки в нашей компании минимальны, и мы смогли в быстрые сроки установить все необходимое ПО выбранной группе будущих BDD-автоматизаторов. Конечно, иногда возникали специфические проблемы, но и они быстро решались. Для коллег из аутстафа/аутсорса было найдено простое и эффективное решение в виде заранее подготовленных виртуальных машин с полным необходимым «боевым набором», которые к тому же быстро «размножались» при необходимости. При возникновении любых проблем всегда можно зайти на виртуальную машину и посмотреть, в чем дело.
Мораль этой краткой, но очень важной главы: заранее позаботьтесь о том, как будущие пользователи вашего BDD-фреймворка будут с ним работать, будь то полная установка необходимого ПО на локальных машинах или предварительная настройка и последующее копирование виртуальных машин с фреймворком. Чем быстрее ваши коллеги начнут пользоваться фреймворком, тем быстрее вы получите от них долгожданный фидбек, который будет особенно полезен в начале развития BDD-автоматизации.
3. Выстраивайте рабочие процессы. Варианты использования методологии
Без выстроенных рабочих процессов автоматизация по BDD-методологии вряд ли будет приносить пользу. Тут стоит рассказать о том, как вы можете встроить использование этой методологии у себя на проектах. Варианты довольно гибкие и зависят от того, насколько вы хотите вовлечь всех участников процессов разработки искомого продукта. Возможно, это будет начальный неполный вариант с привлечением только тестировщиков и автоматизаторов. В этом случае вы выиграете время за счет удаления «прослойки» между вашими автоматизаторами и функциональными тестировщиками в виде тест-кейсов на автоматизацию.
В этом процессе могут косвенно участвовать и менеджеры продукта с аналитиками, указывая какому функционалу необходимо уделить особое внимание и автоматизировать в первую очередь с точки зрения бизнес-значимости функционала.
Следующий вариант использования — полный. Этот вариант предполагает полноценное участие в BDD-методологии всех участников процесса разработки — от менеджеров продукта до тестировщиков и автоматизаторов. Каждый участник того или иного этапа разработки участвует в формировании конечных BDD-кейсов, которые в сумме дают полноценный автоматизированный регресс продукта. Также данный вариант плавно подводит вас к полноценному приемочному тестированию (ATDD), когда все критерии «приемки» продукта формируются не только тестировщиками, как это происходит зачастую, а всеми участниками процесса разработки. Данный подход наиболее полезен и эффективен с точки зрения автоматизации, он дает быстрое и очень качественное пополнение конечного авторегресса.
Мы начали с первого, неполного варианта, с привлечением к методологии только функциональных тестировщиков и автоматизаторов, во многом в виде эксперимента, который показал бы нам на практике слабые и сильные стороны методологии. Мы поняли, что такой подход к тестированию дает свои плоды, и начали думать, как нам привлечь к методологии всех участников разработки. Классический вариант {x}DD, когда изначально пишутся все тесты, и только потом начинается непосредственная разработка, в изначальных наших условиях сильно повлиял бы на наш быстрый релизный цикл, что для банковских сервисов непозволительная роскошь. К тому же установка, настройка и поддержка всего необходимого ПО для BDD-автоматизации всем участникам этапов разработки, не говоря об обучении работе с BDD-фреймворком, сильно замедлили бы нас в дальнейшем развитии методологии. Решение мы нашли в «корнях» BDD-методологии. Напомню, что в основе методологии лежит использование DSL-языка (Gherkin), человекочитаемого языка описания поведения системы, описывающего функционал с помощью бизнес-ситуаций (сценарии поведения, пользовательские истории). Благодаря несложным правилам составления сценариев, можно быстро привлечь большое количество сотрудников к постановке задач и их последующей детализации в формате языка Gherkin. Весь процесс также ведется в рамках используемого вами ПО для управления проектами и багтрекинга, в нашем случае это Atlassian Jira. Менеджеры и аналитики уходят от старого формата постановок задач и начинают ставить задачи в BDD-формате. Дизайнеры и разработчики получают описание задач в BDD-формате, однако могут и сами дополнить список пользовательских историй, исходя из особенностей интерфейса или используемых библиотек при разработке. В итоге, когда задача попадает в тестирование, тестировщик видит список пользовательских историй, проанализировав который, дополняет своими пользовательскими сценариями, исходя из позиции тестировщика. Каждая история — это законченный сценарий для тестирования. Это живая документация продукта. А самое главное — все сценарии из описания задачи быстро переносятся тестировщиками в BDD-фреймворк, становясь фактически готовыми автотестами.
В итоге это практически переход BDD-методологии к полноценному приемочному тестированию (ATDD), когда все этапы разработки участвуют в составлении критериев приемки продукта.
Это описание автоматизации по BDD-методологии на практике «издалека». А что происходит на более низком уровне, как построен процесс пополнения авторегресса? Чтобы ответить на этот вопрос, нужно вернуться к основе BDD-фреймворка. Механизм взаимодействия пользователя с BDD-фреймворком построен на инструкциях. Имеющийся в BDD-фреймворке список доступных инструкций и дерево описанных страниц и элементов позволяют автоматизировать большую часть пользовательских сценариев. Логично предположить, что список инструкций и дерево описанных страниц и элементов не всегда позволяют автоматизировать тот или иной сценарий. Особенно при автоматизации сценариев нового, еще не автоматизированного функционала, несмотря на то, что инструкции построены максимально атомарными, с минимальным уровнем абстракции, на уровне взаимодействия с элементами. Плюс ко всему, могут появиться новые страницы и их новые элементы, которые еще не описаны в нашей иерархии элементов и страниц. Таким образом, появляются BDD-кейсы, для автоматизации которых не хватает инструкций, страниц и их элементов. Тестировщика данная ситуация вводила в ступор из разряда «а что мне делать, если нужной инструкции еще нет?». Тут есть два варианта, как можно построить процесс. Первый — не писать новый BDD-кейс, оповещать автоматизаторов о том, что не всех инструкций хватает или не все элементы описаны. Сразу оценить, хватит ли всего для автоматизации кейса, довольно трудно. Либо второй, более рациональный вариант — давать пользователю писать свой кейс так, как ему хочется, несмотря на отсутствие инструкций, страниц и элементов. Мы дали тестировщикам свободу в написании инструкции, дали им возможность писать кейсы так, как им удобно и построили процесс таким образом, чтобы такие кейсы, имеющие нехватку инструкций или описания элементов, порождали задачи в Jira, которые попадут «на вход» автоматизаторам. Автоматизаторы реализуют недостающие инструкции, описывают недостающие элементы и задачи, и автотест тестировщика попадает в рабочую ветку авторегресса.
Для обеспечения качества новых BDD-кейсов настроен процесс обязательного прохождения код-ревью. Сформулированы конкретные правила, описывающие то, как должны выглядеть основные блоки BDD-кейсов, как они должны быть оформлены. Именно по этим правилам проводится проверка написанных кейсов силами коллег из функционального тестирования. Правила затрагивают соответствие местоположения кейса и его смыслового содержимого, наличие необходимых меток и другие важные моменты. Без этих правил процесс пополнения авторегресса будет хаотичным и непредсказуемым. Но об этом в следующих частях статьи.
4. Разделяйте роли
Данная часть является логическим продолжением предыдущей части.
Любая методология, любой подход к разработке, производству, любой организации труда сильно затрудняется, если участники этих процессов не знают свое место в этом процессе. Человек должен знать свою роль, должен знать конечный список обязанностей, которые данная роль предполагает. Причем чем более детализированы эти обязанности, тем понятнее и прозрачнее процесс будет как для самого участника процесса, так и для всех остальных. Эти тезисы не обходят стороной и такую сложную и трудоемкую методологию, как BDD.
Методология довольно гибкая, и часто многие останавливаются на привлечении в методологию только автоматизаторов и тестировщиков. Полноценное использование методологии предполагает привлечение всех участников разработки, именно её мы и будем рассматривать. Так кто же основные «действующие лица» методологии BDD? Конечно, это функциональные тестировщики, которых мы обозначим как «ФТ». ФТ делятся на «просто тестировщиков», пишущих и автоматизирующих BDD-кейсы, и на тех, кто вдобавок проводит код-ревью новых BDD-кейсов, которых мы обозначим аббревиатурой «КР». Это и автоматизаторы, которых мы назовем «АТ». Аналитиков, менеджеров и технологов всех других участников процесса мы объединим обозначением «АН». «Богоподобную» роль мы назовем «руководителем проекта», или сокращенно «РП». Это все выделенные роли методологии:
— «ФТ» (функциональные тестировщики);
— «КР» (код-ревьюверы);
— «АТ» (автоматизаторы);
— «АН» (аналитики, менеджеры, технологи etc);
— «РП» (руководитель проекта).
Теперь разберемся с основными возможными действиями в методологии. Это:
— написание BDD-кейсов в свободном формате на языке Gherkin;
— автоматизация BDD-кейсов в BDD-фреймворке;
— код-ревью автоматизированных BDD-кейсов, проверка на соответствие выделенным правилам составления новых BDD-кейсов;
— автоматизация недостающих инструкций, их поддержка; описание новых страниц и элементов, их поддержка;
— проведение код-ревью автоматизации недостающих инструкций, их поддержке, описания новых страниц и элементов;
Составим конечную матрицу ролей методологии и возможных действий:
| Действие/Роль | ФТ | КР | АТ | АН | РП |
| Написание BDD-кейсов на языке Gherkin | X | X | X | X | X |
| Автоматизация BDD-кейсов в BDD-фреймворке | X | X | - | - | X |
| Код-ревью автоматизированных BDD-кейсов | - | X | - | - | X |
| Автоматизация инструкций, описание элементов и страниц, etc. | - | - | X | - | X |
| Проведение код-ревью автоматизации | - | - | X | - | X |
Таким образом, каждый в процессе выполняет свою роль и функции:
— новый функционал описывается менеджерами, аналитиками и технологами в удобном для них формате на языке Gherkin;
— функциональные тестировщики заняты написанием качественных с точки зрения тестирования кейсов, автоматизируют их и сами проводят код-ревью написанных кейсов;
— автоматизаторы заняты только чистой автоматизацией и сопутствующей автоматизации работой, а не написанием кейсов, как это часто бывает.
5. Обучайте сотрудников
Несмотря на то, что BDD-кейсы пишутся на человекоподобном языке, а автоматизация ведется в специально созданном фреймворке, придется отвести время на минимальное обучение всех участников методологии. Начнем с тестировщиков, без которых представить BDD-методологию очень трудно.
Роль тестировщиков в процессе — создать качественные BDD-кейсы и автоматизировать их в BDD-фреймворке, либо, как очень часто бывает, автоматизировать «сразу на месте», прямиком во фреймворке. Тестировщики должны понимать, как правильно составлять BDD-кейс, из чего он состоит, и как им с ним работать в дальнейшем. Тут необходимы знания о языке Gherkin. Донести до ребят информацию можно либо на встрече с презентацией, либо с помощью учебных материалов для самообучения в вашей корпоративной wiki, а лучше и тем, и другим.
Навыки работы тестировщиков с фреймворком лучше всего получать с практикой. Наш опыт показал, что эффективнее всего «задачи на обучение». Это типовые — с ними вероятнее всего столкнутся тестировщики при автоматизации — задачи по проекту, в котором внедряется BDD. Каждой задаче выдается определенный срок на выполнение, после чего проводятся коллективные встречи с обсуждением результатов выполнения задач и возникающих проблем.
Обучение менеджеров, аналитиков, технологов и других, участвующих только в написании BDD-кейсов, сводится к обучению языку Gherkin, который они будут применять при составлении описания задач на разработку функционала или его доработку/изменение. Обучение мало отличается от обучения тестировщиков: тут помогут хорошая презентация с интерактивом в виде обсуждения возникших вопросов и корпоративная wiki со всей необходимой информацией.
Автоматизаторы, как правило, не нуждаются в обучении: главное донести до них основные моменты процесса автоматизации, и дать понять им, что ограничивать полет фантазии тестировщиков нельзя, пусть и составленные ими кейсы выглядят для них странно и непонятно. У тестировщиков своя «кухня», у них свой уникальный взгляд на мир.
Стоит отметить, что в сформированном нами подходе к методологии возможна эволюция из одной роли в другую. Так, функциональный тестировщик, набравшись необходимого опыта в составлении BDD-кейсов и в их автоматизации, может перейти в роль код-ревьюера. Код-ревьюер, желая не только писать кейсы, но и полноценный код внутри BDD-фреймворка, может стать и автоматизатором, когда обучится всем необходимым навыкам. Прецедентов пока не было, но мы, автоматизаторы, начали курс обучения автоматизации среди наших BDD-тестировщиков и надеемся, что в скором времени «взрастим» своих автоматизаторов. Минимальные требования — навыки в любом ООП-языке и большое желание научиться чему-то новому.
Из всех поступающих «новеньких» сотрудников тестирования время от времени формируйте группы обучения BDD-автоматизации, выделяйте из уже обученных людей менторов, которые не только помогут новеньким хорошо понять методологию, но и сыграют важную роль во вливании новеньких в ваш коллектив. Это касается и всех остальных участников методологии.
Помните, что от грамотного систематизированного подхода к обучению сотрудников зависят результаты внедрения методологии.
6. Обсуждайте результаты и проблемы
Результаты пополнения авторегресса обсуждаются каждую неделю, когда мы подводим итоги так называемого «спринта» — недельного отрезка, во время которого фиксируем, как развивается автоматизация наших продуктов и обсуждаем возникающие проблемы. На встрече подводятся итоги прошедшей недели, оглашаются количественные показатели автоматизации. Для команды BDD-автоматизации это отличный мотивационный инструмент, который дает им понять, что их труды не остаются незамеченными. Также такая ретроспектива дает понять, есть ли деградация в автоматизации по сравнению с предыдущими «спринтами», и если она наметилась, возможно, понять причины её возникновения и разобраться, как ее устранить.
Как показала наша практика, основной проблемой при внедрении BDD-методологии и её дальнейшем развитии может стать банальное отсутствие времени у участников методологии и трудности при распределении затрачиваемого времени на «BDD-активность», её приоритет в потоке задач. Уделите этому особое внимание и будьте готовы, что, возможно, придется сократить время на тестирование задач и проведение регресса или увеличить длину релизного цикла. Время, затрачиваемое на BDD-активность среди всех участников процесса, можно гибко регулировать, начиная от выделения определенных дней в неделю и заканчивая выделением определенных часов рабочего дня для BDD-автоматизации. Однако, затраты на автоматизацию вернутся сторицей, когда авторегресс позволит сократить время, затрачиваемое на регресс выпускаемого функционала, и повысит качество регресса.
Остальные проблемы несущественны — как правило, это «просветы» либо в понимании процесса, либо в специфических знаниях о работе с BDD-фреймворком. Решаются такие проблемы просто: либо проведением повторных ликбезов, либо личной беседой для устранения всех «белых пятен».
Большой проблемой автоматизации всегда остается непосредственно использование автотестов, как бы печально это ни звучало. Автотесты могут стать неактуальными в виду изменений в автоматизированном продукте; могут использовать некорректные тестовые данные, наталкиваться на нерабочую тестовую среду, иметь проблемы в инфраструктуре прогона автотестов.
Неактуальность — наверное, самая распространенная проблема автотестов. Автотестам трудно успевать за постоянно увеличивающимся объемом нового или изменяемого функционала. Несмотря на то, что вышедшие изменения могут аффектить большую часть автотестов, правки в них могут потребоваться минимальные. У нас очень часто возникали ситуации, когда проблема в актуализации автотестов заключалась не в том, что требуется много правок из-за изменений, а в том, что эти изменения случились неожиданно для нас, автоматизаторов. Другими словами, основная проблема в актуализации автотестов в том, что автоматизаторы не знают о грядущих изменениях. Выход из этой ситуации следующий: как только становится понятен окончательный скоп задач, которые войдут в очередной релиз тестируемой системы, необходимо проанализировать, какие изменения аффектят авторегресс. В большинстве случаев это задачи, затрагивающие интерфейсную часть тестируемой системы. Найти такие задачи в скопе релизных задач довольно просто. А имея на руках тестируемую ветку релиза, автоматизаторы могут быстро внести необходимые правки в авторегресс, что и позволит вашему авторегрессу быть актуальным для регресса.
Некорректность тестовых данных является продолжением неактуальности автотестов. Тестовые данные, как правило, подбираются под конкретные проверки того или иного функционала, и терять свою актуальность они могут из-за грядущих изменений. Решение данной проблемы такое же, как и неактуальности автотестов в целом: необходим анализ релизной версии тестируемого продукта на предмет изменения входных данных. Для удобства и быстрой правки тестовых данных необходимо максимально отказываться от «хардкода» тестовых данных и переносить их в единое место хранения.
Нерабочие тестовые среды — настоящий бич тестирования и автоматизации тестирования. Проблемы с тестовыми средами могут привести как к трудностям в тестировании, так и к полноценному простою команд тестирования. Рабочие тестовые среды — еще один из столпов, без которого тестирование будет очень затруднительно. Благо существует множество инструментов, позволяющих держать ваши тестовые среды в стабильном состоянии. Плюс очень радует развитие инструментов для изолированного разворачивания тестовых контуров под нужды тестирования: это позволит прийти к процессу вроде «развернул тестовую среду — провел тестирование — свернул и почистил тестовую среду».
Нет ничего обиднее, чем автотесты, которые не смогли запуститься по каким-либо причинам.
Если у вас много автотестов, то, скорее всего, у вас развернута инфраструктура их запуска. С большой долей вероятности вы используете open-source решения. Заранее предусмотрите вопрос необходимых сетевых доступов и будьте готовы к тому, что Selenium или любой другой open-source инструмент имеет множество «открытых» проблем, на которые вы можете напороться. Будьте предельно внимательны и осторожны при обновлениях версий используемых инструментов. По нашей практике наиболее частыми проблемами были настройка и конфигурация CI-систем: где-то не хватило памяти, где-то потерялся доступ, где-то обновленный плагин перестал работать. Так же часто попадали на проблемы с драйверами браузеров: не всегда удавалось с первого раза найти работающую комбинацию версии браузера и его драйвера — все подбирается экспериментальным путем. Тем не менее, все перечисленные проблемы решаемы, однако требуют много времени и сил.
7. Будьте готовы к увеличению количества кейсов
Настроенный процесс автоматизации проекта по BDD-методологии позволит вам буквально поставить на поток пополнение вашего авторегресса BDD-кейсами. Переменные, которыми вы можете регулировать этот поток — это время, выделяемое участникам процессов разработки на «BDD-активность», и это задаваемый автоматизаторам баланс между задачами по актуализации BDD-кейсов и реализации новых инструкций. Следующие переменные будут влиять на процесс пополнения авторегресса автотестами, но они не всегда на 100% подчиняются вашей воле — это возможность пополнения BDD-кейсами тестируемого функционала в принципе (да-да, возможна ситуация, когда все автоматизировано), это стабильность инфраструктуры написания BDD-кейсов и их запуска, это состояние тестовой среды. Эту схему можно представить в следующем виде:
Время, выделяемое на BDD-активность, согласовывается, как правило, с менеджерами проекта, с этим все довольно понятно. Возможно, как упоминалось выше, вы придете к изначальному экспериментальному выделению нескольких часов в неделю. Баланс, задаваемый автоматизаторам на реализацию задач актуализации и реализации недостающих инструкций/описания элементов, следует задавать, исходя из текущей нагрузки по этим направлениям. Со временем, как показала практика, у вас установится примерное соотношение скорости реализации нового функционала тестируемого проекта к скорости написания новых BDD-кейсов функциональными тестировщиками. Не стоит откладывать реализацию недостающих инструкций BDD-кейсов в долгий ящик, делая упор только на актуализации: со временем это может привести к тому, что BDD-кейс потеряет свою актуальность и его придется актуализировать.
Оценить возможность пополнения регресса тестируемого функционала автотестами при полноценном внедрении BDD-методологии помогут BDD-истории, написанные менеджерами, аналитиками и технологами. Тогда оценкой возможности автоматизации функционала является оценка возможности автоматизации всех BDD-историй. При неполном внедрении BDD-методологии, с участием только тестировщиков и автоматизаторов, на плечи тестировщиков ложится составление полного списка возможных пользовательских сценариев. Удобным инструментом в данной ситуации является использование карты тестирования. Это документ, хранящий в идеале краткое описание всех возможных пользовательских сценариев взаимодействия с функционалом, проверяемых при регрессе. В этот документ добавляется поле о текущем статусе автоматизации кейса. Имея поле критичности кейса для функционала в целом, тестировщик представляет, какой функционал необходимо автоматизировать и в каком порядке. Возможное решение проблем со стабильностью фреймворка, инфраструктуры использования автотестов и тестовых стендов описано в предыдущих главах статьи.
При большом количестве BDD-кейсов, являющихся в тоже время и автотестами, рано или поздно появится вопрос о времени их «прогона», который тесно перекликается с возможностями распараллеливания автотестов. Никому не интересны автотесты, возможный результат которых ты получишь только через N часов. И если со стороны кода для распараллеливания имеются работающие проверенные решения, то о возможностях инфраструктуры использования автотестов придется подумать. В нашем случае пришлось увеличить технические мощности сборочных агентов TeamCity и виртуальных машин в системе распределенного запуска автотестов Selenium Grid.
Использование полного авторегресса тестируемой системы оправдано, как правило, при проведении полного регресса. Для возможности быстро и изолированно проверить необходимый функционал мы реализовали запуск авторегресса по меткам. Весь функционал системы бьется на иерархию меток в доступном для всех участников BDD-методологии виде. При написании нового кейса в обязательном порядке проставляются метки по затрагиваемому BDD-кейсом функционалу. Для запуска нужной части авторегресса нужно просто указать необходимые к запуску метки.
Заключение
Автоматизация по методологии BDD при всей своей сложности и трудоемкости внедрения определенно приносит пользу качеству продукта. При правильной организации ключевых элементов автоматизации, таких как фреймворк, обучение сотрудников и рабочий процесс, автоматизация по методологии BDD может стать отправной точкой для полноценного внедрения BDD на всех этапах разработки продукта, развенчивая расхожее мнение о том, что методологию BDD можно внедрять только в полноценном её варианте с «верхних» этапов разработки продукта и невозможности успешного внедрения в крупных компаниях.
Помните, что автоматизация по методологии BDD не является волшебной таблеткой от всех ваших текущих бед с автоматизацией: данный подход к автоматизации отлично решает свои главные задачи — добиться максимального покрытия тестируемого функционала автотестами и сократить время, затрачиваемое на покрытие функционала автотестами. Не стоит внедрять автоматизацию по методологии BDD при явных проблемах со стабильностью инфраструктуры запуска автотестов, проблемах с тестовыми данными и тестовыми средами, которые не только оттянут внедрение на долгие сроки, но и, возможно, вовсе заставят вас отказаться от затеи.
И все же, при правильном подходе к основным пунктам, описанным в данной статье, умноженном на старание и самоотдачу всей команды, участвующей в методологии, вас должен ждать успех, и все ваши затраты на внедрение окупятся с лихвой. Надеемся, что наш опыт поможет вам, и эта статья станет полезным материалом в вашей непростой, но вполне выполнимой задаче.
Автор: Тинькофф Банк
