Ручное тестирование в небольшой команде: как организовать QA

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

Разберём, как выстроить такой процесс, что проверять перед каждым релизом и как описывать ошибки, чтобы их быстро исправляли.

Нужен ли небольшой команде отдельный тестировщик?

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

Как распределить проверку без тестировщика:

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

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

Что проверять перед каждым релизом?

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

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

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

Фото: Unsplash

Чек-листы или тест-кейсы?

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

Пример чек-листа регрессии

Регрессия перед релизом — интернет-магазин
[ ] Регистрация, вход, восстановление пароля
[ ] Поиск и фильтры каталога, карточка товара
[ ] Корзина: добавить, изменить количество, удалить
[ ] Оформление заказа с доставкой и самовывозом
[ ] Оплата картой: успех и отказ банка
[ ] Личный кабинет: история заказов, повтор заказа
[ ] Админка: новый заказ виден менеджеру, смена статуса
[ ] Письма: подтверждение заказа и смены статуса
[ ] Мобильная версия: оформление заказа на телефоне

Чек-лист живёт рядом с кодом или в базе знаний и обновляется, когда появляется новая ключевая функция.

Как описывать ошибки, чтобы их быстро исправляли?

Ошибку описывают так, чтобы разработчик мог воспроизвести её с первого раза: шаги, ожидаемый и фактический результат, окружение и данные, скриншот или запись экрана. Половина времени на исправление обычно уходит не на код, а на то, чтобы понять и повторить проблему.

Шаблон отчёта об ошибке:

1. Заголовок — что сломалось и где: «Не применяется промокод к товарам со скидкой».
2. Шаги — пронумерованные действия от начала.
3. Ожидаемый результат — как должно работать.
4. Фактический результат — что происходит, с текстом ошибки.
5. Окружение — стенд, браузер или устройство, учётная запись.
6. Приоритет — насколько ошибка мешает пользователям и бизнесу.
7. Вложения — скриншот, видео, ссылка на запись в логах.

Как организовать тестовое окружение и данные?

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

Что подготовить:

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

Регулярная ручная проверка вместе с автотестами и ревью делает сроки предсказуемее — меньше ошибок возвращается после релиза, об этом в статье почему срываются сроки разработки.

Коротко

• В небольшой команде проверку делят разработчики и владелец продукта; тестировщик нужен при сложном продукте и частых релизах.
• Перед каждым релизом проходите короткий чек-лист регрессии и постепенно автоматизируйте его.
• Для небольшой команды чек-листы практичнее тест-кейсов; подробные сценарии — для критичных функций.
• Отчёт об ошибке: шаги, ожидаемое и фактическое поведение, окружение, вложения.
• Тестовый стенд — с тестовыми данными и учётными записями для всех ролей, без реальных персональных данных.