Как делают приложения и где в этом тестирование

Кто есть в команде

Приложение почти никогда не делает один человек. В типичной команде:

Роль	Чем занимается	Что получает от неё тестировщик
Менеджер продукта	Решает, что и зачем делать, расставляет приоритеты	Понимание, что важнее для пользователей и бизнеса
Аналитик	Описывает, как именно должна работать функция	Требования — главный источник «как должно быть»
Дизайнер	Рисует экраны и продумывает, как ими пользоваться	Макеты, с которыми сверяют вёрстку
Разработчики	Пишут код: фронтенд (то, что видно), бэкенд (сервер), мобильные приложения	Готовые задачи на проверку
Тестировщик	Проверяет, что всё работает как задумано	—

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

Путь задачи

Любая новая функция — например, «оплата по QR-коду» — проходит примерно один путь:

1. Идея. Менеджер продукта решает, что функция нужна.
2. Требования. Аналитик описывает, как она работает: что видит пользователь, какие проверки, что делать при ошибке.
3. Дизайн. Дизайнер рисует экраны.
4. Разработка. Разработчики пишут код.
5. Тестирование. Тестировщик проверяет, что всё сделано по требованиям и ничего не сломалось.
6. Выпуск (релиз). Новая версия попадает к пользователям.
7. Поддержка. Команда следит за ошибками, которые нашли уже пользователи, и исправляет их.

Каскад и гибкая разработка

Раньше многие проекты делали каскадом (waterfall): сначала месяцами пишут все требования, потом всё разрабатывают, потом всё тестируют. Минус — об ошибках в замысле узнают слишком поздно.

Сейчас чаще работают гибко (Agile), и самый популярный вариант — Scrum. Работу делят на короткие спринты по 1–4 недели, чаще всего по две. В начале спринта команда выбирает задачи, каждый день коротко сверяется на встрече (её называют стендапом), а в конце показывает готовый результат.

Для тестировщика это значит: проверять приходится постоянно, небольшими порциями, прямо внутри спринта, а не одним большим этапом в конце.

Тестирование начинается с требований

Ошибки рождаются не только в коде. Возьмём строчку из требований: «Пароль должен быть надёжным». Звучит понятно, но разработчик и тестировщик могут понять её по-разному. Сколько символов? Нужны ли цифры? Можно ли пробелы? Что увидит человек, если пароль ненадёжный?

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

• неясности — «надёжный», «быстро», «удобно» без конкретики;
• противоречия — в одном месте «до 10 товаров», в другом «до 20»;
• пропуски — что будет при ошибке, пустом поле, потере связи.

Где проверяют: окружения

Одно и то же приложение обычно живёт в нескольких местах — окружениях:

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

Эксперименты, которые могут что-то сломать, проводят только на тестовом окружении. Оплатить «тестовый» заказ настоящей картой на продакшене — плохая идея.

Статусы задачи

Задачи живут в трекере (о трекерах — в уроке 7) и переходят из статуса в статус. Названия везде свои, но смысл похож:

1. Нужно сделать
2. В работе
3. Готово к тестированию
4. Тестируется
5. Готово

Тестировщик берёт задачи из «Готово к тестированию» и либо отправляет их дальше, либо возвращает разработчику с найденными ошибками, описанными в баг-репортах.