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

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

Лирическое отступление

Это только присказка, сказка впереди

В начале 2000-x я работал в IT-компании, которая выполняла несколько аутсорсинговых проектов для компании Integrated Genomics. Проекты были связаны с расшифровкой геномов простейших организмов. К примеру, одна из утилит искала фрагменты (праймеры) с определенными свойствами в геноме кишечной палочки. На входе утилиты была последовательность ДНК, загружаемая из публичной базы геномов ERGO и состоящая из азотистых оснований. На выходе таблица фрагментов и их позиция в цепочке ДНК. Далее эти фрагменты использовались биологами для синтеза геномов. Задача была сравнительно простой. Нужно было лишь позаботиться о том, чтобы программа не выжирала всю оперативную память довольно слабых машин, которые были у нас на тот момент. Сложность других проектов заключалась в том, что они находились на стыке трех дисциплин: биологии, математики и информатики. В тех случаях, когда алгоритм задачи был понятен, его реализация в программном коде не представляла трудности. Но когда сама задача была неопределенной, и не находилось никого кто мог бы ее формализовать, это был серьезный вызов.

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

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

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

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

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

Ручной тестировщик с глубоким пониманием продукта и методик тестирования и разработчик с опытом программирования отлично дополняют друг друга. Первый силен в постановке задачи (use case -> test case), второй в ее реализации. Встает вопрос: почему среди автоматизаторов встречается много ручных тестировщиков? На это есть несколько причин:

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

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

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

Опасение потерять в карьерном росте и зарплате.

Разберем эти моменты.

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

Задачи у автоматизатора интересные и зачастую сложные. В первую очередь стоит вспомнить про знаменитую пирамиду Фаулера. Модульные, интеграционные, end-to-end тесты подразумевают вдумчивый подход к структуре тестов и выбору инструментов в соответствии с функциональностью продуктов, для которых пишем автотесты. Если говорить о продуктах, разрабатываемых в Veeam, то автоматизатору понадобится работать с REST, WebDriver, Microsoft SQL Server, Amazon Web Services, Microsoft Azure, VMware vCenter, Hyper-V список не исчерпан. У каждого из облаков и гипервизоров свой API и свои скелеты в шкафу. Порой приходится писать код на различных языках программирования, использовать заглушки, семафоры, создавать свои обертки и т.п.

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

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

Нужно обратить внимание на качество самих автотестов. Кто сторожит сторожей? Какому автотесту можно доверять? Автотест должен быть эффективным по критерию количество затраченных на него усилий / полученный результат, автономным, стабильным (нехрупким), быстрым, надежным (никаких false positive и false negative). В автотесте должен быть понятный, хороший код с точки зрения возможностей языка программирования, чтобы этот код можно было легко расширять и изменять.

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

Что в Veeam?

В компании Veeam мы будем рады новым боевым товарищам с опытом программирования на C# (например, web-интерфейсы, десктопные приложения, консольные утилиты и т.п.). У нас в Veeam есть много продуктов. Технологии в них могут различаться. В автотестах для нескольких продуктов мы опираемся на REST и WebDriver. Если у вас нет опыта с этими технологиями, но вы уверенно себя чувствуете в написании кода на C# и питаете интерес к автоматизации тестирования, то, возможно, мы также найдем точки соприкосновения.

Мы будем рады вашему резюме и паре абзацев о том, что вас привлекает в автоматизации, о ваших сильных сторонах и профессиональных планах. Пишите нам на ящик qa@veeam.com внимательно прочитаем. Если укажете в теме письма [Хабр] (например, [Хабр] Позиция автоматизатора), будет плюс в карму =)

Да пребудет с Вами Сила.

Привет, меня зовут Фахридин Джамолидинов, я специалист департамента тестирования в Ростелеком ИТ. Занимаюсь автоматизацией тестирования основного сайта компании rt.ru и сегодня я расскажу, как про мы внедрили тестирование скриншотами, или как помочь автотестам видеть ошибки.

Наш сайт это не только витрина для информирования клиентов и продаж услуг и товаров для сегментов B2C, B2B и B2O, он ещё предназначен для обслуживания текущих клиентов: FAQ, чат, формы обратной связи, платежные формы и т.п.Он постоянно обновляется, и каждый раз после выпуска новой версии нужно проверять сотни страниц с богатым, динамичным UI на работоспособность в браузерах и адаптивность вёрстки.

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

Как всё начиналось

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

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

Итого, что нам требовалось:

• возможность сравнения всей страницы целиком, отдельных элементов, групп элементов;

• проверка на адаптивность (десктоп 1920px, планшет 768px, мобила 360px);

• поддержка минимум двух браузеров: Chrome и Firefox;

• игнорирование и скрытие элементов (групп элементов) при сравнениях;

• удобочитаемый отчет с подсветкой отличий.

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

Java основной язык программирования;
TestNG фреймворк автоматизации тестирования;
Maven сборщик;
Selenide обертка над Selenium, которая упрощает написание веб автотестов;
Selenoid GGR сервер-балансировщик для запуска изолированных браузеров в Docker контейнерах;
Allure фреймворк для создания отчётов автотестов и плагин ScreenDiff;
aShot библиотека для попиксельного сравнения изображений.

Благодаря балансировщику Selenoid GGR (Go Grid Router), в котором настроено распределение на несколько машин, мы имеем возможность поддержки нескольких браузеров (при необходимости: нескольких версий), плюс запуск тестов (изолированных браузеров) в параллель (~40 потоков).

В этой статье мы покажем как работает автотестирование по скриншотам будем акцентировать внимание на функционал aShot (кстати, спасибо ребятам из Яндекса за такие полезные инструменты как aShot и Allure) и на самом процессе.

Как это работает

Тесты условно разбиты на две группы:

• fullscreen страницы целиком (с прокручиванием);

• element(s) отдельный элемент (группа элементов)

Каждая из групп представляет из себя data-driven тесты, т.е. каждая страница, элемент (группа элементов) это отдельный параметризованный тест на основе DataProvider, а вся задача сводится к сравнению двух скриншотов. Например, регресс верстки списка Landing Page, в виде схемы выглядит так:

Избавляемся от динамики

Динамика в основном проявляется в виде:

• каретки в полях ввода, которая мигает (может пропасть или появиться);

• CSS Transition и Animations;

• видео с автопроигрыванием и ряд других моментов.

Там, где есть возможность отключаем (инъекцией CSS):

Каретку делаем прозрачной (задаем значениецвета = transparent). Таким образом она всегда будет невидимой и не будет влиять на результат. CSS Transition обнуляем transitions-delay и transition-duration. CSS Animation обнуляем animation-delay, animation-duration и ставим состояние анимации в паузу, устанавливаяanimation-play-stateвpaused.

*, *::after, *::before {    caret-color: transparent !important;    transition-delay: 0s !important;     transition-duration: 0s !important;    animation-delay: 0s !important;     animation-duration: 0s !important;    animation-play-state: paused !important;    overflow: hidden; // Опционально скрываем полосу прокрутки}

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

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

Если с десктоп браузером всё понятно, с планшетом и мобилой встал вопрос, как проще эмулировать браузер. Было решено, что пока достаточно использовать фичу вебдрайвера mobileEmulation. Пример скрипта поднятия вебдрайвера Chrome с включением этой опции, в режиме планшета и выбором девайса = iPad:

@Override    public WebDriver createDriver(DesiredCapabilities capabilities) {WebDriverManager.chromedriver().setup();Map<String, String> mobileEmulation = new HashMap<>();mobileEmulation.put("deviceName", "iPad");ChromeOptions chromeOptions = new ChromeOptions();chromeOptions.setExperimentalOption("mobileEmulation", mobileEmulation);WebDriver driver = new ChromeDriver(chromeOptions);WebDriverRunner.setWebDriver(driver);return driver;    }

Снимаем скриншоты

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

screens / {browser} / {desktop | tablet | mobile} / {region} в зависимости от выбранного для запуска браузера, устройства (режима адаптивности) и регионов (некоторые компоненты могут быть регионозависимы, т.е. отображаться по-разному в зависимости от выбранного пользователем региона).

Название файла состоит обычно из:

• для fullscreen (страницы целиком) = {URL path} + опционально {query}, {ref};

• для отдельного элемента | групп элементов = {URL path} + {уникальный class | id | path} (тут на усмотрение кому как удобно, главное, чтобы можно было выделить уникальное значение)

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

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

Пример снятия скриншота всей страницы (fullscreen):

Создаем объект Screenshot AShot, перед вызовом метода takeScreenshot() вызываем метод shootingStrategy(), в параметрах которого задаем правило съемки viewportPasting(300), т.е. снимать скриншот с прокручиванием, с таймаутом 300 мс. AShot по умолчанию использует jQuery для поиска координат, при его отсутствии, необходимо включить поиск координат с помощью WebDriver API предварительно вызвав метод coordsProvider(new WebDriverCoordsProvider()).

Screenshot actualScreenshot = new AShot()   .shootingStrategy(ShootingStrategies.viewportPasting(200))   .coordsProvider(new WebDriverCoordsProvider())   .takeScreenshot(getWebDriver());

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

Черные области при прокруткеНекорректный масштаб и склейка областей при прокрутке

Погуглив и проанализировав DPR (Device Pixel Ratio) значения страниц в разных режимах, стало понятно, что дело скорее всего в соотношении пикселей устройств, которые мы эмулируем. Запустив window.devicePixelRatio;в консоли браузера, можно найти его. Задали другой shootingStrategy, указав подходящий устройству DPR scaling в параметрах, и таким образом избавились от вышеуказанных проблем.
Для режима планшет (iPad) указали ShootingStrategies.viewportRetina(600,0,0,2f).
Для мобилы (Pixel 2XL) указали ShootingStrategies.viewportRetina(600,0,0,3.5f)

Пример снятия скриншота конкретного элемента (группы элементов):

При вызове метода takeScreenshot(), в параметрах, помимо текущего WebDriver, передаем еще элемент WebElement либо коллекцию элементов Collection <WebElement>, по которым мы хотим получить скриншот:

Collection<WebElement> elements = new ArrayList<>();   elements.add($x("//div[contains(@class,'rtk-offer-list')]")); // допуслуги и оборудование   elements.add($x("//div[@class='rtk-offer__legend']")); // блок ценыScreenshot actualScreenshot = new AShot()   .shootingStrategy(ShootingStrategies.viewportPasting(200))   .coordsProvider(new WebDriverCoordsProvider())   .takeScreenshot(getWebDriver(),elements);

Снятие скриншота c установкой игнорирований элемента(-ов) при сравнении:

Создаем set из элементов, которые хотим игнорировать при сравнениях:

Set<By> ignoredElements = new HashSet();ignoredElements.add(By.xpath(xpath);

и передаем при снятии актуального скриншота этот набор вызовом метода ignoredElements(final Set ignoredElements)

Screenshot actualScreenshot = new AShot()   .shootingStrategy(ShootingStrategies.viewportPasting(200))   .coordsProvider(new WebDriverCoordsProvider())   .ignoredElements(ignoredElements)   .takeScreenshot(getWebDriver());

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

expectedScreenshot.setIgnoredAreas(actualScreenshot.getIgnoredAreas());

Сравнение скриншотов

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

ImageDiff diff = new ImageDiffer().withDiffMarkupPolicy(new ImageMarkupPolicy().withDiffColor(Color.RED)).makeDiff(expectedScreenshot, actualScreenshot);    if(diff.getDiffSize()!=0){       Allure.label("testType", "screenshotDiff");       attachImg("expected", expectedScreenshot.getImage());       attachImg("actual", actualScreenshot.getImage());       attachImg("diff", diff.getMarkedImage());       attachImg("diff (прозрачность)", diff.getTransparentMarkedImage());       Assert.fail("Скрины отличаются");    }

Пример отчета с шагами и вложениями (без блока Screen Diff)

Для удобства просмотра отличий используем плагин Allure ScreenDiff, который добавляет специальный блок в сценарий, внутри отчёта, с двумя режимами:

• Отображение отличий с подсветкой (Show diff);

• Отображение формы с режимом наложения (Overlay) с передвигаемым по горизонтали ползунком для удобного визуального сопоставления текущего и ожидаемого результата.

Отображение отличий с подсветкой (Show diff) Отображение формы с режимом наложения (Overlay)

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

А в чём польза?

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

Пользователи мобильной версии версии сайта бренда долгое время вместо кнопки Узнайте больше видели Узнайте боль (спасибо ребятам из Альфа-банка, которые первыми это заметили). Это один из примеров, который вызывает больше улыбку чем неудобство, но бывают ситуации, которые не столь безобидны. На этом пока всё. Всем стабильных тестов! :)

Привет, Хабр!
Недавно мы провели Kolesa QA Meetup онлайн-встречу для Mobile и Web QA-инженеров и тестировщиков. На примере кейсов Kolesa Group ребята рассказали, как улучшают процессы обеспечения качества в продуктах и автоматизируют тестирование. Делимся видео докладов.

Независимый мокинг зависимостей в Koin, Аида Сундетова, Mobile QA-инженер

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

QA-центрический подход к разработке, Игорь Бучинский, ведущий Mobile QA-инженер в Kolesa Group

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

Пути подготовки данных к автотесту, Сергей Рыжков, Web QA-инженер в Kolesa Group

Сергей рассказывает о том, какими способами можно готовить данные к автотестам, о плюсах и минусах каждого из способов и о том, как это работает в Kolesa Group.

QAчественные меры, Асель Абильмажинова, Web QA-инженер в Kolesa Group

Асель рассказывает о нашем опыте перехода от тестирования к полноценному Quality Assurance и о мерах, предпринимаемых командой для обеспечения лучшего качества продуктов. Она затрагивает тему shift left и важность проведения ревью требований, рассказывает о том, как внедряли чек-листы в Kolesa Group. А еще, делится опытом поддержания базы знаний в актуальном состоянии, повышения awareness того, что происходит в продуктах среди сотрудников и реагирования на фейлы на проде.