[Из песочницы] Советы и рекомендации по развёртыванию процесса автоматизация тестирования с нуля

Предисловие

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

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

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

P.S.: И последнее — данный текст бы никогда не сформировался, если бы не полезные лекции Александра Баранцева и Натальи Руколь, а также пропасть информации, написанная добрыми людьми за последние годы по данной теме.

Вот теперь всё, вы предупреждены — можно начинать рассказ.

Часть 1 — Развёртывание автоматизации тестирования

1. Выбор стратегии автоматизации тестирования (дальше — АТ)

Существует несколько общепринятых используемых вариантов стратегии АТ. От выбора конкретной стратегии зависит порядок и интенсивность тех или иных работ по АТ. Выбор стратегии — задача не самая важная, но начать процесс развёртывания автоматизации лучше всего именно с неё. Приведу 3 варианта стратегий, характерных для самого начала развёртывания автоматизации. Конечно же, вариантов стратегий больше, полный список можно посмотреть на семинарах Натальи Руколь.

1.1 Стратегия «Let's try»

Применяется в том случае, когда АТ ни на проекте ни в компании по сути никогда не было, и планируется осторожный старт с умеренным выделением ресурсов.

Стратегию имеет смысл применять в случае, когда:

• Отсутствуют точные цели автоматизации (покрыть 40% кода конкретного модуля к определённой дате, уменьшение расходов на ручное тестирование и т.д.).
• АТ на проекте ранее никогда не применялась.
• У тестировщиков отсутствует (или очень мал) опыт АТ.
• Выделенные ресурсы умеренны или низки.

Описание стратегии:

• Больше внимания уделять подготовительным этапам тестирования (составление тест-планов, тест-кейсов и т.д.).
• Больше внимания уделять инструментам, которые можно использовать как помощь в ручном тестировании.
• Больше экспериментировать с технологиями и методологиями АТ. Никто не ждёт срочных результатов и можно экспериментировать.
• Работать с проектом, начиная с верхнего уровня, в начале не углубляясь в автоматизацию конкретных модулей.

1.2 Стратегия «Here the target»

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

Стратегию имеет смысл применять в случае, когда:

• Когда на проекте уже проведена предварительная работа, имеется какой-то бэкэнд в виде тест-планов, тест-кейсов, оптимально — автотестов предыдущего этапа АТ.
• Есть конкретная цель АТ (не глобальная — 80% автотестов за полгода, а скорее 50% автотестов конкретного модуля за месяц)
• Для выполнения конкретной цели выбраны конкретные инструменты, оптимально если у специалистов имеется некий технический бэкэнд по работе с инструментами.

Описание стратегии:

• Поступательная стратегия, чем-то напоминающая Agile методологии разработки. Движение вперёд этапами. Покрытие автотестами модуля за модулем, до полного выполнения мета задач вида (80% за полгода).
• На каждый этап выставляется новая цель (вероятнее всего продолжающая последнюю выполненную цель, но не обязательно), и выбираются инструменты для реализация данной цели.
• Глубокая фокусировка на конкретной цели, написание тест-кейсов, автотестов, не для всего проекта, а исключительно под конкретную задачу.

1.3 Стратегия «Operation Uranum»

По сути, стратегия — постоянная и методичная работа над АТ по выставляемым раз в 2-3 недели приоритетам. Оптимально — наличие постоянно работающего именно над автоматизацией человека, не особенно отвлекающегося на сторонние задачи.

Стратегию имеет смысл применять в случае, когда:

• Отсутствуют конкретные цели, есть лишь общее пожелание «чтоб всё было хорошо». Если «Here the target» напоминает по принципу работы Agile, то данная стратегия близка по духу к методологии Waterfall.
• Есть ресурс в виде хотя бы одного постоянно действующего на проекте человека, плотно занятого задачей автоматизации.
• Нет чётко выраженных целей АТ, однако есть пожелания (приоритеты), которые можно выставить на достаточно продолжительный период времени (данные модули более важны, нежели те, больше ошибок традиционно в бэкэнде/фронтэнде, потому большие усилия стоит направить на него).

Описание стратегии:

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

Резюмируя:

Стоит обдумать общую логику и стратегию автоматизации, однако я бы предложил следующий вариант: В начале на 1 месяц (3-4 недели) воспользоваться стратегией «Let's try», подготовить базу для дальнейшей работы, не особо глубоко погружаясь в написание кода, самих авто-тестов и глубокую конкретику модулей. По завершению этого этапа у нас будет готовый базис для дальнейших работ. А дальше нужно выбрать, как будет удобно работать дальше — грубо говоря, waterfall'ом или Agile'ом. И дальше действовать в соответствии с выбранной стратегией.

2. Распараллеливание задач

Данный пункт имеет смысл в том случае, если над тестированием проекта работает или будет работать несколько человек. Тогда возникает существенно важный момент распараллеливания задач в команде. Если в твоей команде над АТ будет работать один человек — данный пункт можно смело пропускать.

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

Роли

Архитектура

• Выбор инструментов
• Выбор подходов

Разработка

• Разработка и отладка тестов
• Поддержка, обновление
• Исправление ошибок

Тест-дизайн

• Отбор тестов
• Проектирование тестов
• Проектирование тестовых данных

Управление

• Планирование
• Сбор метрик
• Обучение

Тестирование

• Локализация ошибок
• Заведение ошибок
• Подготовка тестовых данных

В случае, если над тестированием проекта работает несколько человек, то логично описанные выше роли распараллелить по конкретным людям. В данном случае имеет смысл назначит роль «Управление» одному человеку, разделить роли «Тест-дизайн» и «Тестирование» на всех, и роли «Архитектура» и «Разработка» одному-двум героям.

Логика в этом следующая.

1. Есть чёткий руководитель тестирования по данному проекту, который планирует, определяет сроки, и несёт ответственность в случае их несоответствия.
2. Есть два общих типа тестировщиков — ручные тестеры и автоматизаторы. При этом задачи ролей «Тест-дизайн» и «Тестирование» одинаково актуальны для обоих типов. Соответственно все тестировщики пишут и проектируют тесты, которые в дальнейшем можно использовать и в ручном тестировании и в автоматизации.
3. Далее ручные тестеры по созданным тест-планам и тест-кейсам проводят ручной тестирование, автоматизаторы же допиливают нужные тесты до вида, годного к разработке и занимаются именно автоматизацией.

Впрочем, если у вас будет человек-оркестр, то он будет делать сразу всё, но не будет профессионалом во всём.

3. Создание тест-плана

После выбора стратегии АТ следующим важным пунктом будет отправная точка работ — создание тест плана. Тест-план должен быть согласован с разработчиками и менеджерами продукта, поскольку ошибки на этапе создания тест плана могут аукнуться существенно позже.

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

Тест-план состоит из следующих пунктов:

3.1 Объект тестирования.

Краткое описание проекта, основные характеристики ( web/desctop, ui на iOs,Android, работает в конкретных браузерах/операционках и так далее).

3.2 Состав проекта.

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

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

3.3 Стратегия тестирования и планируемые виды тестирования на проекте.

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

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

3.4 Последовательность проведения работ по тестированию.

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

3.5 Критерии завершения тестирования

Кратко описать — когда тестирование считается завершенным в рамках данного релиза. Если есть какие-то специфические критерии — описать их.

Резюмируя:

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

4. Определение первичных задач

После выбора стратегии и составления тест плана стоит выбрать набор задач, с которых начнём автоматизацию тестирования.

Наиболее частые типы задач, которые ставятся перед автоматизацией:

• Полная автоматизация приёмочного тестирования (Смоук тестирование) — вид тестирования, проводящийся первым после получения билда отделом тестирования. В рамках смоук-тестирования проверяется тот функционал, который должен работать всегда и в любых условиях, и, если он не работает — по соглашению с разработчиками считается, что билд не может быть принят к тестированию.
• Максимизация количества найденных дефектов. В этом случае надо отобрать сначала те модули (или аспекты функциональности) системы, которые наиболее часто подвержены изменениям логики работы, а затем выбрать наиболее рутинные тесты (то есть тесты, где одни и те же шаги с небольшими вариациями выполняются на большом объеме данных).
• Минимизация «человеческого фактора» при ручном тестировании. Тогда отбираются, опять-таки, наиболее рутинные тесты, требующие наибольшей внимательности от тестировщика (при этом, легко автоматизируемые). К примеру — тестирование пользовательского интерфейса (например, проверка имён 60 колонок в таблице), проверка содержимого комбо-бокса с 123 элементами, проверка экспорта таблицы на веб-странице в Excel, и т.д.
• Нахождение большинства crash'ей системы. Тут можно применять «случайные» тесты.

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

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

Также подразумевается, что смоук-тесты будут позитивными(проверяющими корректное поведение системы, в то время как негативные — проверяют, будет ли система работать некорректно), дабы не тратить время на лишние проверки.

Резюмируя:

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

5. Написание тест-кейсов по выбранным задачам

В отношении тест-кейсов принято делить процесс тестирования на две части: тестирование по готовым сценариям (тест-кейсам) и исследовательское тестирование.

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

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

Три варианта дальнейшего использования тест-кейсов, кроме очевидного:

• Сформировать из тест-кейсов чек-листы по модулям проекта, так проверка ускорится, но основные проблемные места будут проверены.
• Обучение новичков — пришедший на проект тестировщик может изучать проект с точки зрения тест-кейсов, поскольку они захватывают многие не очевидные моменты работы приложения.
• Дальнейшее использование как базис автотестов. Если при развёртывании АТ применяется системный подход — то написание и дальнейшее использование тест-кейсов является совершенно логичным — по сути тест-кейс — уже готовый сценарий автотеста.

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

Хороший тест-кейс состоит из следующих пунктов:

1. Название (описание) — очень краткое описание того, что проверяет тест.
2. Предварительное состояние системы — описание состояния системы, в котором она должна быть на момент начала выполнения тест-кейса.
3. Последовательность шагов — последовательно описанные действия, проверяющие заявленную в Названии цель.
4. Ожидаемый результат — состояние системы, которое мы ждём после прохождения последовательности шагов тест-кейса.

Для удобного хранения тест-кейсов существует множество решений, однако из тех, что я пользовался, весьма неплохим показало себя приложение Testlink, а оптимальным — система sitechco.ru, удобная бесплатная система создания/хранения и отслеживания выполнения тест-кейсов.

Резюмируя:

Для дальнейшей АТ нужно написать тест-кейсы по выставленным в п.4 задачам. Они послужат одновременно началом создания нормального регрессионного тестирования и послужит базой для дальнейших автотестов.

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

6. Выбор инструментов для автоматизации

Очевидно — инструменты для АТ выбираются в зависимости от платформы, на которой работает приложение.

Приведу пример выбора инструментария для проекта, состоящего из двух частей — Backend на AngularJS и Frontend – клиент под планшеты и телефоны, основанные на iOS.

1. Backend

Karma+Protractor(Jasmine).

Плюсы: В качестве оболочки рекомендую использовать инструмент Protractor, он идеально подходит для приложений, написанных на AngularJS. Protractor имитирует взаимодействие с пользователем, позволяет создавать автотесты, созданные посредством BDD фреймворка Jasmine. Ну а Krame позволяет эти тесты запускать в разных браузерах.

Минусы: Тестировщик должен уметь писать хотя бы простые скрипты на JS. Либо же ему должен писать эти скрипты программист, что с развитием АТ может стать накладным.

Selenium Webdriver.

Плюсы: Удобный, простой и надёжный инструментарий для автоматизации тестирования GUI web приложений. Множество документации, пропасть примеров, в общем — удобен. В самом примитивном варианте не требует никакого знания программирования от тестировщика.
Минусы: Protractor написан командой AngularJS для тестирования AngularJS, в то время как Selenium универсален. С моей точки зрения, писать тесты для Protractor+Jasmine на AngularJS проекте будет удобнее. В случае, если планируется серьёзное автотестирование, а не просто помощь ручным тестировщикам, то тестировщику всё равно необходимо будет знать язык программирования (java, pithon, ruby, c#), поскольку гибкая настройка тестов требует знаний программирования.

2. Frontend

Calabash+Cucumber.

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

Стоит учитывать, что Calabash — платное решение (http://ift.tt/1rgAIcs).

Резюмируя:

Инструменты для автоматизации тестирования описаны выше, однако это далеко не единственные доступные инструменты и я бы рекомендовал тому, кто займётся настройкой всей этой инфраструктуры и развертыванием АТ в компании вдумчиво покопаться в сети, возможно уже появится что-то новое и более удобное, чем выбранные мной инструменты.

7. Отбор тестов для автоматизации

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

1. Очень сложно автоматизировать следующие вещи:

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

2. Избавление от монотонной работы.

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

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

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

3. Простота тестов.

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

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

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

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

1. Ожидаемый результат в автоматизированных тест-кейсах должен быть описан предельно чётко и конкретно.

• Плохо: Результат — открывается страница Forms.
• Хорошо: Результат — открывается страница Forms, на странице присутствует форма поиска <input type=«text» placeholder=«Search»..>, присутствует элемент css=div.presentations_thumbnail_box и link=Notes.

2. Учитывать особенности синхронизации браузера и приложения, запускающего тесты.

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

• Плохо: Нажать на ссылку «Forms» в верхнем меню. Подтвердить внесённые изменения.
• Хорошо: Нажать на ссылку «Forms» в верхнем меню. Дождаться появления формы с текстом «Do you want to save changes?». Нажать на кнопку «ОК».

3. Не стоит прописывать в тест-кейсе жестких значений.

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

• Плохо: Открыть слайд «slide 1_11»
• Хорошо: Открыт первый слайд презентации

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

• Плохо: Из файла, созданного предыдущим тестом…

5. Стоит внимательно изучать документацию по используемым инструментам.

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

Резюмируя:

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

9. Настройка стека приложений для автоматизации

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

Backend

1. Karma+Protractor(Jasmine)

— Karma + Protractor — Отличный мануал по развёртыванию инструментов — http://ift.tt/204brVu
— Protractor + Jasmine — Установка и настройка Jasmine http://ift.tt/204brVw

В случае выбора данной схемы, для автоматического запуска тестов будет необходимо «подружить» Karma и одну из систем Continuous integration. Предлагаю два показавшихся мне наиболее интересными варианта — Jenkins и Teamcity.

— Teamcity — Решение достаточно простое, заключающееся в установке плагина karma-runner-reporter;
— Jenkins — Аналогично — простое решение, установка плагина karma-jenkins-reporter.

2. Selenium Webdriver

Само решение не слишком элегантно, но об этом написано выше. Если всё же решили идти простым путём, то достаточно поставить:

— Selenium IDE;
— Принципы работы с Selenium Webdriver в случае, если тестов, полученных из IDE явно недостаточно можно почитать здесь.

После установки инструментов, останется запускать их на Continuous integration системе. И вновь предлагаю два наиболее (на мой взгляд), удобных варианта — Teamcity и Jenkins.

— Teamcity — переводим тесты из IDE в тесты на языке (C#, Java, Python, Ruby), и настраиваем их запуск в Teamcity. Один из вариантов решения — в статье.
— Jenkins (прямо скажу — сложнее).

Frontend

1. Calabash+Cucumber

— Первый вариант установки;
— Второй вариант установки;

Далее начинается самое весёлое — заставить Calabash работать в связке с Continuous integration системой.

— Teamcity — наверное лучший вариант, что я видел, описан здесь.
— Jenkins — тоже всё совсем не просто, как вариант для начала.

Резюмируя:

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

10. Подготовка тестовых данных

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

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

Особых правил здесь нет, всё интуитивно понятно, если исходить из тестов, единственное замечание — обычно автотесты запускают изолированными наборами независимых тестов. При этом зачастую запускаются тесты одного набора в случайном порядке. Соответственно, при написании автотестов постарайтесь писать их так, чтобы по завершению одного теста всё еще мог выполниться любой другой тест из набора.

• Плохо — тест обращается к подготовленному изначально файлу и в процессе работы удаляет его. Другой тест, запускающийся следующим, также должен обратиться к уже удалённому файлу. Происходит ошибка.
• Хорошо — тест, удаляющий файл либо создаёт его в начале своей работы, либо создаёт по завершении работ. Таким образом файл существует до начала и после завершения теста.

11. Разработка и запуск автотестов

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

Удачи!

Резюмируя 11 глав руководства

Выполнив все описанные выше рекомендации, настроив, написав и запустив автотесты вы сделали самую важную часть работы — начали разворачивать автоматизацию тестирования на проекте.

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

Во второй части руководства будут описаны задачи, встающие перед автоматизатором каждый новый цикл тестирования, maintenance или sustain задачи. Возвращаться к ним придётся достаточно часто, до тех пор, пока продумывание и анализ автотестов не войдёт в привычку.
Всё, первая глава руководства успешно завершена!

На этом месте можно обнимать и радостно пить шампанское!

Поздравляю, первый шаг сделан!

Часть 2 — Развитие и сопровождение процесса автоматизации тестирования

12. Оценка эффективность автоматизации

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

Оценка эффективности рассматривает в двух логических полях:

1. Оценка эффективности автоматизации в целом.

Оценку эффективности АТ по сравнению с ручным можно приблизительно высчитать по следующему алгоритму:

1. Необходимо прикинуть время, необходимое тестировщикам (или программистам, если они занимаются автоматизацией), на разработку набора автотестов, покрывающих определённый модуль или функционал проекта — это будет TAuto.
2. Прикинуть время, необходимое тестировщикам на разработку тест-кейсов и чек-листов, которые будут использоваться в тестировании данного функционала — это будет TMan.
3. Посчитать (или прикинуть, если функционал еще не разработан) время, которое будет затрачено на однократное тестирование функционала вручную — это будет TManRun.
4. Прикинуть время, которое будет затрачено на переделку автотестов в случае изменения функционала — это будет TAutoRun.
5. Прикинуть время, которое будет затрачено на анализ результатов выполнения автотестов — это будет TAutoMull.
6. Очень ориентировочно посчитать планируемое количество итераций в данном продукте до его завершения (если есть точные данные по числу циклов разработки — конечно же использовать точные данные ) — это будет N.
7. Приблизительно прикиньте количество сборок продукта, требующих повторного тестирования в рамках одного релиза. Среднее число возьмём за R.

Теперь выводим следующую формулу:

TManTotal = N*Tman + N*R*TManRun
TAutoTotal = TAuto + N*TAutoRun + N*R*TAutoMull

Соответственно, в случае, если TManTotal >= TAutoTotal автоматизация имеет смысл.

Данное исследование можно проводить при планировании работ в новом модуле или новом крупном функционале, с целью определить, окупятся ли данные затраты.

2. Оценка эффективности автотестов

Периодически (идеально — раз в цикл тестирования) нужно проводить оценку эффективности отдельных автотестов.

Причин, по которым нужно проводить подобное исследование, несколько:

1. Динамичные изменения функционала.

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

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

Соответственно то, что будет динамично меняться не стоит переделывать до завершения всех работ и вместо автотестов временно тестировать данную область вручную.

Если же работ больше не планируется и модуль вероятнее всего какое-то время будет стабилен — будет верно изменить тест под новые условия.

2. Дублирование работы.

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

3. Оптимизация времени выполнения.

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

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

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

4. Логика запуска тестов.

Для повышения эффективности выполнения автотестов будет правильно подробно и тщательно обдумать механизмы их запуска.

Наиболее популярные модели:

Приоритетность тестов:

• Критический
• Мажорный
• Минорный
• Тривиальный

Модель описана выше, используется для управления наборами тестов.

Модульная принадлежность тестов:

• Модуль 1
• Модуль 2
• Модуль 3
• ...

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

Необходимость запуска:

• Запускать
• Не запускать

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

Время запуска:

• По расписанию — к примеру — сборка текущего тестового/stable билда в 5 утра, к приходу на работу вас уже будет ждать отчёт о прохождении тестов.
• При изменении приложения — перезапускать автотесты при появлении нового changeset'а в текущей тестовой ветке репозитория.
• При изменении тестов — аналогично, при обновлении автотестов в репозитории.
• По требованию — стандартный запуск по требованию.

Резюмируя:

Если есть большое желание внедрить АТ на проекте, спустя несколько циклов разработки будет полезно потратить время и посчитать эффективность идущей автоматизации. И периодически перепроверять результаты. Равно как и взять за привычку периодически оценивать эффективность выполнения автотестов.

13. Оценка времени выполнения задач

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

С точки зрения оценки временных затрат принято делить тесты, планируемые к автоматизации на два типа:

1. Исследовательские.

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

Если поставлена задача, носящая признаки исследовательской, для её оценки следует задаться следующими вопросами:

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

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

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

2. Тиражируемые.

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

Такие задачи достаточно просто оценивать, ведь подобные им уже были выполнены и мы знаем примерное время их исполнения. Нам поможет:

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

Резюмируя:

Чем шире будет покрытие автотестами функционала проекта, тем более точными будут становится ваши оценки времени, планируемого на автоматизацию.

Резюмируя руководство:

На этом всё, по автоматизации тестирования можно сказать еще многое, здесь представлен исключительно срез моего опыта и моего использования и понимания множества стандартных техник автоматизации. Писать это было интересно, и спасибо за то, что прочитали!

This entry passed through the Full-Text RSS service - if this is your content and you're reading it on someone else's site, please read the FAQ at http://ift.tt/jcXqJW.