Подпишитесь на DeepL Pro и переводите документы большего объема.

Подробнее на www.DeepL.com/pro.
 Оглавление
Предисловие

Часть 1: Основы

Глава 1: Введение в автоматизацию

тестирования Глава 2: Стратегия

автоматизации тестирования Глава 3:

Общие инструменты и фреймворки

Часть 2: Практические вопросы

Глава 4: Начало работы с основами

Глава 5: Автоматизация тестирования

для Web Глава 6: Автоматизация

тестирования для Mobile Глава 7:

Автоматизация тестирования для API

Глава 8: Автоматизация тестирования

для производительности Часть 3:

Непрерывное обучение

Глава 9: CI/CD и автоматизация

тестирования Глава 10: Общие

проблемы и подводные камни Оценки

Индекс

Другие книги, которые могут

вам понравиться

Приложение A:Mocking API

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

Автоматизация тестирования лежит в основе большинства мероприятий

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

Тестирование не является отдельным видом деятельности и

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

В этой книге я познакомлю вас с различными аспектами

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

Инженеры по качеству: Инженеры по качеству, которые имеют

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

В главе 2 "Стратегия автоматизации тестирования"

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

В главе 3 "Общие инструменты и фреймворки" описаны основные

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

Глава 4, "Начало работы с основами", рассказывает о некоторых

продвинутых командах Git и знакомит читателей с IDE. Затем читателям
предлагается пройти экспресс-курс по JavaScript.

В главе 5 "Автоматизация тестирования для Web" подробно

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

Глава 6, "Автоматизация тестирования для мобильных устройств",

знакомит читателей с фреймворком для автоматизации тестирования
мобильных устройств Appium. В ней рассказывается об установке и
настройке, а также о том, как написать свой первый тест для
автоматизации мобильных устройств с помощью Appium. Также
рассматриваются некоторые ключевые аспекты автоматизации
мобильных тестов.
В главе 7 "Автоматизация тестирования API" подробно
рассматривается, как использовать инструмент Postman для
тестирования RESTful API. В ней также представлены варианты
автоматизации тестов API в Postman.

Глава 8, Автоматизация тестирования производительности,

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

Глава 9, CI/CD и автоматизация тестирования, устанавливает

концепцию CI/CD и рассматривает, как стратегии автоматизации
тестирования применяются к методологии CI/CD. Кроме того, в ней
читатели увидят демонстрацию GitHub Actions - встроенного в GitHub
инструмента CI/CD.

Глава 10 "Общие проблемы и подводные камни" знакомит читателей с

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

Приложение A, How to Dockerize Automated Tests, помогает читателям

использовать контейнерную технологию для создания и запуска
автоматизированных тестов.

Чтобы получить максимальную

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

Программное/аппаратное обеспечение, Требования к операционной

рассматриваемое в книге системе
Visual Studio Code (VC Code) Windows, macOS или Linux

Python 3.5+ Chrome, Firefox, Edge

Java Runtime Environment (JRE) 1.8+

Терминал (macOS) / PowerShell (Windows)

Cypress версии 11.2.0

Node.js

Комплект средств разработки Java (JDK)

Программное/аппаратное обеспечение, Требования к операционной

рассматриваемое в книге системе
Android Studio

Postman (версия 9.3.15)

Инструмент командной строки Newman

JDK 8 и JRE 8 или выше

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

Код в тексте: Указывает на код в действиях, командах, ключевых

словах, именах папок, файлах, расширениях файлов и именах путей.

Вот пример: "Функция setTimeout() вызывает метод после указанного

ожидания в миллисекундах. Например, setTimeout(() =>
console.log('hello!'), 5000) выводит сообщение после ожидания в 5
секунд."

Блок кода задается следующим образом:

describe ("Первый Android Spec", () => {

it ("найти элемент по идентификатору доступности", async () => {

const animationOption = await $("~Animation");

Любой ввод или вывод командной строки

записывается следующим образом: appium driver

install xcuitest

установка драйвера appium uiautomator2

Жирный: обозначает новый термин, важное слово или слова, которые

вы видите на экране. Вот пример: "Используйте опцию "Настройки" в
меню "Параметры
меню для дополнительной

настройки". Советы или важные

заметки

Выглядят так.

Загрузите файлы кода примера

Файлы кода примеров для этой книги можно загрузить с GitHub по
адресу https://packt.link/Uhjqi. Если код будет обновлен, он будет
обновлен в репозитории GitHub.

У нас есть и другие наборы кодов из нашего богатого каталога книг и

видео, доступные на сайте https://github.com/PacktPublishing/.
Проверьте их!

Свяжитесь с нами
Отзывы наших читателей всегда приветствуются.

Обратная связь: Если у вас есть вопросы по любому аспекту этой

книги, напишите нам по адресу customercare@packtpub.com и укажите
название книги в теме сообщения.

Ошибки: Несмотря на то, что мы сделали все возможное, чтобы

обеспечить точность наших материалов, ошибки все же случаются. Если
вы нашли ошибку в этой книге, мы будем благодарны, если вы
сообщите нам об этом. Пожалуйста, посетите сайт
www.packtpub.com/support/errata и заполните форму.

Пиратство: Если вы обнаружите в интернете нелегальные копии наших

работ в любой форме, мы будем благодарны, если вы сообщите нам
адрес или название сайта. Пожалуйста, свяжитесь с нами по адресу
copyright@packt.com со ссылкой на материал.

Если вы заинтересованы в том, чтобы стать автором: Если у вас

есть тема, в которой вы разбираетесь, и вы заинтересованы в
написании или участии в создании книги, пожалуйста, посетите сайт
authors.packtpub.com.
Поделитесь своими мыслями
После прочтения книги "Test Automation Engineering Handbook" мы
будем рады выслушать ваши мнения! Пожалуйста, нажмите здесь,
чтобы перейти на страницу отзывов Amazon об этой книге и
поделиться своим мнением.

Ваш отзыв важен для нас и технологического сообщества и поможет нам

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

Скачайте бесплатную PDF-

копию этой книги
Спасибо за покупку этой книги!

Вы любите читать на ходу, но не можете повсюду носить с собой

печатные книги?

Ваша электронная книга не совместима с выбранным вами

устройством?

Не волнуйтесь, теперь с каждой книгой Packt вы бесплатно получаете

PDF-версию этой книги без DRM.

Читайте в любом месте, на любом устройстве. Ищите, копируйте и

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

На этом преимущества не заканчиваются: вы можете получить

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

Выполните эти простые действия, чтобы получить преимущества:

1. Отсканируйте QR-код или перейдите по ссылке ниже

https://packt.link/free-ebook/9781804615492

2. Предоставьте доказательство покупки

3. Вот и все! Мы вышлем вам бесплатный PDF-файл и другие
преимущества прямо на вашу электронную почту
Часть 1: Основы
В этой части мы начнем с основ тестирования и автоматизации
тестирования. Вы узнаете о том, какие соображения необходимо
учитывать при разработке эффективных стратегий автоматизации
тестирования. Вы также познакомитесь с Git и поймете основы
известных фреймворков для автоматизации тестирования. К концу
этого раздела вы будете узнавать и понимать часто используемые
термины, фреймворки и инструменты автоматизации тестирования.

Эта часть состоит из следующих глав:

Глава 1, Введение в автоматизацию

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

За качество в команде отвечают все, и в этой главе приведены

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

Вот основные темы, которые вы узнаете к концу этой главы:

Знакомство с тестированием
программного обеспечения Внедрение
автоматизации тестирования
Изучение ролей в инженерии качества
Ознакомление с общими терминами и определениями

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

Функционал: Проверка бизнес-функций программной системы:

Соответствие требованиям: Регулирующие органы,

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

Нефункциональное: Проверка нефункциональных аспектов

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

Надежность: Время бесперебойной работы,

отказоустойчивость, непрерывность бизнеса и многое другое
Безопасность: Уязвимости, тестирование на
проникновение и многое другое Производительность:
Нагрузка, стресс-тестирование и многое другое

Теперь, когда мы вкратце познакомились с тестированием, давайте

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

Задачи, связанные с тестированием

Тестирование - это не просто выполнение задокументированных
тестовых примеров. В тестирование вовлечено множество задач,
которые можно перечислить ниже:

Обсуждение критериев приемки с представителями продукта и

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

В зависимости от размера, возможностей и структуры команды, для

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

Как видно из предыдущей диаграммы, тестирование охватывает

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

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

Поскольку Agile-среда нацелена на то, чтобы как можно быстрее

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

Часто результаты работы инженера по тестированию оцениваются по

количеству и качеству дефектов, которые он находит в программном
приложении. Далее мы рассмотрим некоторые ключевые аспекты
управления дефектами.

Управление дефектами при

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

Дефект против ошибки

Дефект - это отклонение от ожидаемого поведения. Это может быть

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

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

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

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

Подход Shift-Right является продолжением Shift-Left, когда

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

Это приводит нас к вопросу о том, как внедрить качество на ранних

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

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

В мире DevOps очень важно сохранять гибкость в тестировании и

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

До сих пор мы рассматривали различные аспекты тестирования, и это,

несомненно, ответственная деятельность. Давайте рассмотрим
некоторые проблемы, с которыми инженеры-испытатели сталкиваются
ежедневно.

Трудности при тестировании

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

Самая распространенная проблема, с которой сталкиваются Agile-

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

Далее давайте рассмотрим, как раннее и частое тестирование помогает

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

Таблица 1.1 - Важность раннего и частого тестирования

Следующий отрывок рассказывает о стоимости исправления ошибок

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

Распространенные аргументы в пользу отказа от раннего тестирования:

"У нас нет
ресурсов" или "У нас недостаточно времени". И то, и другое -
результат недостаточно тщательного изучения рисков проекта.
Доказано, что общее количество усилий больше, когда тестирование
вводится на более поздних этапах проекта. Со стороны тестировщика
важно сократить избыточность и постоянно думать о повышении
эффективности своих тестов. Test-Driven-Design (TDD) -
распространенный подход к практике Test Early, Test Often. Для того
чтобы этот подход был успешным, процессы тестирования должны
быть отлажены и строго соблюдаться.
Тестирование может оказать стратегическое влияние на качество
продукта, если его внедрить на ранней стадии и проводить часто и
эффективно. Пирамида тестирования Agile (которая представляет
собой
подробно рассматривается в главе 2) может служить руководством для
стратегической классификации и организации различных типов
тестов.

До сих пор мы рассматривали ряд концепций, которые помогают нам

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

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

Тестирование, безусловно, не является одноразовым мероприятием и

должно проводиться каждый раз, когда в программное приложение
вносятся изменения. Чем дольше мы не тестируем приложение, тем
выше вероятность неудачи. Таким образом, непрерывное тестирование
- это не вариант, а абсолютная необходимость в современном Agile-
программировании. Ручное тестирование подразумевает выполнение
тестировщиком заранее определенных тестовых случаев на
тестируемой системе, как это сделал бы реальный пользователь.
Автоматизированное тестирование предполагает выполнение тех же
тестов с помощью скрипта, что позволяет сэкономить драгоценное
время тестировщика и сосредоточиться на юзабилити или
исследовательском тестировании. При правильном подходе
автоматизированные тесты более надежны, чем тесты, выполняемые
вручную. Более того, у тестировщика появляется больше времени,
чтобы извлечь ценные выводы из результатов автоматизированных
тестов, что способствует увеличению тестового покрытия программного
приложения в целом.
Автоматизация тестирования - это один из основных способов
создания и достижения качества. Основное преимущество
автоматизации тестирования заключается в выявлении ошибок в
программном обеспечении и их исправлении на ранней стадии и как
можно ближе к среде кодирования разработчика. Это помогает
снизить пагубное влияние позднего обнаружения дефектов, а также
поддерживает цикл обратной связи между командами разработчиков
и разработчиков продукта. Несмотря на то что первоначальные
инвестиции в автоматизированные тесты могут показаться большими,
анализ показал, что со временем они окупаются. Автоматизация
тестирования позволяет командам предоставлять новые функции
быстро и с высоким качеством. На рисунке 1.2 показано, как
различные компоненты программного приложения могут быть
взаимозависимы, и постоянное тестирование каждого из них
подтверждает их поведение. Необходимо проверять эти компоненты
не только как отдельные, но и как интегрированные системы:

Рисунок 1.2 - Непрерывное тестирование

Представьте себе простой поток заявок на получение кредита,

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

1. Создание кандидата
2. Создание заявки на кредит
3. Определение права на получение кредита
Каждый из API сначала должен быть протестирован изолированно,
чтобы проверить точность бизнес-функциональности. Позже, когда API
будут интегрированы, необходимо будет провести
Бизнес-процесс должен быть протестирован для подтверждения
поведения системы. Здесь можно создать набор средств автоматизации
тестирования для автоматизации как отдельных API, так и поведения
всей системы. Кроме того, при повторном использовании API
создания заявителя в другом приложении набор средств
автоматизации может быть использован повторно, что обеспечит
возможность повторного использования и переносимость
тестирования. Аналогичная реализация может быть выполнена и для
компонентов пользовательского интерфейса.

Автоматизация тестирования - это очень совместная деятельность,

требующая участия бизнес-аналитиков, инженеров-программистов и
инженеров по качеству/инженеров по тестированию разработки
программного обеспечения (SDET). Она освобождает всю команду от
чрезмерного влияния повторяющихся ручных тестов, что позволяет
достичь качества в кратчайшие сроки. В то время как экспертные
обзоры кода и внутренние обзоры дизайна выступают в качестве
дополнительных мероприятий для раннего выявления дефектов,
автоматизация тестирования позволяет команде начать тестирование
продукта с конечными пользователями. Распространено заблуждение,
что автоматизированные тесты ограничивают взаимодействие
человека с тестируемой системой. Хотя это может быть правдой, что
тестировщик не взаимодействует с системой так часто, как при ручном
тестировании, сама деятельность по разработке и поддержке
автоматизированных тестов объединяет всю команду, комментируя
тестовый код и дизайн. Автоматизированные тесты открывают новый
способ общения внутри команды, чтобы улучшить качество системы и
предотвратить появление ошибок.

Рассмотрев основы автоматизации тестирования, давайте узнаем о

некоторых важных моментах в мире Agile.

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

Начните с малого и итеративно развивайте сценарии

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

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

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

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

Как уже говорилось ранее, недостаточная автоматизация

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

Создание и поддержка инфраструктуры автоматизации тестирования -

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

Поиск и устранение ошибок

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

Стандарты проверки кодексов ниже уровня или вообще

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

Инженеры-тестировщики могут стать ключевым компонентом,

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

Метрики автоматизации
тестирования
Зачем и что измерять при автоматизации тестирования - это
постоянный вопрос, который не дает покоя команде тестировщиков.
Инженерам-испытателям интересно знать, насколько эффективны их
скрипты и как они работают в различных условиях. С другой стороны,
руководство компании будет заинтересовано в том, чтобы узнать
окупаемость инвестиций в автоматизацию тестирования, а не просто
надеяться на то, что она принесет пользу в долгосрочной перспективе.
Давайте рассмотрим некоторые ключевые показатели, которые могут
помочь оценить ценность автоматизации тестирования, которая уже
внедрена:
 Эффективность автоматизации тестирования: Это ключевая
метрика, которая позволяет понять, насколько эффективно
автоматизированные тесты находят ошибки. При логическом
разбиении по скриптам/тестовым средам эта метрика дает
направление, на котором следует сосредоточить наши дальнейшие
усилия:
Эффективность автоматизации тестирования = (количество
дефектов, найденных автоматизацией/общее количество
найденных дефектов) * 100

Покрытие автоматизации тестов: Эта метрика показывает

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

Покрытие автоматизации тестирования = (количество

автоматизированных тестовых случаев/общее количество тестовых
случаев) * 100

Стабильность автоматизации тестирования: Эта метрика дает

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

Стабильность автоматизации тестирования = (количество

неудачных тестов/общее количество прогонов тестов)
* 100

Показатель успешности или неуспешности автоматизации

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

Коэффициент успешности автоматизации тестирования =

(количество пройденных тестовых случаев/общее количество
выполненных тестовых случаев) * 100

Эквивалентные усилия по тестированию вручную: Эта

метрика, обычно выраженная в человеко-часах, является
показателем окупаемости инвестиций, позволяющим определить,
можно ли автоматизировать конкретную функцию или нет:
Эквивалентные усилия по тестированию вручную = Усилия по
тестированию конкретной функции * Количество раз
тестирования функции в цикле тестирования
 Время выполнения автоматизации тестирования: Как видно
из названия, эта метрика показывает, насколько долго или коротко
выполняются ваши тесты. Сравнение этого показателя с общим
временем развертывания в производство дает представление о том,
сколько времени тратится на выполнение автоматизированных
тестов. Это очень важно в условиях Agile, когда скорость доставки
продукта клиенту считается ключевым фактором:

Время выполнения автоматизации тестирования = Время

окончания автоматизации тестирования - Время начала
автоматизации тестирования

Важное замечание относительно показателей автоматизации

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

До сих пор мы видели, как тестирование и автоматизация тестирования

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

Изучение ролей в инженерии

качества
В мире тестирования есть три основные роли, не связанные с
управлением людьми. В разных компаниях эти роли могут
использоваться или называться по-разному. Роли, связанные с
качеством, также различаются в зависимости от размера и структуры
организации. Например, небольшие компании могут объединить все эти
роли в одну и назвать ее SDET. Основные различия обусловлены их
техническими знаниями и общим опытом в области программного
обеспечения и инженерии качества:
Традиционный ручной тестировщик (или аналитик по
обеспечению качества) Инженер по автоматизации
тестирования (или инженер по качеству программного
обеспечения)
 Инженер по разработке программного обеспечения в области
тестирования (SDET)
Традиционная роль ручного тестировщика уже не так
распространена, как раньше, поскольку в мире Agile от каждой роли в
области качества ожидается определенный уровень автоматизации
тестирования. Поэтому здесь мы сосредоточимся только на двух
последних. Это не означает, что ручное тестирование больше не
проводится. Обязанности ручного тестировщика разделяют между
собой инженеры по тестированию, SDET, бизнес-аналитики и
владельцы/менеджеры продуктов.

Есть организации, где инженеры/разработчики программного

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

Далее мы рассмотрим наиболее распространенные роли

тестировщиков, которые преобладают на рынке.

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

Планирование тестирования и разработка стратегии тестирования

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

Подводя итог, можно сказать, что на ежедневной основе инженерам-

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

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

Основные обязанности SDET включают следующее:

Постановка четких целей автоматизации тестирования
Создание и совершенствование инфраструктуры
автоматизации тестирования Владение стратегией
автоматизации тестирования
 Взаимодействие с инженерами-программистами в команде и в
других командах (при необходимости) для создания и поддержки
системы автоматизации
Участие в обсуждении дизайна и архитектуры
Выполнение функций наставника для инженеров по
качеству в команде
Взаимодействие с командой DevOps для обеспечения
тестирования на всех этапах разработки.
Адаптация и внедрение новейших технологических разработок в
области инженерии качества
В таблице 1.2 показаны различия между инженером по
автоматизации тестирования и SDET:

Инженер по автоматизации SDET

тестирования
Создание и проведение Создает и поддерживает систему
автоматизированных и ручных тестов автоматизации тестирования

Сотрудничает с командами по Сотрудничает с инженерами-

разработке и внедрению продуктов программистами и командами DevOps

Высокая квалификация в области Эксперты в области тестирования

программирования и навыки как вручную, так и с помощью
тестирования автоматизации

Разрабатывает средства Использует средства автоматизации

автоматизации тестирования тестирования

Таблица 1.2 - Автоматизация тестирования в сравнении с SDET

Несмотря на то что их роли требуют разной ответственности, и

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

В следующем разделе мы познакомимся с некоторыми общепринятыми

определениями в мире тестирования и автоматизации тестирования.

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

A/B-тестирование: Тестирование для сравнения двух версий веб-

страницы по производительности и/или удобству использования,
чтобы решить, какая из них лучше привлекает конечных
пользователей.
Приемочное тестирование: Метод тестирования, позволяющий
установить, соответствует ли функция/продукт критериям приемки
бизнес-пользователей или конечных пользователей.
Agile-методология: Это итерационный подход к разработке
программного обеспечения, в котором на первый план выходят
сотрудничество и коммуникация. По сути, это набор идей для
быстрой и эффективной доставки программного обеспечения
клиентам.
Поведенчески-ориентированная разработка (BDD): BDD - это
распространенная практика Agile, когда критические бизнес-
сценарии сначала документируются, а затем реализуются, чтобы
конечный продукт непрерывно развивался вместе с
общее понимание. Мы рассмотрим реализацию фреймворка
BDD в главе 7.
Тестирование "черного ящика": Этот метод тестирования
фокусируется на выходе продукта, игнорируя детали
проектирования и реализации.
Тестирование на основе данных: Распространенный подход к
автоматизированному тестированию, при котором многократно
используемая логика, часто являющаяся частью тестового
сценария, прогоняется через набор тестовых данных для
сравнения фактических и ожидаемых результатов.
Сквозное тестирование: Метод тестирования, позволяющий
убедиться, что интегрированные компоненты продукта работают
так, как ожидается. Это очень важный вид тестирования для
проверки критических бизнес-потоков.
Эксплораторное тестирование: Подход к ручному
тестированию, при котором продукт тестируется в
исследовательской и любопытной манере без документированных
шагов с главной целью - найти ошибки.
Интеграционное тестирование: Метод тестирования, при
котором логика взаимодействия отдельных программных
компонентов или сервисов объединяется и тестируется как
единое целое.
Нагрузочное тестирование: Тип тестирования, позволяющий
оценить производительность программного приложения путем
имитации реального трафика системы. Оно может проводиться как
с программной системой в целом, так и только с API или базой
данных. Настройку для нагрузочного тестирования мы рассмотрим
в главе 8.
Тестирование на проникновение: Это тип тестирования
безопасности, при котором тестировщик пытается найти и
использовать уязвимости программного приложения.
Тестирование безопасности: Тип тестирования, позволяющий
убедиться в наличии всех необходимых средств защиты от
различных типов киберугроз.
Стресс-тестирование: Это тип тестирования производительности,
при котором система подвергается большим нагрузкам с
намерением сломать ее. Стресс-тестирование в основном
используется для определения пределов производительности
программного приложения. Мы рассмотрим настройку для стресс-
тестирования в главе 8.
Тестирование API: Это тип тестирования, направленный на
проверку логики, сборки и структуры API. Основная цель -
проверить функциональную логику API. Мы рассмотрим
реализацию тестирования API в главе 7.
 Дымовое тестирование: Техника тестирования, которая в
основном используется для проверки основных функций продукта
при внесении изменений или перед выпуском продукта для
широкой аудитории.
Системное тестирование: Тип тестирования, используемый для
оценки программной системы в целом, чтобы убедиться, что
интеграция всех компонентов работает так, как ожидается.
Тестовый пример: Это набор шагов, данных и ожидаемых
результатов для тестирования части кода или функционального
компонента в программном приложении.
План тестирования: Это документ, в котором описывается
методический подход к тестированию программного приложения.
В нем подробно описывается тестирование различных частей
приложения по частям и в целом.
Разработка, управляемая тестами (Test-Driven Development,
TDD): Это подход, используемый в основном в мире Agile, где
сначала пишется тест, а затем - код, достаточный для выполнения
теста. Рефакторинг кода продолжается в соответствии с тестами,
таким образом сохраняя акцент на спецификациях.
Набор тестов/комплекс автоматизации тестирования: Набор
автоматизированных тестовых сценариев и связанных с ними
зависимостей, используемых для запуска программного приложения.
Единичное тестирование: Тип тестирования, при котором
проверяется логика самых маленьких компонентов или объектов
программного обеспечения. Это, как правило, первый тип
тестирования, выполняемый в жизненном цикле разработки.
Юзабилити-тестирование: Это метод тестирования,
используемый для оценки продукта (обычно веб-приложения) с
целью определения трудностей при его использовании.
Валидация: Это процесс обеспечения входных и выходных
параметров продукта. Она отвечает на вопрос: Правильно ли мы
создаем продукт?
Верификация: Это процесс проверки соответствия продукта
заданным требованиям. Верификация отвечает на вопросы:
Создаем ли мы правильный продукт?
Водопадная модель: Это методология управления проектами, в
которой жизненный цикл разработки программного обеспечения
делится на несколько фаз, и
 Каждая фаза выполняется в последовательном порядке.
Тестирование "белого ящика": Метод тестирования,
позволяющий проверить возможности продукта с помощью
низкоуровневого проектирования и реализации.
Мы вооружились знаниями о широком спектре терминов, используемых
в индустрии качества. Теперь давайте быстро подведем итоги того, что
мы увидели в этой главе.

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

В следующей главе мы рассмотрим, что включает в себя тщательная

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

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

1. Что такое тестирование программного обеспечения и зачем оно

нужно?
2. Каковы некоторые важные результаты тестирования программного
обеспечения?
3. Что такое автоматизация тестирования и как она помогает
тестированию?
4. С какими трудностями приходится сталкиваться при тестировании
 и автоматизации тестирования?
5. Каковы общие роли в инженерии качества?
Стратегия автоматизации
тестирования
Эффективная автоматизация тестирования требует творческого
подхода, технической смекалки и упорства. Успех в автоматизации
тестирования достигается путем упорного преодоления разнообразных
трудностей, связанных со сложными областями применения,
меняющимися требованиями и нестабильной средой. Каждый
успешный проект по автоматизации тестирования начинается с
продуманной стратегии. Каждый программный проект уникален, и
стратегия автоматизации тестирования служит маяком для
удовлетворения уникальных требований проекта автоматизации
тестирования. Она служит опорой для поиска, оценки и постоянного
улучшения общего качества программного обеспечения.

Стратегия автоматизации тестирования - это не только планирование и

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

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

понимание стратегии и фреймворков автоматизации тестирования:

Знание стратегии автоматизации

тестирования Разработка хорошей
стратегии автоматизации тестирования
Понимание пирамиды тестирования
Ознакомление с общими шаблонами проектирования
автоматизации тестирования

Технические требования
В последующей части этой главы мы рассмотрим некоторый код на
Python, чтобы понять простую реализацию паттернов
проектирования. Вы можете обратиться к следующему URL-адресу
GitHub для поиска кода в этой главе:
https://github.com/PacktPublishing/B19046_Test-Automation-Engineering-
Handbook/blob/main/src/test/design_patterns_factory.py.
Этот Python-код приводится в основном для понимания паттернов
проектирования, и читателям не нужно выполнять код. Но если вы
заинтересовались, то вот необходимая информация, чтобы заставить
его работать на вашей машине. Во-первых, читателям понадобится
интегрированная среда разработки (IDE) для работы с кодом. Visual
Studio Code (VS Code) - это отличный редактор с широкой
поддержкой множества языков программирования.

Следующий URL-адрес содержит хороший обзор по использованию

Python в VS Code:

https://code.visualstudio.com/docs/languages/python

Чтобы выполнить этот код, на вашей машине должны быть

установлены версии Python 3.5+ и Java Runtime Environment (JRE)
1.8+. pip - это программа установки пакетов для Python, и я
рекомендую устанавливать ее с помощью
https://pip.pypa.io/en/stable/installation/. После установки PIP вы можете
использовать команду pip install -U selenium для установки привязки
Selenium к Python.

Далее необходимо установить драйвер для вашего браузера. Это

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

Chrome: https://chromedriver.chromium.org/downloads
Firefox: https://github.com/mozilla/geckodriver/releases
Edge: https://developer.microsoft.com/en-us/microsoft-
edge/tools/webdriver/

Убедитесь, что исполняемые файлы драйверов находятся в переменной

окружения PATH.

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

Цели автоматизации тестирования

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

Повышение качества продукции: Это главный стимул для

проектов автоматизации тестирования. Инженеры по автоматизации
тестирования могут планировать и создавать тесты, которые
позволяют выявлять регрессивные ошибки и помогают
предотвратить появление дефектов.
Улучшение тестового покрытия: Это ключевая мотивация для
многих начинаний по автоматизации тестирования. Инженеры-
испытатели обычно работают с инженерами-программистами и
командой разработчиков продукта, чтобы охватить все возможные
сценарии. Затем эти сценарии можно разделить на категории в
зависимости от их критичности.
Сокращение ручного тестирования: Нет необходимости говорить
о том, что сокращение ручного тестирования является основной целью
большинства - если не всех - инициатив по автоматизации
тестирования.
Автоматизированные тесты предсказуемы и выполняют
запрограммированные задачи последовательно и без ошибок. Это
оставляет больше времени для всей команды, чтобы
сосредоточиться на других важных задачах, и повышает общую
производительность команды.
Минимизация обслуживания и повышение переносимости
тестов: Это может быть невероятно веской причиной для начала
инициативы по автоматизации тестирования. В старых
программных проектах могут присутствовать тесты с жесткой
связью, не совместимые с новыми технологиями. Обычно от
команды тестирования требуются значительные усилия, чтобы
сделать их переносимыми и легко читаемыми.
Повышение стабильности программного продукта: Это
служит основной мотивацией для начала проекта автоматизации
тестирования с целью устранения нефункциональных
недостатков. Это предполагает определение и документирование
различных реальных сценариев стресс- и нагрузочного
тестирования приложения
 тестируемого приложения. Впоследствии, с помощью
соответствующих инструментов, приложение может быть
подвергнуто тестированию производительности.
Снижение затрат на качество: Это может помочь руководству
инвестировать свои ресурсы и средства в развитие возможностей
организации.
Уменьшение избыточности усилий, связанных с качеством,
помогает сократить затраты на тестирование и время. Стратегия
автоматизации тестирования может стать отличным стимулом для
этого.
Стремление к автоматизации тестирования может быть вызвано одной
из этих причин или их сочетанием. Хорошо продуманные цели
автоматизации тестирования в конечном итоге повышают общую
эффективность работы команды инженеров, тем самым направляя их
усилия на достижение большей ценности для бизнеса.

Далее рассмотрим, насколько важно заручиться поддержкой

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

Получение поддержки со стороны

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

После постановки задач и получения адекватной поддержки усилий по

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

Количество критически важных

для бизнеса потоков Сложность
тестовых примеров
Типы тестирования приложения Набор навыков
инженеров по автоматизации тестирования
Возможность повторного использования
компонентов в приложении Ограничения по
срокам поставки продукта
Доступность/зрелость тестовой среды

Нереально планировать автоматизацию каждой части программного

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

Теперь давайте рассмотрим важнейшую роль, которую играет тестовая

среда в стратегии автоматизации тестирования.

Среда автоматизации тестирования

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

Что представляет собой тестовая среда?

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

Здесь представлены наиболее распространенные типы тестовых сред:

Разработка
Тестирован
ие
Постановка
Производст
во

Мы не будем вдаваться в подробности каждого типа, но важно

помнить, что среда тестирования - это место, где выполняется
большинство автоматизированных тестов. Среда постановки обычно
используется для сквозного (E2E) тестирования и тестирования на
приемку пользователем (UAT). Оно может быть как ручным, так и
автоматизированным. Все организации имеют среду разработки, но в
зависимости от размера и возможностей некоторые могут объединять
среды тестирования и постановки в одну. Теперь, когда мы знаем, что
представляет собой тестовая среда, давайте рассмотрим, как ее создать.

Предоставление тестовой среды

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

Создание и настройка тестовой среды должны быть автоматизированы

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

Тестирование в производственной среде

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

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

Далее мы рассмотрим, как стратегия автоматизации тестирования

обеспечивает качество в Agile-ландшафте.

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

Еще один ключевой аспект, на который следует обратить внимание, -

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

Внимательные и постепенные инвестиции в автоматизацию

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

Квадранты Agile-тестирования представляют собой логичный способ

организации различных видов тестов в зависимости от того,
ориентированы ли они на бизнес или на технологию. Давайте быстро
рассмотрим, какие типы тестов пишутся в каждом из квадрантов:
 Квадрант 1: высокотехничные тесты, написанные
программистами, обычно на том же языке программирования, что
и программное приложение.
Квадрант 2: Тесты, проверяющие бизнес-функции и сценарии
использования. Эти тесты могут быть автоматическими или
ручными и используются для подтверждения соответствия
поведения продукта спецификациям.
Квадрант 3: Ручные тесты, которые проверяют
пользовательский опыт (UX) и функциональность продукта
глазами реального пользователя.
Квадрант 4: Инструментальные тесты, проверяющие
нефункциональные аспекты приложения, такие как
производительность и безопасность.
Стратегия автоматизации тестирования также должна учитывать
различные потребности в инструментах и процессах в каждом из
квадрантов Agile-тестирования, как показано на следующей диаграмме:

Рисунок 2.1 - Квадранты Agile-тестирования

Стратегия автоматизации тестирования в Agile-проекте должна

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

Отчет о результатах тестирования

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

Стратегия автоматизации тестирования должна позволять

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

Также должен существовать единый портал, на котором можно

фильтровать и использовать результаты тестирования, чтобы
обеспечить наглядность для заинтересованных сторон.

Правильная отчетность при автоматизации тестирования значительно

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

Взгляните на следующую схему:

Рисунок 2.2 - Разбивка стратегии автоматизации тестирования

На рисунке 2.2 представлены все основные составляющие стратегии

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

Далее мы рассмотрим некоторые основные моменты, которые

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