OpenQuality.ru

Качество программного обеспечения

Качество программного обеспечения: в главных ролях

Лента  Радар  Блог  Опыт  
Разум  Видео  Заметки  Эпизоды


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

Содержание:

 

Вступление

 

7 августа 1974 года французский канатоходец Филипп Пети прогулялся по канату, натянутому между Северной и Южной башнями-близнецами Всемирного торгового центра в Нью-Йорке. Прогулка продолжалась 45 минут, во время которых Филипп восемь раз прошел туда и обратно. Сразу после головокружительного променада Филипп был арестован полицией, но все обвинения были сняты в обмен на бесплатное представление для детей в Центральном парке Нью-Йорка.

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

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

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

 
Автотесты в общей структуре обеспечения качества
 

Знаменитая пирамида тестирования Фаулера выделяет модульные тесты, сервисные тесты, а также тесты в графическом интерфейсе.
Ага, подсматриваете?
В соответствии с этой концепцией считается, что в продукте должно быть как можно больше модульных тестов, какое-то существенное покрытие сервисными (интеграционными) тестами и небольшое количество UI-тестов. Почему так? Потому что, как правило, UI-тесты сравнительно медленные, дорогие в разработке и поддержке, а также хрупкие. Попробуйте автоматизировать клики по нужным элементам в Veeam ONE Monitor, и вы меня поймете.

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

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


1. Блин, давайте писать UI-тесты, ведь они эмулируют действия пользователей. Здравствуй, AutoIt, TestComplete и Selenium RC (тогда еще не было WebDriver).

2. Не, так не пойдет, заплюхаемся с UI. Давайте за потроха дергать. Здравствуйте, Com-объекты, CLI и API.

3. Нужна золотая середина – смотрим за что можно дернуть и оцениваем эффективность (но об этом ниже).

Как правило, модульные тесты (unit tests) пишут разработчики: либо в рамках методологии TDD (сравнительно редко), либо постфактум (после написания кода приложения), либо вообще не пишут - зависит от квалификации разработчиков, позиции менеджмента и возраста проекта:

  • Не каждый разработчик понимает как писать модульные тесты и/или осознает их важность.
  • Руководители проекта порой не выделяют на это время (“пишите production code – дальше тестировщики прокликают”)
  • Проекту может быть много лет, и там черт ногу сломит (“разобраться бы как вот этот кусок работает - не то что автотесты писать”)

Есть и другой край спектра: разработчики пишут тесты на всех уровнях пирамиды тестирования. Классический пример: SQLite. Разработчики этого продукта в свое время заявляли о 100% покрытии кода автотестами.

Обычно тестировщики-автоматизаторы (то есть, люди из QA) не пишут низкоуровневые модульные тесты. Во-первых, нужна соответствующая квалификация (досконально понимать код продукта). Во-вторых, это не всегда считается важным. Но порой в одном месте сходятся люди с нужной квалификацией и назревшие потребности в модульных тестах, и результат может порадовать Мартина Фаулера (автора пирамиды тестирования). Более того, в отдельных компаниях есть даже позиции типа Software Developer In Test (SDET). Иногда под это определение попадают обычные “тестировщики-автоматизаторы от QA”, но порой это достаточно квалифицированные разработчики, которые full time пишут низкоуровневые тесты либо специализированные инструменты для их написания. Например, таких людей много в Google. И раз уж мы упомянули Google, то вот ссылка на, пожалуй, самую нашумевшую статью по автотестам за последние несколько лет.

Как бы то ни было, в большинстве случаев тестировщики-автоматизаторы пишут интеграционные и высокоуровневые автотесты, задействуя CLI, API, REST, командлеты, пользовательский интерфейс.

 
Выбор теста на автоматизацию и критерии хорошего автотеста
 

Зачем нужны автотесты, которые пишут тестировщики-автоматизаторы? Для того чтобы снять часть нагрузки с ручных тестировщиков:


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

2. Автотесты избавляют от рутинных проверок как в наиболее часто используемых, так и в редкотестируемых сценариях. Если в автотестах удается реализовать перебор различных вариантов в той или иной функциональности (опции продукта, версии OS, SQL Server и т.п.), то у ручных тестировщиков высвобождается время на более интеллектуальные сценарии.

Вот каких принципов мы придерживаемся:

  • Автотест адресует проблему, стоящую перед ручными тестировщиками и/или разработчиками (например, снизить объем трудоемких рутинных проверок, выполняемых с каждым билдом).
  • Автотест эффективен по критерию “количество затраченных усилий – полученный результат”.
  • Автотест стабильный (не хрупкий).
  • Результат автотеста легко интерпретировать и понять суть проблемы в случае фэйла.
  • Автотест сравнительно легко поддерживать в случае изменений в функциональности продукта и расширения автотестов.
  • Ручные тестировщики доверяют результатам автотестов. Не должно быть false negative и false positive тестов, когда тест сигнализирует о несуществующей проблеме или не сигнализирует о существующей. Желательно, чтобы ручной тестировщик понимал, что именно и как тестирует автотест – тогда ему будет ясно, что автотест на данный момент может проверить и что нет.

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

В качестве примера рассмотрим реализованный сценарий для продукта Veeam ONE. Один из компонентов продукта – Business View, который позволяет группировать элементы виртуальной инфраструктуры по различным критериям. Критериев и вариантов их комбинирования очень много, поэтому проверка этой функциональности вручную занимает много времени. Написание автотестов “в лоб” с имитацией действий ручных тестировщиков было бы неэффективным: тесты для графического интерфейса десктопных приложений, как правило, сложны и трудоемки в разработке, являются хрупкими, их тяжело модифицировать, и выполняются они долго. Мы нашли другое решение: поскольку действия пользователя в UI интерполируются в SQL-запросы к базе данных, мы используем SQL-запросы для создания категорий и групп, вызывая их из Powershell. Это позволило нам в разумные сроки покрыть автотестами все свойства и операторы, задействованные в Business View.

 
Портрет автоматизатора
 

  • Автоматизатор должен писать код. Важно, чтобы автоматизитор умел и любил это делать, а также стремился писать хороший код, чтобы при необходимости его можно было комфортно изменять, расширять, переиспользовать и поддерживать его коллегам. Зачастую в автотестах задействовано несколько языков, нужно осознанно выбирать инструмент по задаче, а также ориентироваться в кучу готовых утилит, способных облегчить жизнь. Как удаленно выполнить команды на Linux, как поймать SNMP trap, как отправить тестовое письмо, какие фреймворки задействовать для репортинга? Все давным-давно реализовано - далеко не всегда надо изобретать велосипед. Необходимо уметь работать с системами контроля версий (например, GitLab). Желательно уметь работать с системами непрерывной интеграции (Jenkins, TeamCity).
  • Важно, чтобы автоматизатор не опускал руки перед сложными техническими задачами, искал и находил пути для их решения.
  • Важно, чтобы автоматизатор ощущал себя тестировщиком. Написание автотестов подразумевает работу с продуктом, и периодически возникает необходимость проанализировать поведение продукта, которое отличается от ожидаемого. Автоматизатор должен уметь видеть продукт глазами ручного тестировщика, чтобы самостоятельно принимать решение о сценариях, требующих покрытия автотестами.
  • Автоматизатор должен быть готов к компромиссам. Автотесты – это код, но при этом это плод командных усилий. Вовлеченность автоматизатора в обсуждение сценариев для автотестов и их реализации может быть больше или меньше в зависимости от его опыта и роли в проекте, но в целом нужно слушать и слышать друг друга, уметь приходить к компромиссам и руководствоваться принятыми решениями при выборе сценариев для тестирования и путей их реализации.
  • Важно, чтобы автоматизатор мог свободно читать по-английски профильную литературу и не испытывать от этого дискомфорта. Без этого ему будет трудно в разумные сроки освоить те или иные инструменты и технологии и найти пути решения задач, с которыми он столкнется.
  • Проактивность, взаимовыручка, уменее и готовность задавать вопросы коллегам, ручным тестировщикам, разработчикам и не замыкаться в случае трудностей.

 
Карьера автоматизатора
 

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

Читали Чайку по имени Джонатан Ливингстон?

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

  • C# + WebDriver (да, нам таки нужны end-to-end тесты): NUnit, Page Object, навык написания нехрупких локаторов
  • PowerShell, REST
  • Опыт запуска автотестов в TeamCity (предпочтительно) или Jenkins
  • Живой ум, склонность к анализу, способность к самообучению, готовность решать нестандартные задачи, свободное чтение документации на английском языке

Мы будем рады вашему резюме и неформальному сопроводительному письму (почему вам интересна работа в Veeam, что привлекло вас в нашей вакансии, ваши сильные стороны). Пожалуйста, присылайте резюме с сопроводительным письмом по адресу qa@veeam.com

 
Успехов на нашем поприще.

Отправить в Twitter, Facebook, ВКонтакте | Опубликовано 22.08.2019 в рубрике "Автоматизация"

Комментарии (3)

  1. Pingback : Заметки по автоматизации тестирования — Блоги экспертов | August 23, 2019

    […] Источник […]


  2. Автор комментария : Максим | September 16, 2019

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

    “Желательно, чтобы ручной тестировщик понимал, что именно и как тестирует автотест” - если он их при этом не пишет, мы имеем оверхед в виде аллюра и прочей ненужной отчетности.

    [Ответить]

    Капитан отвечает:

    Максим, добрый день.

    На текущий момент результаты прогона тестов обрабатывают те, кто их пишут – тестировщики-автоматизаторы.

    По поводу ручных тестировщиков есть два нюанса. Первый нюанс описан в статье (не должно быть false negative и false positive тестов + желательно, чтобы ручной тестировщик понимал, что именно и как тестирует автотест – тогда ему будет ясно, что автотест на данный момент может проверить и что нет). Второй нюанс: в перспективе обработку результатов автотестов хочется возложить на ручных тестировщиков, чтобы у них была полная картина по продукту, а у автоматизаторов больше времени на написание автотестов.

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

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

    [Ответить]



Добавить комментарий

Пожалуйста, исправьте результат: дважды два равно



КРАТКОЕ СОДЕРЖАНИЕ

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


ПУТЕВОДИТЕЛЬ

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

ПОДПИСКА

Доступ к самым интересным материалам по электропочте и RSS. Подробности.

ИЩЕЙКА