Всем привет! Меня зовут Саша, я — старший специалист по автоматизации тестирования в компании ITFB Group. По роду своей профессиональной деятельности я общаюсь с большим количеством своих коллег, даю советы, рекомендации, а также занимаюсь упрощением и улучшением процессов тестирования. На одном проекте у нас возникла необходимость уйти от Jira как системы управления тестами, и я взялся за эту исследовательскую задачу, чтобы воплотить ее в жизнь. Всем, кому интересна эта история, — добро пожаловать под кат.

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

• максимально быстро и точно уметь переносить все тест-кейсы из Jira;

• запускать автоматизированные тесты по одному или целыми группами без необходимости открывать GitLab CI/CD;

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

Мы изучили большое количество систем и сделали по каждой определенные выводы. Например, TestRail выглядит красиво, но не столь изящно, как того хотелось бы мне. Тем более, что пришлось бы повозиться с ее подключением, а также разбираться с интеграцией с Jira и Jenkins. Потом я вспомнил, что коллеги как-то рассказывали про еще одну отечественную разработку — Allure TestOps. Поизучав ее возможности, я понял, что это то, что мне нужно.

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

Оказалось, что перенос тестов из Jira был нетривиальной, но решаемой при помощи поддержки задачей. Скрипт был найден, настройки для переноса описаны, всё запущено, и несколько тысяч тестов перенеслись в Test Cases Allure TestOps без каких-либо проблем. Первый пункт требований был выполнен.

Перейдя ко второму пункту, я обнаружил, что сам Allure TestOps легко подключается к GitLab CI/CD и позволяет запускать автоматизированные тесты, не переходя по сторонним ссылкам, а результаты не только отображает в форме привычного Allure отчета, но и ищет подобные ошибки, которые встречаются в других запусках, что также упрощает жизнь автотестировщикам при исправлении ошибок.

Также оказалось, что для настройки связи между Allure TestOps и GitLab CI/CD нашему DevOps-инженеру потребовалось минимальное количество времени, и для написания инструкции по запуску тестов для нового сотрудника у нас ушла всего пара часов.

Пример инструкции:

1. Выбрать тесты, которые хочется прогнать. Это могут быть как единичные тесты, так и целые группы (папки).

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

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

4. Нажать кнопку «Подтвердить» и наслаждаться результатом.

Allure уже знает, сколько есть автоматизированных тестов, а сколько ручных.

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

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

1. @JiraIssue — для быстрого перехода из Allure TestOps на задачу в Jira.

2. @AllureId — для связи кода и самого теста.

3. @Section1, @Section2 — для структурирования тестов по папкам.

4. @Owner — для присваивания авторства автотеста, чтобы впоследствии было проще найти того, кто должен исправлять ошибки/вносить изменения в код.

5. @Priority — для задания приоритета теста в прогоне.

Следующий код описывает аннотацию, которая используется для связи тестов в самом Allure TestOps с соответствующей задачей в Jira:

import	io.qameta.allure.LabelAnnotation;

import	java.lang.annotation.Documented;
import	java.lang.annotation.ElementType;
import	java.lang.annotation.Inherited;
import	java.lang.annotation.Retention;
import	java.lang.annotation.RetentionPolicy;
import	java.lang.annotation.Target;

@Documented
@Inherited
@Retention (Retention Policy.RUNTIME)
@Target({ElementType.METHOD, ElementType.TYPE})
@LabelAnnotation(
name = "jira"
public @interface JiraIssue {
String[] value();
}

Здесь показано применение аннотаций непосредственно к самому тесту:

@Test(
Groups = {RELEASE_2024, REGRESS},
description = “Создание заявления от имени физ.лица”,
dataProvider = “applicationTypeProvider”)
@AllureId(“37625”)
@JiraIssue(“Jira-24150”)
@Priority(“High”)
@Section2(“35647”)
@Section1(“Релизы 2024”)
@Owner(“DmitrievAI”)
Public void creatingApplicationOnBehalfOfIndividualTest() {
Steps()…
}

В итоге с отказом от Jira TMS выиграла вся команда: функциональные тестировщики стали быстрее писать тесты, приводить их в порядок, а также при необходимости запускать со страницы описания, без необходимости изучать особенности работы с GitLab CI/CD. Автоматизаторы могли сразу же видеть привязку своих тестов к самим тест-кейсам и к запуску в GitLab CI/CD, а также оперативно замечать нестыковки в работе систем и устранять ошибки и/или заводить дефекты. Лид по тестированию получил мощнейший инструмент для изучения покрытия функциональности, а также стабильность работы автотестов и генерации отчетов по всей работе своей команды.

Саша, старший специалист по автоматизации тестирования ITFB Group