В стартапе нет команды QA из 20 человек. У вас есть 2 инженера и дедлайн. Невозможно тестировать всё.
Вопрос не в том, «нужно ли тестировать?» — вопрос в том, «что тестировать в первую очередь?»
Пирамида тестирования на основе рисков
Забудьте о традиционной пирамиде тестирования (модульное > интеграционное > E2E). Для стартапов я использую подход, основанный на рисках:
Приоритет 1: Тестируйте то, что приносит убытки. Платежные потоки, управление подписками, расчеты биллинга. Ошибка здесь стоит реальных денег и реальных клиентов.
Приоритет 2: Тестируйте то, что приводит к потере данных. Миграции баз данных, экспорт данных, резервное копирование/восстановление. Ошибка здесь катастрофична и часто необратима.
Приоритет 3: Тестируйте то, что подрывает доверие. Аутентификация, авторизация, сброс пароля, доставка писем. Ошибка здесь заставляет пользователей сомневаться в вашей безопасности.
Приоритет 4: Тестируйте всё остальное. Взаимодействие с интерфейсом, граничные случаи, производительность, доступность. Важно, но не критично для выживания.
Минимально жизнеспособный набор тестов
Для типичного SaaS-стартапа вот что я бы настроил в первую неделю:
