Ответ
На проекте использовался итеративный подход, объединяющий следующие этапы:
1. Подготовительные этапы:
- Анализ требований: участие в уточнении user stories, выявление рисков и противоречий.
- Планирование: определение объёма тестирования, оценка усилий, выбор инструментов.
- Дизайн тестов: создание тест-кейсов, чек-листов, подготовка тестовых данных и стендов.
2. Основные этапы выполнения:
- Модульное (Unit) тестирование: проводилось разработчиками (например, с использованием JUnit, pytest).
- Интеграционное тестирование: проверка взаимодействия между модулями и внешними сервисами.
- Системное (E2E) тестирование:
- Ручное: smoke, регрессионное, исследовательское и UI/UX-тестирование.
- Автоматизированное: критичные пользовательские сценарии (например, через Selenium WebDriver или Cypress).
3. Заключительные этапы:
- Приёмочное (UAT) тестирование: проверка заказчиком или бизнес-аналитиком.
- Регрессионное тестирование: после каждого изменения кода или фикса критичных дефектов.
- Отчётность: ведение баг-трекера (Jira), анализ метрик (test coverage, defect density), составление отчётов о тестировании.
Пример автоматизированного E2E-теста (Python + Playwright):
import pytest
from playwright.sync_api import Page, expect
def test_user_login(page: Page):
page.goto("/login")
page.fill("#username", "test_user")
page.fill("#password", "secure_pass")
page.click("button[type='submit']")
expect(page).to_have_url("/dashboard")
expect(page.locator(".welcome-message")).to_contain_text("Welcome")Ответ 18+ 🔞
Так, слушай, смотри, как мы тут на проекте крутились, блядь. Всё по науке, но с таким пиздецом, что мама не горюй.
Сначала, конечно, подготовка, этап такой, предстартовый. Анализ требований — сидим, читаем эти user stories, а там такое написано, что волосы дыбом, ёпта. Находим риски и противоречия, а их, блядь, овердохуища. Потом планирование — прикидываем, сколько нам на это всего надо, какой стенд, какие инструменты. Дизайн тестов — вот тут начинается веселье: пишем тест-кейсы, чек-листы, готовим тестовые данные. А данные эти, сука, иногда такие, что хоть святых выноси — то дата рождения в будущем, то имя из одних цифр.
Дальше — основная движуха. Модульное тестирование — это за разработчиками, они там со своими JUnit'ами ковыряются. Потом интеграционное — начинаем стыковать модули, а они, блядь, как кошка с собакой, друг друга не понимают. И вот кульминация — системное, E2E.
- Ручное — дымовое, регрессия, исследовательское. Сидишь, тыкаешь в интерфейс, а он тебе: «Ошибка 500». И думаешь — ну ядрёна вошь, опять.
- Автоматизированное — тут уже красота. Написали скрипты на Selenium или Cypress, запустили — и смотришь, как оно само всё проходится. Красота, блядь. Пока не упадёт на третьем шаге, потому что фронтенд-разработчик кнопку переименовал.
Под конец, когда уже все выдохлись, заключительные этапы. Приёмочное (UAT) — отдаём заказчику, а он такой: «А я думал, тут будет не так». Регрессионное — после каждого чиха, блядь, после каждого фикса бага надо всё перепроверять, а то как бы хуже не стало. И отчётность — сидишь в Jira, считаешь баги, анализируешь метрики, пишешь отчёты. А в отчёте одно и то же: «Найдены дефекты, часть исправлена, остальные в работе». Классика, блядь.
Вот, например, красота в коде, автоматизация, чтобы не тыкать каждый раз руками:
import pytest
from playwright.sync_api import Page, expect
def test_user_login(page: Page):
page.goto("/login")
page.fill("#username", "test_user")
page.fill("#password", "secure_pass")
page.click("button[type='submit']")
expect(page).to_have_url("/dashboard")
expect(page.locator(".welcome-message")).to_contain_text("Welcome")Смотришь на это и думаешь — эх, сейчас запущу, и оно само всё сделает. Ан нет, сука, а этот ".welcome-message" уже десять раз поменяли, и тест опять не работает. Вот и вся наша жизнь, в рот меня чих-пых.