Чем тестировщик занят на работе

Если вы уже работали тестировщиком, большая часть урока вам знакома: пролистайте до раздела «Что тестировщик решает, а что нет».

Вторая неделя работы в MarketCove. Утром вы открываете трекер, и на вас назначены три карточки:

• MC-418 — баг в корзине, Настя перевела его в «Исправлен», нужно перепроверить;
• MC-431 — «Бесплатная доставка от 3000 ₽», задача выложена на стейджинг, нужно проверить;
• MC-440 — «Отзывы на карточке товара», Олег дописал требования, разработка начнётся в понедельник.

В чате Света пересылает жалобу: покупатель говорит, что в письме о заказе стоит не та сумма. А Ирина напоминает, что завтра релиз и нужен регресс.

Никто не просит вас «обеспечить качество продукта». День складывается из конкретных задач, у каждой понятный результат: баг закрыт или возвращён, задача проверена, вопросы к требованиям заданы.

Что разберём:

• из каких задач состоит рабочий день тестировщика;
• зачем проверять задачу, если разработчик уже проверил её сам;
• что тестировщик решает, а что нет;
• кто читает то, что вы пишете.

---

Из чего состоит рабочий день

Задачи тестировщика повторяются изо дня в день. Доли меняются: перед релизом больше регресса, в начале работы над новой функцией больше чтения требований. Набор почти всегда один и тот же.

Задача	Что делаете	Что получается
Проверка новой задачи	Проверяете на стейджинге, что функция работает по требованиям	Задача переходит дальше или возвращается с багами
Заведение багов	Описываете найденное в трекере так, чтобы разработчик мог повторить	Карточка бага
Перепроверка	Повторяете шаги исправленного бага на новой сборке	Баг закрыт или переоткрыт
Смоук и регресс	Сразу после выкладки проходите главные сценарии, перед релизом — старые функции	Отмеченный список проверок и новые баги, если нашлись
Жалобы поддержки	Повторяете то, что описал покупатель	Баг или ответ Свете, что именно вы проверили и что увидели
Чтение требований	Читаете задачу до начала разработки и ищете, что в ней не сказано	Вопросы Олегу
Тест-документация	Пишете и обновляете чек-листы и тест-кейсы	Списки проверок, по которым пойдёте вы и коллеги

Чек-лист — список того, что нужно проверить, по пункту на строку; ему посвящён следующий урок. Тест-кейс — подробное описание одной проверки с шагами и ожидаемым результатом; его разберём в теме 2.

Жалоба, которую вы не смогли повторить, ещё не значит, что покупатель ошибся. Чаще у него было что-то, чего не было у вас: другой браузер, другой товар, промокод. Поэтому Свете отвечают не «не подтвердилось», а что именно вы проверили, и просят подробности: номер заказа, скриншот, время.

Есть ещё одна часть работы — автотесты, программы, которые проходят проверки сами. В вакансиях QA-инженеров их просят всё чаще, а на middle-собеседовании о них спрашивают почти всегда. Писать код вы начнёте с нуля в теме про Python и Git. Она открывается вместе с темой 4, когда вы уже будете понимать, какие проверки стоит автоматизировать. Заранее ничего знать не нужно.

Зачем проверять, если разработчик уже проверил

Кирилл закончил бесплатную доставку и проверил её на стейджинге: положил в корзину товаров на 3500 ₽, доставка стала бесплатной; положил на 1000 ₽, доставка стоит 300 ₽. Всё как в требовании. Задача ушла на проверку.

Тестировщик берёт ту же задачу и проверяет:

• заказ ровно на 3000 ₽ и на 2999 ₽;
• заказ на 3500 ₽ с купоном на 700 ₽, после которого к оплате 2800 ₽;
• что будет, если на странице оформления убрать товар и сумма опустится ниже 3000 ₽;
• что в письме о заказе и в истории заказов стоит та же сумма доставки, что и в корзине;
• как выглядит строка «Доставка: 0 ₽» на экране телефона.

Кирилл проверял честно. Но он проверял задачу так, как сам её понял. Если он решил, что «от 3000» значит «больше 3000», его проверка на 3500 и 1000 ₽ это подтвердит, а случай ровно в 3000 ₽ он не проверит: в его понимании такой случай ничем не особенный. Тестировщик читает требование сам, отдельно от разработчика, поэтому видит расхождение.

Вторая причина — соседние функции. Кирилл отвечает за доставку и смотрит на неё. Письмо о заказе, история в профиле, самовывоз написаны другими людьми и в другое время, и разработчик задачи редко вспоминает про них. Проверить, что изменение их не задело, — работа тестировщика, тот самый регресс из прошлого урока.

Это не значит, что разработчики не проверяют свой код. Многие пишут автотесты на свои функции, и это хорошо. Просто проверка человеком, который не писал код и читает требование сам, находит другие ошибки.

Чем раньше, тем дешевле

Посмотрите на требование ещё раз: «доставка бесплатная от 3000 ₽». Если покупатель применил купон на скидку, 3000 ₽ считаются до купона или после? Олег об этом не написал.

Этот вопрос можно задать в трёх местах, и цена у них разная:

• когда читаете требование — одно сообщение Олегу, он уточняет и дописывает в задачу; код ещё не написан;
• на стейджинге — баг, Кирилл переделывает, сборку выкладывают заново, вы проверяете ещё раз;
• на проде — покупатели платят за доставку, которая должна быть бесплатной, Света разбирает жалобы, команде приходится возвращать деньги и делать хотфикс.

Поэтому тестировщика подключают ещё до разработки. Карточка MC-440 с отзывами из вашего утра — как раз такой случай.

💡 Читая требование, спрашивайте себя: «Что будет, если...?» Если ответа в тексте нет, это вопрос аналитику.

Что тестировщик решает, а что нет

За час до релиза вы нашли баг: в письме о заказе стоит доставка 300 ₽, хотя в заказе она бесплатная. Что дальше?

Вы заводите баг, описываете, насколько он серьёзен (покупатель получает неверное письмо, но списывается правильная сумма), и сообщаете Ирине. Решение о релизе принимает она или команда вместе: выпустить сейчас и исправить в следующей сборке, подождать исправления или перенести релиз. Для этого решения ей нужна ваша информация: что сломано, кого задевает, есть ли обходной путь (способ всё-таки сделать нужное, например посмотреть верную сумму в личном кабинете), что проверено, а что нет.

Во многих компаниях без отметки тестировщика релиз не выходит: он подтверждает, что проверка пройдена, по-английски это называют sign-off. Но и тогда тестировщик подтверждает факты — что проверено и какие риски остались. Выпустить сборку с известным багом или нет, решает тимлид.

Тестировщик делает	Тестировщик не делает
Находит и описывает баги	Не исправляет код
Оценивает, насколько баг серьёзен	Не решает в одиночку, выпускать ли сборку
Говорит, что проверено и что нет	Не ищет, кто виноват в ошибке
Задаёт вопросы к требованиям	Не меняет требования сам

Новые баги команда регулярно разбирает вместе: решает, что исправлять сейчас, что позже, что вообще не ошибка. Такой разбор называют триажем (triage). Тестировщик приходит на него с фактами: как повторить, кого задевает, есть ли обходной путь.

📌 Если вы не успели проверить что-то до релиза, скажите об этом прямо. «Письмо о заказе не проверено» — полезная информация для решения; молчание превращает её в сюрприз на проде.

Кто читает то, что вы пишете

Баг из примера выше вы описали за десять минут. Дальше его прочитают разные люди, и каждому нужно своё.

Кто читает	Что ему нужно
Кирилл или Настя	Повторить баг и понять, где искать причину
Ирина	Понять, насколько серьёзно, и решить, когда исправлять
Олег	Увидеть, если баг показывает дыру в требованиях
Света	Понять, что ответить покупателю
Другой тестировщик	Найти ваш баг поиском и не заводить такой же ещё раз
Вы через полгода	Вспомнить, что было и чем закончилось, когда похожее сломается снова

Никто из них не стоял у вас за спиной, когда вы нашли баг. Всё, что им известно, — это текст в карточке. Если в ней написано «доставка считается неправильно», Кирилл будет гадать, какая сумма, какой заказ и где именно неправильно, а Света не поймёт, списали ли с покупателя лишнее. Как составлять баг-репорт по частям, разберём с урока 3.

🎯 «Чем QA отличается от тестирования?» Тестирование (testing) — проверка продукта: запустить, сравнить с требованием, найти расхождения. QA (quality assurance, обеспечение качества) шире: это работа над процессом, чтобы ошибок появлялось меньше, например вопросы к требованиям до разработки. В вакансиях эти слова обычно означают одну и ту же профессию.

Что дальше

Следующий урок — про чек-лист: как разобрать экран на части и составить список проверок, по которому можно пройти перед релизом. В нём будет первое задание куратору. У этого урока задания куратору нет, вопросы ниже — для самопроверки.

Словарик

• Тестировщик (QA) — специалист, который проверяет продукт и сообщает команде, где он работает не так, как договорились.
• Тест-кейс — подробное описание одной проверки с шагами и ожидаемым результатом.
• Обходной путь — способ всё-таки сделать нужное, когда основной путь сломан.
• Sign-off — отметка тестировщика, что проверка перед релизом пройдена.
• Триаж — совместный разбор новых багов: что исправлять сейчас, что позже, что не ошибка.
• QA (quality assurance) — работа над качеством продукта и процесса; в вакансиях так обычно называют тестировщика.