Тестирование — это не «работа QA, меня не касается». Аналитик в нём участвует дважды: он автор критериев приёмки (описывает, что значит «работает правильно») и первый приёмщик (проверяет, что сделали то, что он просил). Тесты делятся на уровни — это пирамида: много быстрых юнит-тестов внизу, меньше интеграционных в середине, совсем чуть-чуть медленных end-to-end сверху. Тест-кейс и критерий приёмки — не одно и то же: критерий говорит «что должно быть верно», тест-кейс — «какие шаги это проверяют». Хороший приёмщик гоняет не только счастливый путь, но и ошибки, и границы (минимум, максимум, ноль, пусто). Рутину и регресс забирают автотесты, человек проверяет смысл.
Однажды я принял фичу за пять минут: открыл, ввёл нормальную сумму, всё посчиталось — «работает, принято». Через неделю прод лёг на том, что кто-то ввёл сумму 0, и система поделила на неё. Баг был не в коде разработчика — он был в моей приёмке: я проверил только то, что и так очевидно работает. С этого дня я понял, что «потыкать и убедиться» — это не приёмка, а самообман. Приёмка — это когда ты заранее знаешь, что именно идёшь ломать.
Зачем аналитику вообще тестирование
Кажется, что тестирование — чужая поляна: есть тестировщики, пусть они и проверяют. Но аналитик стоит в этой цепочке на двух ключевых местах, и обойти их не выйдет.
Он автор критериев приёмки. Прежде чем кто-то что-то протестирует, кто-то должен сказать, что считать правильным поведением. Это и есть критерии приёмки, и пишет их аналитик. Без них тестировщик проверяет «на свой вкус», разработчик трактует требование по-своему, а спор «баг это или фича» становится вечным. Критерии приёмки — часть Definition of Ready: задача не готова входить в работу, пока не сказано, как поймём, что она сделана.
Он первый приёмщик. Когда задача вернулась со словом «готово», именно аналитик чаще всего первым смотрит: сделали ли то, что я описывал. Это не дублирование работы тестировщика — это проверка на соответствие замыслу, а не только на отсутствие багов. Тестировщик ловит «сломалось», аналитик ловит «сделали не то».
Что важно знать
Критерии приёмки удобнее всего писать на языке сценариев — «дано / когда / тогда». Это прямо вытекает из user story и use case: история объясняет «зачем», критерии приёмки превращают её в проверяемые условия. Если в задаче нет ни одного критерия приёмки — её нечем принимать, и тестировать там нечего.
Пирамида тестов простыми словами
Тесты бывают разного «масштаба» — и стоят по-разному. Чтобы это уложить в голове, придумали образ пирамиды: внизу широкое основание из дешёвых быстрых тестов, наверху узкая верхушка из дорогих медленных. Снизу вверх три уровня.
flowchart BT U["Юнит-тесты: много, быстрые, дешёвые"] I["Интеграционные: меньше, средние"] E["End-to-end / e2e: мало, медленные, дорогие"] U --> I --> E
Снизу вверх пирамида читается так. Юнит-тесты — основание: они проверяют один маленький кусочек кода в отрыве от всего остального (например, «функция расчёта скидки на сумму 1000 вернёт 900»). Их много, они выполняются за миллисекунды и стоят дёшево, поэтому их пишут тысячами. Интеграционные — середина: проверяют, что несколько частей работают вместе (сервис реально сходил в базу и сохранил заказ). Их меньше, они медленнее, потому что поднимают больше окружения. End-to-end (e2e) — верхушка: проверяют весь путь целиком, как живой пользователь (открыл сайт, нажал «купить», получил письмо). Они самые медленные и хрупкие, поэтому их держат мало — только на критичные сценарии. Главная мысль: чем выше тест, тем он ближе к реальности, но тем дороже и медленнее, поэтому пирамида широкая внизу и узкая вверху, а не наоборот.
Перевёрнутая пирамида — антипаттерн
Если команда почти не пишет юнит-тестов, зато гоняет десятки медленных e2e через весь интерфейс — это «перевёрнутая пирамида» (её ещё называют «рожок мороженого»). Прогон тестов занимает часы, тесты постоянно мигают «то красные, то зелёные», и команда перестаёт им верить. Когда слышите «у нас тесты идут полтора часа и половина падает без причины» — почти наверняка дело в перекошенной пирамиде.
Тест-кейс не равен критерию приёмки
Это путают чаще всего, а разница простая и важная.
Критерий приёмки — это условие, которое должно быть истинным, чтобы задачу можно было принять. Он на языке поведения: «сумма заказа не может быть отрицательной», «при нулевой сумме система показывает ошибку и не создаёт заказ». Критерий не описывает, как именно щёлкать мышкой — он описывает, что должно быть верно. Это зона аналитика.
Тест-кейс — это конкретная проверка одного критерия: набор шагов, входные данные и ожидаемый результат. «Открыть форму → ввести сумму -5 → нажать Сохранить → ожидаем ошибку „сумма должна быть больше нуля“, заказ не создан». Один критерий приёмки часто разворачивается в несколько тест-кейсов. Это зона тестировщика, хотя аналитик обязан уметь их читать.
| Критерий приёмки | Тест-кейс | |
|---|---|---|
| Отвечает на вопрос | Что должно быть верно? | Какими шагами это проверить? |
| Язык | Поведение, условие | Шаги, данные, ожидаемый результат |
| Кто автор | Аналитик | Тестировщик |
| Сколько | Один на правило | Часто несколько на один критерий |
Позитивные, негативные тесты и границы
Когда вы продумываете, что проверять, мысль идёт по трём направлениям. Разберём на одном поле — «сумма» (целое число, разрешённый диапазон от 1 до 1 000 000).
Позитивный тест — проверяем, что на правильных данных всё работает. Ввели 1500 — заказ создался, сумма сохранилась. Это «счастливый путь», и джуны обычно проверяют только его.
Негативный тест — проверяем, что на неправильных данных система ведёт себя предсказуемо: не падает, а внятно отказывает. Ввели -5, ввели «abc», оставили поле пустым — ожидаем понятную ошибку и отсутствие заказа, а не пятисотку и не молча созданный кривой заказ.
Граничные тесты (boundary) — самое интересное. Баги почти всегда сидят на краях диапазона, а не в середине. Для поля «сумма» от 1 до 1 000 000 проверяем не «1500», а сами границы и их окрестности:
- 0 — на единицу ниже минимума: должна быть ошибка (а у меня тогда поделили на ноль).
- 1 — ровно минимум: должно работать.
- 1 000 000 — ровно максимум: должно работать.
- 1 000 001 — на единицу выше максимума: должна быть ошибка.
- пусто — поле не заполнено: понятная ошибка, не падение.
Правило краёв
Когда описываете критерий с диапазоном или лимитом, всегда явно проговаривайте, что происходит ровно на границе и сразу за ней. «Сумма от 1 до 1 000 000» — а 0 это ошибка или пусто? а 1 000 000 ещё можно или уже нет? Если в требовании этого нет — разработчик решит сам, и вы узнаете о его решении на проде.
Что вы проверяете руками, а что отдаёте автотестам
Принимать руками всё на каждой задаче невозможно и не нужно — для повторяемого есть автотесты. Разделение примерно такое.
Аналитик на приёмке смотрит: счастливый путь (главный сценарий действительно решает задачу пользователя), ключевые ошибки (отказы внятные, система не падает), границы критичных полей. Цель — убедиться, что сделали то, что задумано, и что очевидные дыры закрыты. Это вдумчивый, осмысленный проход по сценарию, а не перебор всех комбинаций.
Автотестам отдают: всё, что нужно проверять снова и снова при каждом изменении, — перебор граничных значений, десятки комбинаций входных данных, проверку, что старое не сломалось. Машина делает это за секунды и не устаёт, человек — медленно и с ошибками от скуки.
Регресс простыми словами
Регресс (регрессия) — это когда новое изменение ломает то, что раньше работало. Починили скидку — отвалился расчёт доставки, который никто не трогал. Это самый коварный класс багов, потому что проверять-то идут новую фичу, а сломалось старое и проверять его уже никто не собирался.
Регрессионное тестирование — это прогон набора проверок по уже работающей функциональности после каждого изменения, чтобы поймать такие поломки. Делать это руками каждый раз нереально — поэтому регресс автоматизируют: накопленные тест-кейсы превращают в автотесты, и они гоняются на каждый коммит (это часть CI/CD). Отсюда и нужна нижняя часть пирамиды: дешёвые быстрые тесты — это и есть постоянная страховка от регресса.
Роль QA и место аналитика рядом
QA-инженер (тестировщик) — отдельная роль, и подробно о ней в записи кто все эти люди в IT-команде. Если коротко: тестировщик профессионально ищет, где система ломается, проектирует тест-кейсы, ведёт регресс, автоматизирует проверки. Аналитик его не заменяет и не дублирует — он даёт тестировщику опору (критерии приёмки) и проверяет соответствие замыслу. Хорошая связка: аналитик говорит «что должно быть верно», тестировщик говорит «вот где это неверно».
Откуда это взялось
Образ пирамиды тестов популяризировал Майк Кон в книге «Succeeding with Agile» около 2009 года — именно он нарисовал ту самую картинку с юнит-тестами в основании и UI-тестами на верхушке. Идея «тестируй раньше и ниже» позже выросла в подход shift-left testing: сдвигать проверку качества как можно ближе к началу разработки, а не оставлять её на финал. Для аналитика это прямое следствие — критерии приёмки и продумывание границ на этапе требований и есть тот самый сдвиг влево: дешевле поймать дыру в спеке, чем баг на проде.
Частые вопросы
Зачем аналитику разбираться в тестировании, если есть QA?
Потому что аналитик стоит в цепочке качества на двух местах, которые QA не закрывает. Во-первых, он автор критериев приёмки — без них тестировщику нечего проверять, и спор «баг или фича» становится бесконечным. Во-вторых, он первый приёмщик: проверяет, что сделали именно то, что задумано, а не просто «без багов». QA ловит «сломалось», аналитик ловит «сделали не то» — это разные проверки.
Чем критерий приёмки отличается от тест-кейса?
Критерий приёмки — это условие, которое должно быть истинным, чтобы задачу приняли («при нулевой сумме система показывает ошибку и не создаёт заказ»). Тест-кейс — это конкретная проверка этого условия: шаги, входные данные и ожидаемый результат («ввести 0 → нажать Сохранить → ожидаем ошибку, заказ не создан»). Критерии пишет аналитик, тест-кейсы — тестировщик, и на один критерий обычно приходится несколько тест-кейсов.
Что такое граничные тесты и зачем они нужны?
Граничные (boundary) тесты проверяют поведение на краях допустимого диапазона, а не в его середине, потому что баги почти всегда сидят на границах. Для поля «сумма от 1 до 1 000 000» проверяют не «1500», а 0, 1, 1 000 000, 1 000 001 и пустое значение — то есть сами границы и значения сразу за ними. Аналитику важно проговаривать в требованиях, что происходит ровно на границе и сразу за ней, иначе разработчик решит это сам.