Привет, дорогой читатель! Я, Владимир Зиновьев, ведущий тестировщик в ИТ-команде «Северстали». Если тебя заинтересовала эта статья, то скорее всего ты такой же тестировщик, как и я, и задаёшься вопросом, как эффективно выстроить свою работу. Здесь я поделюсь долгим путём нашей команды со всеми «шишками» и успехами тестирования наших систем в большом MES-проекте. Особенно я бы порекомендовал обратить внимание на раздел с тестированием «Legacy-системы», так как там применялись довольно нестандартные и интересные подходы, по-моему мнению, конечно. Давай погружаться.

Коротко о главном

Итак, давай как в математике:

Дано. Несколько MES-систем, объединённых в один большой MES-проект, которые можно сгруппировать по технологиям:

• первая группа написана на стеке: ORACLE/Postgres + SPRING BOOT + REACT;

• вторая группа: ORACLE + DELPHY.

Имеется. Семь самых крутых бойцов за качество против отмазок типа: «Это не баг, а фича», «На моём ПК всё работает» и т. д.

Найти. Понятный и прозрачный подход к нашей работе.

Для достижения эффективности необходимо решить некоторые вопросы, а именно:

• архитектурный;

• технологический;

• командный.

Архитектурный вопрос

Если посмотреть на стек, о котором я писал ранее, становится понятно, что имеются системы с десктоп-интерфейсом и веб-интерфейсом, которые требуют различных инструментов тестирования. В этих условиях у нашей команды появилась задача, которую я озвучу примерно так: «Найти решение, которое обеспечивает в конечных тестах идентичность, при всём разнообразии технологий». Тут немного поясню: под идентичностью понимается, сколько бы новых систем ни пришло на поддержку в нашу команду, при написании тестов использовались одни и те же методы, подходы и философия. Для простоты оставлю старый добрый мем с человеком-пауком.

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

1. Элементный подход.

2. Функциональный подход.

3. Распределённый подход.

Перед тем, как подробнее рассмотреть подходы, давайте договоримся о понятиях:

• элемент системы – элемент интерфейса тестируемой системы;

• робот – фреймворк тестирования, в котором написаны механики поиска, определения и взаимодействия с элементами системы;

• элемент тестирования – класс в роботе, который отвечает за взаимодействия с элементами системы;

• page-object – паттерн тестирования, который создаёт репозиторий для хранения элементов тестирования (простыми словами, форма с некоторым набором элементов системы).

Элементный подход

Подход включает в себя две сущности: абстрактный page-объект и элемент тестирования, у которых атрибуты (ID, условия поиска, связь page-объекта с элементами) описаны в отдельном настроечном файле.

Преимущества такого подхода:

• все механики в одном месте;

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

• также можно создать page-объект, из которого будем получать элементы тестирования,

• скорость написания кода.

Минусы:

• механики в одном месте ведут к перегруженности;

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

Этот метод будет хорош для маленькой команды и не сильно перегруженного графическими элементами проекта.

Функциональный подход

Подход основан на функциях, к примеру, табличные операции, операции над полями и т. д. Здесь уже присутствует разделение по механикам, а page-объект – это всё то, что находится на экране в текущий момент.

 Преимущества:

• механики логически сгруппированы;

• скорость написания кода;

• поиск элементов организован в коде.

Минусы:

• невозможность вынести общие элементы системы в page-объект,

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

Распределённый подход

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

• общие интерфейсы элементов тестирования;

• элементы тестирования;

• page-объекты, объединяющие элементы;

• тесты, которые используют page-объекты.

Как же этот подход решает главную задачу?

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

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

Page-объекты – в классах типа page мы собираем элементы, которые присутствуют на той или иной форме. Здесь стоит подумать о формах интерфейса, которые используются в нескольких местах.

Так, с архитектурой роботов определились, перейдём к технологиям.

Технологический вопрос

Веб

Для тестирования веб-интерфейса мы использовали связку SpringBootTest + Selenide + TESTNG + Allure. Несколько слов о преимуществах этого стека.

SpringBootTest:

• Spring имеет большой спектр технологий и инструментов от удобства работы ввода/вывода до ИИ-технологий (что считается на момент публикации показателем крутого проекта);

• для примера возьмём одну из задач: «Необходимо замерить время отклика элементов» для мониторинга быстродействия всех систем. И как мы справились: мы подключили Spring AOP, написали класс-аудитор и замерили необходимые нам действия над формой или элементом простым добавлением определённой аннотации;

• в будущем планируем использовать Apache PDFBox с AI, так как появилось много задач на тестирование pdf-отчётов.

Selenide:

• это классика, большинство современных тестов написано на этой технологии, много гайдов в интернете;

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

TESTNG:

• по мнению нашей команды, TestNG имеет очень удобную и гибкую настройку тестов с помощью XML-файла, которая позволяет просто объединить ваши тесты в отдельные наборы.

Allure:

• система отчётности, которую можно внедрить в большинство CI/CD-систем;

• ну и трендовая технология как-никак)

Итак, с вебом всё понятно, но давайте перейдём к более интересной теме — «Тестирование десктоп, или легаси-системы».

Десктоп (легаси)

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

В первые годы моей работы в компании наша команда тестировала систему, написанную на Delphi с использованием элементов DevExpress. Они очень сложны для тестирования, так как имеют очень скромный backdoor (очень мало видимых атрибутов элемента, не распознаются надписи, некоторые кнопки и т. д.). Однако это нас не напугало, и методом проб и ошибок мы нашли идеальный стек для тестирования:

SpringBootTest + UI-AUTOMATION + TESSERACT + TESTNG + ALLURE

Причины использования SpringBootTest, TESTNG, ALLURE те же самые, о которых я писал ранее.

Остановимся на новых:

UI-AUTOMATION – инструмент взаимодействия с элементами системы:

• даёт доступ к WinAPI (если разберёшься в API Windows, то найдёшь множество фич);

• универсальный инструмент для любых фреймворков интерфейсов;

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

TESSERACT – инструмент распознавания текста:

• очень помогает получить текст внутри элементов, надписи, отчетов и другое;

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

А какие технологии использует ваша команда? Напишите в комментариях.

Командный вопрос

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

• итеративная (1 раз в 2 недели);

• ежедневная.

Для поиска эффективной работы с тестами мы пробовали несколько концепций:

1. «Мобилизация» . Когда наступает тот или иной релиз, все начинают его разбирать. В данной концепции есть жирный минус: если в один и тот же день случаются несколько релизов для тестирования, то работа начинает буксовать.

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

3. «Зоны ответственности». Команда делится на небольшие группы (2-3 человека в зависимости от количества тестов), которые отвечают за свою систему. В данной концепции все предыдущие проблемы были решены, а именно:

• при нескольких релизах в день, каждая команда занималась своим;

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

Последнюю концепцию мы используем до сих пор, но при внештатных ситуациях мы прибегаем к «Мобилизации».

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

Заключение

Если ты, дорогой читатель, дошёл до этой главы, хочу сказать тебе спасибо, что прочитал и, надеюсь, выделил для себя что-то полезное. Успехов тебе в твоей работе! Не забудь подписаться на блог «Северстали».