Команда делает приложение доставки еды, задача недели — промокоды: человек вводит в корзине LETO25 и видит скидку. Можно ждать, пока задачу «доделают», и в последний день пройтись по экрану. А можно до кода спросить, что будет с просроченным промокодом, заранее завести пять разных кодов и на первой же сборке поймать двойную скидку от двойного нажатия.
Разница между этими двумя способами работать и есть роль: тестировщик выясняет, как система ведёт себя на самом деле, и приносит команде картину — что работает, что сломано и чем мы рискуем, выпустив как есть. Роль часто называют QA-инженер или просто QA.
Тестировщик подключается на каждом шаге, а не в конце: он показывает, что сломано и чем это грозит. А решение «чинить сейчас или выпускать» принимает команда.
День тестировщика: одна задача от вопроса до релиза
До кода. Вы задаёте вопросы, на которые в описании нет ответа: что делать с просроченным промокодом, можно ли применить два сразу, складывается ли скидка с акцией. Ответ «хм, а правда, что делать?» — это дырка в требованиях, пойманная, пока починка стоит разговор (как спрашивать). Пока пишут код, вы складываете будущие проверки в чек-лист или тест-кейсы и просите завести пять промокодов с разными условиями: в день приезда сборки их никто быстро не сделает.
Сборка приехала. Три слова из ежедневного обихода: сборка (билд) — работающая версия приложения с номером; тестовый стенд — отдельная копия со своей базой, где можно ломать что угодно; прод (боевая среда) — копия для реальных людей с реальными деньгами. Сборку ставят сначала на стенд, в прод — только после проверок. На двух нажатиях подряд в корзине оказывается скидка минус 500 рублей вместо минус 250. В чат «промокоды сломались» такое не пишут: сначала проверяют, каждый ли раз это повторяется и только ли при быстром нажатии, — потом заводят баг-репорт с шагами, ожидаемым и фактическим результатом, скриншотом и номером сборки.
Перепроверка и релиз. На новой сборке вы повторяете те же шаги, а потом проходите обычный заказ и заказ с акцией: правка могла задеть соседнее — это регресс, проверка того, что раньше работало. Перед релизом говорите вслух, что проверено, что нет и почему: промокод на доставку проверить не успели, таких кодов на стенде нет. Непроверенная область, известная команде, — риск; известная только вам — мина.
Кто вокруг и чего от вас хотят
- Аналитик и владелец продукта — неудобные вопросы до работы, картина перед релизом, ответ «это баг или так задумано».
- Разработчики — баг, который воспроизводится с первого раза; у них же спрашивают про тестовые учётные записи и таблицы с данными.
- Дизайнер — ответ на «это ошибка или просто некрасиво»: «в макете иначе» — основание для бага.
- Поддержка — знает, на что жалуются чаще всего и что ломалось в прошлый раз: источник идей для проверок.
- Руководитель или ведущий тестировщик — приоритеты и ответ на «не успеваю проверить всё, что резать»: молчать про нехватку времени хуже, чем сказать вслух.
Людей вокруг может не быть вовсе: в небольшом продукте тестировщик часто один, и решение «что не успеваем проверить» фактически его; в крупной компании — отдел с общими правилами и ролями вроде автоматизации. От новичка ждут не процесса, а понимания продукта и багов, которые не возвращают (навыки на старте, куда расти).
Зачем команде отдельный человек
Разработчик свой код проверяет, но этого не хватает, и дело не в старательности: установки «как сделать, чтобы работало» и «при каких условиях это сломается» плохо уживаются в одной голове, а автор вдобавок идёт по той же модели, которую построил, — как вычитка собственного текста, где глаз читает задуманное. Свежий человек нажимает кнопку дважды и вставляет промокод с пробелом в конце. Плюс конфликт интересов у срока: находка означает автору ещё один вечер работы, а вам — ничего.
Себя разработчик проверяет на другом уровне — модульными тестами вроде «функция скидки на сумме 1000 и коде 25 % возвращает 750»; двойного срабатывания кнопки такой тест не заметит (уровни тестирования).
Что решает тестировщик, а что — нет
Кажется, что тестировщик — тот, кто «не пускает плохое в прод». На деле его результат — не вердикт «релиз отменяется», а картина:
Скидка применяется дважды при быстром двойном нажатии «Применить». Воспроизводится в трёх случаях из пяти, на любом промокоде. Задевает всех, кто нажимает нервно, — на распродаже таких многие. Потеря — двойная скидка на заказ, деньги реальные. Обхода нет. Не проверено: промокоды на доставку, их на стенде нет.
С этой картиной команда выбирает: чиним сейчас и выпускаем позже; выпускаем и чиним следующей сборкой; выпускаем с заглушкой — кнопка блокируется после первого нажатия. Это вопрос бизнеса, а не тестирования: сколько стоит день задержки, идёт ли завтра реклама. Отвечает владелец продукта, а ваше слово весит ровно столько, насколько точна картина.
Дальше находку взвешивают по важности и срочности — чиним сейчас, «работает как задумано» или «починим потом», — и она идёт по статусам в трекере. Возврат «не воспроизводится» означает «не хватило данных»: добавьте номер сборки, промокод, запись экрана (качество баг-репорта). А пропущенный баг разбирают как дырку в процессе, а не как чью-то вину (разбор причин).
QA, QC и тестирование — где всплывает разница
Вернёмся к вопросу, заданному до кода: что если человек применит промокод, а потом удалит из корзины товар, из-за которого набралась минимальная сумма? Аналитик дописал требование, разработчик учёл случай — вы ничего не тестировали, кода ещё не было, но один баг не родился. Это и есть QA (Quality Assurance, обеспечение качества): работа про то, чтобы проблемы не возникали.
А когда вы на готовой сборке сравниваете, как система работает, с тем, как она должна работать, — это тестирование, действие внутри более широкого QC (Quality Control, контроль качества). QC смотрит на готовое, QA работает с процессом. На практике почти всех зовут «QA», и это нормально; разницу стоит понимать потому, что она объясняет, зачем вас зовут туда, где ещё нечего проверять.
Коротко
- Тестировщик приносит команде картину: что сломано, как часто воспроизводится, кого задевает, что осталось непроверенным.
- Работа начинается не со сборки, а с вопросов по требованиям: там баг стоит разговора, в проде — отката релиза.
- Автор кода проверяет по той же модели, которую построил, и у него конфликт интересов со сроком.
- Решение «чинить сейчас или выпускать» принимает владелец продукта; вес вашего слова равен точности картины.
- Возврат «не воспроизводится» лечится данными; пропущенный баг разбирают как дырку в процессе, а не как вину.
- QA — про то, чтобы проблемы не возникали; QC и тестирование — про проверку готового.
Что почитать дальше
- Что такое тестирование — откуда берутся баги и почему цена ошибки растёт.
- Жизненный цикл разработки и тестирования — в какие моменты вы подключаетесь.
- Тестировщик в Scrum и Agile — как день из этой статьи укладывается в спринт.
- Баг-репорт: как описать проблему — главный навык первых месяцев.