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

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

Автоматизация тестирования уязвима к мгновенному устареванию.

Проекты связаны с созданием кода. Код автоматических тестов не является кодом, который выходит в production. Таким образом, приоритеты в разработке программного обеспечения допускают изменения исходного кода, даже если эти изменения ломают автоматические тесты. Это, вообще говоря, разумно с экономической точки зрения. Если предположить, что продукт будет меняться, у вас есть в два варианта: инвестировать в автоматическое тестирование — в создание архитектурно выверенных фреймворков, чтобы оно было устойчивым и надёжным к таким изменениям, или быстро написать автоматические тесты и быть готовым к тому, что изменения продукта (кода) могут привести к необходимости переделывать тесты или даже писать их заново.

Автоматические тесты не могут полностью заменить ручные тесты

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

Автоматизация тестирования — больше чем запуск тестов

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

  • Генерация тестов (генераторы данных и сценариев)

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

  • Конфигурация системы

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

  • Эмуляторы

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

  • Выполнение тестовых сценариев

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

  • Исследования

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

  • Оракулы

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

  • Анализ покрытия

    Инструменты могут наблюдать за тестированием со стороны и генерить отчёты о том, что протестировано, а что нет.

  • Управление тестированием

    Автоматические тесты могут оповещать результатах, могут собирать статистику, получать различные метрики.

Автоматизация тестирования зависит от тестопригодности кода

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

Инструменты тестирования разнообразны

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

Автоматизация тестирования может отвлечь вас от хорошего тестирования.

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

Принципы Agile автоматизации тестирования

Я предлагаю эти принципы работы для получения непрерывных и эффективных результатов:

  • Автоматизация тестирования представляет из себя не только запуск тестов, но и поддержку всех аспектов тестового проекта
  • Процесс автоматизации тестирования управляется тестировщиками и никем другим.
  • Автоматизация тестирования прогрессирует, когда к ней подключаются специализированные на автоматизации программисты (toolssmiths). Можно назвать их тренерами/гуру/лидами.
  • Toolsmiths разрабатывают, собирают и применяют широкий спектр инструментов для поддержки тестирования.
  • Автоматизация тестирования организована так, чтобы быстро выполнять краткосрочные цели, не забывая при этом о будущей стоимости изменения тестов — то есть стараться закладывать гибкую архитектуру.
  • Долгосрочные цели автоматизации тестирования требуют экономического обоснования перед бизнесом. Например, — «это, это, это позволит в будущем сократить затраты на то, то, то»

Задачи Toolsmiths

Тестовые Toolsmiths совершают следующие активности:

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

Состав команды Agile автоматизации

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

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

Автоматизация тестирования доказывает свою состоятельность с точки зрения того, как она…

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

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

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

  • Список запросов

    Это список новых запросов для Toolsmiths от клиентов (тестировщиков).

  • Список назначенных задач

    Это список того, что каждый toolsmith в настоящее время делает

  • Список запросов на обслуживание

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

  • Список решений

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

  • Список препятствий

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

Фоновые задачи

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

Как тестировщики работают с Toolsmiths

Во-первых, Toolsmith, как и любой другой член команды, должен находиться не в другом помещении, а вот тут вот — рядом, в шаговой доступности и в области видимости. Тестировщики являются «клиентами» toolsmiths. Тестировщик может в любой момент обратиться за помощью к lead по автоматизации тестирования, а lead должен регулярно проверять, делает ли toolsmith всё возможное для тестировщиков.

Запросы к toolsmith могут включать в себя такие вещи, как:

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

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

Как разработчики работают с Toolsmiths

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

Как менеджмент работает c Toolsmiths

Менеджмент работает с Toolsmiths в основном, прося и оперативно получая отчеты о ходе тестирования. Toolsmith должен быть готов ответить на некоторые стандартные вопросы:

  • Что мы получим от автоматизации тестирования?
  • Сколько это будет стоить нам?
  • Учитывая стоимость, становимся оправдана ли автоматизация тестирования?
  • Что плохого произойдет, если мы приостановим дальнейшие инвестиции в автоматизацию тестирования?

Ещё одна вещь, которую может сделать тестирование и toolsmith — создать доску с метриками, которая кратко передаёт значимость тестирования и производительность.
Вот некоторые потенциальные показатели и другие конкретные метрики, которые могут помочь пролить свет на производительность тестирования:

  • "Рейтинг нахождения" исправляемых ошибок

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

  • "Рейтинг нахождения костылей"

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

  • Рейтинг исправлений

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

  • Тестирование стало возможным

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

  • Избегание кошмаров

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

  • Цикл тестирования

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

  • Цикл разработки/тестирования

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

  • Уверенность менеджмента

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

  • Затраты на техническую поддержку

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

  • Удержание клиентов

    Чем лучше качество, тем клиенты счастливее и лояльнее.

  • Репутация

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

  • Поставленные решения

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

Риски в Agile автоматизации

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

Follow us

Visit and follow our fan page to get information about new BoK’s, news and vacancies