Ответ
На проекте применялся адаптированный гибкий жизненный цикл тестирования (Agile STLC), встроенный в двухнедельные спринты.
Фазы цикла в рамках спринта:
-
Анализ требований и планирование:
- Участие QA в Sprint Planning и Backlog Refinement.
- Анализ user stories, определение тестовых сценариев и оценка усилий.
- Создание тест-кейсов в TestRail с привязкой к задачам в Jira.
-
Разработка тестов:
- Параллельная с разработкой функционала написание автотестов (Python + Pytest + Selenium/Requests).
- Проектирование тестовых данных и подготовка стендов.
-
Выполнение тестирования:
- Дымовое тестирование (Smoke): После каждого успешного билда в CI (Jenkins/GitLab CI).
- Функциональное/интеграционное тестирование: По мере готовности функциональности.
- Регрессионное тестирование: Автоматический прогон перед мержем в master и во время релизного кандидата.
-
Отчетность и закрытие:
- Логирование дефектов в Jira с четким шаблоном: Шаги воспроизведения, Фактический/Ожидаемый результат, Серьезность, Окружение, Логи/скриншоты.
- Участие в Sprint Review (демонстрация) и Sprint Retrospective (улучшение процессов).
Интеграция с CI/CD (пример):
# .gitlab-ci.yml
stages:
- build
- test
- deploy
automated_tests:
stage: test
script:
- pip install -r requirements.txt
- pytest tests/ --alluredir=allure-results # Запуск тестов и сбор отчетов
artifacts:
when: always
paths:
- allure-results/
allow_failure: false # Блокировка пайплайна при падении тестов
Ключевые метрики: Процент автоматизации, количество дефектов, найденных на ранних этапах (Shift-Left), время прохождения регресса.
Ответ 18+ 🔞
Да ты посмотри, какая красота, блядь! Ну прям по науке, всё расписано, как по нотам. Ага, «адаптированный гибкий жизненный цикл», сука. А по-нашему это значит — мы, тестировщики, впрягаемся в эту спринтовую телегу и несёмся, блядь, сломя голову, чтобы всех успеть.
Слушай, как это у нас было. Всё по этим вот фазам, да.
Первая фаза — планирование, или «всем встать в позу мыслителя». Сидим мы на этих Sprint Planning, блядь. Разработчики что-то бормочут про «user stories», а мы, QA, уже чувствуем подвох. Подозрение ебать чувствую! Смотрю на таску — вроде «кнопочку добавить». А в голове уже проносится: «А если её нажать десять раз? А если интернет отвалится? А если юзер — полупидор и введёт вместо цифр иероглифы?». Сразу в TestRail начинаю строчить кейсы, чтоб потом не орать «а я говорил!». Привязываю к Jira, чтобы этот самый разработчик, который накосячил, не отвертелся, хитрая жопа.
Вторая — разработка тестов, она же «опережающий удар». Пока эти кодёры что-то там компилируют, мы уже пишем на них автотесты, блядь! Python, Pytest, Selenium — вся эта хуйня. Чувак, это как минировать поле, пока враг ещё даже не вышел из казармы. Красота! Подготовили стенд, данные тестовые нагенерили — сидим, ждём, когда их творение можно будет начинать ебашить.
Третья — выполнение, она же «час расплаты». Выкатили билд — сразу дымовой тест. Если этот дым, блядь, не задымился — можно дальше смотреть. Потом начинается основное веселье: функциональное тестирование. Тут-то и вылезают все косяки. «Ожидалось, что кнопка будет зелёная, а она, сука, фиолетовая!». Или интеграция с какой-нибудь левой службой отваливается. А потом — регресс. Это святое, блядь. Запускаем всю нашу ораву автотестов и молимся, чтобы они всё не разнесли в хлам. Удивление пиздец, когда после мелкой правки в профиле ломается оплата.
Четвёртая — отчётность, она же «ты чё, мудак, накосячил?». Вот тут важно не просто написать «не работает». Надо, блядь, так багрепорт в Jira оформить, чтоб разработчик сам от себя охуел. Шаги воспроизведения, скриншоты, логи, окружение — всё, как в учебнике. Чтобы он не смог сказать «а у меня работает». Потом на Sprint Review сидишь, киваешь, когда показывают фичу, а внутри думаешь: «Да, конечно, работает… после того как я тебе три бага впендюрил». А на ретроспективе уже можно и поругаться, для разрядки.
А самое, блядь, вкусное — это когда всё это в CI/CD вшито. Смотри, какой красивый кусок конфига:
# .gitlab-ci.yml
stages:
- build
- test
- deploy
automated_tests:
stage: test
script:
- pip install -r requirements.txt
- pytest tests/ --alluredir=allure-results # Запуск тестов и сбор отчетов
artifacts:
when: always
paths:
- allure-results/
allow_failure: false # Блокировка пайплайна при падении тестов
Видишь эту строчку allow_failure: false? Это наше всё, блядь! Это значит, что если наши тесты посрутся — вся эта красивая цепочка сборки и деплоя накрывается медным тазом. Никакой кривой код в мастер не проскочит. Чувствуешь власть? А потом ещё и отчёт в Allure красивый сгенерируется, можно ткнуть в него носом менеджера: «Вот, смотри, где у нас проблемные места, ебанашка!».
Метрики, говоришь? Ну, «процент автоматизации» — это чтобы начальство радовалось, цифры любит. «Количество дефектов на ранних этапах» — это наш принцип «Shift-Left», поймать баг, пока он дешёвый, а не когда он уже на проде у клиента вылез. А «время прохождения регресса» — это чтобы мы не ждали этих тестов сутки, а успевали выпить кофе.
Вот так и живём, блядь. Не жизнь, а сплошной цикл, в рот меня чих-пых. Но зато как-то системно, а не абы как.