Переезд с Jira
Всем привет! Меня зовут Саша, я — старший специалист по автоматизации тестирования в компании 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-инженеру потребовалось минимальное количество времени, и для написания инструкции по запуску тестов для нового сотрудника у нас ушла всего пара часов.
Пример инструкции:
Выбрать тесты, которые хочется прогнать. Это могут быть как единичные тесты, так и целые группы (папки).
Перейти в меню запуска тестов и увидеть количество ручных и автоматизированных тестов в полученной выборке.
Задать необходимое окружение, если оно требуется. По умолчанию всё уже заранее настроено на готовый запуск по клику.
Нажать кнопку «Подтвердить» и наслаждаться результатом.
Allure уже знает, сколько есть автоматизированных тестов, а сколько ручных.
В итоге после проделанных операций прямо на странице с тест-кейсом появится очередная строка с информацией о результате его запуска. Также можно провалиться в нее и увидеть, как тест запускался, как проходил, на чем падал и много другой полезной информации.
В разговоре с функциональными тестировщиками было отмечено, что стало намного приятнее работать и уменьшилось количество проблем, связанных с редактированием того или иного теста или шага в нем, а также в структурировании самих тестов по папкам. Да и сами тесты перестали выглядеть такими громоздкими, как было раньше. Автоматизаторы подчеркнули удобство в связи кода и самого теста, что ускорило работу на проекте. Связать автотесты с Allure TestOps оказалось весьма простой задачей, которая была выполнена при помощи нескольких аннотаций:
@JiraIssue — для быстрого перехода из Allure TestOps на задачу в Jira.
@AllureId — для связи кода и самого теста.
@Section1, @Section2 — для структурирования тестов по папкам.
@Owner — для присваивания авторства автотеста, чтобы впоследствии было проще найти того, кто должен исправлять ошибки/вносить изменения в код.
@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
