Стартапам дают два совета про тестирование. Первый: вам пока не до этого, найдите product-market fit сначала. Второй: надо нанять QA, без него никак. Оба совета плохие — потому что оба игнорируют реальность стартапа.
Реальность такая. Баги в продакшне стоят дороже их предотвращения — всегда, на любом этапе. Особенно когда клиентов двадцать и каждый на счету. И нанять QA-команду до product-market fit — это преждевременная оптимизация которая сжигает runway.
Есть третий путь. Минимальная страховочная сетка которую может поддерживать основатель, разработчик или первый QA без специальных знаний.
Что нужно тестировать в первую очередь
Забудьте про сто процентов покрытия. Это не цель, это процесс. В стартапе цель другая: поймать катастрофы до того как они достигли пользователей.
Определите десять сценариев которые, если сломаются, означают что продукт не работает. Называйте это "критический путь" или "smoke suite" — не важно. Важно что это именно те сценарии от которых зависит что продукт вообще функционирует.
Для типичного SaaS это:
Пять-десять сценариев. Не двести. Не пятьдесят. Десять.
Почему именно сейчас, а не "потом"
Есть мнение что маленькой команде не нужны автотесты — мол, "мы и так всё проверяем руками". Это заблуждение которое дорого стоит.
Руками вы проверяете то что помните проверить. Автоматика проверяет то что вы настроили — каждый раз, одинаково, не устаёт и не забывает.
Второй момент: стоимость написания теста растёт с кодовой базой. Тест для простой регистрации из пяти полей — это час работы. Тест для той же регистрации через год, после трёх рефакторингов и двух OAuth-интеграций — это два дня. Лучше час сейчас.
Третий: ранний тест документирует поведение. Когда через год вы забудете почему конкретный флоу работает именно так — тест напомнит. Не словами а исполняемым кодом.
Как запустить с нуля за один день
Шаг первый: выберите инструмент который не требует инфраструктуры. TestManager, Cypress Cloud, или подобные — главное что не нужно настраивать сервер, разбираться с Docker и писать CI-конфигурацию в первый день.
Шаг второй: запишите пять сценариев. Не пишите, не программируйте — запишите в том смысле что пройдите сценарий в браузере пока инструмент смотрит. Большинство современных инструментов умеют записывать действия.
Шаг третий: убедитесь что запись воспроизводится. Запустите пять тестов, убедитесь что прошли.
Шаг четвёртый: настройте запуск перед деплоем. Большинство инструментов интегрируются с GitHub Actions, GitLab CI, Bitbucket за пятнадцать минут через готовые шаблоны.
Всё. У вас есть автоматизированное тестирование. Несовершенное, маленькое — и работающее.
Растём: как масштабировать когда продукт вырос
Со временем появляются новые фичи. Естественное правило: каждая новая значимая фича — новый тест. Не сто тестов. Один основной сценарий. Добавляйте постепенно.
Когда набор достигнет пятидесяти тестов — самое время нанять первого QA. К этому моменту у него будет с чем работать: существующий набор, настроенный инструмент, документированные сценарии. Он не начинает с нуля.
Команды которые откладывают автоматизацию платят за неё дважды. Первый раз когда наконец начинают — приходится разбираться в накопленном коде и добавлять тесты ретроспективно. Второй раз — за баги которые поймали бы раньше.
Один человек против технического долга
Самый частый аргумент против: "у нас нет времени". Понимаем. Но посчитайте по-другому.
Один серьёзный инцидент в продакшне — это минимум четыре часа: час на диагностику, час на фикс, час на деплой и мониторинг, час на объяснения клиентам. Это в лучшем случае.
Написать тест для сценария который поймал бы этот инцидент — час. Один раз.
Даже если инцидент случается раз в квартал — тест окупается за первое срабатывание.
FAQ
Нужна ли автоматизация тестирования в стартапе на ранних этапах?
Да. Но не в полном объёме. Стартапу достаточно покрыть пять-десять критических сценариев (регистрация, основное действие, оплата) и запускать их перед каждым деплоем. Это занимает день на настройку и несколько минут на запуск. Альтернатива — баги в продакшне которые обнаруживают клиенты.
С чего начать автоматизацию тестирования если нет QA команды?
Начните с инструмента который не требует написания кода. Определите десять сценариев которые нельзя сломать. Запишите их через интерфейс инструмента. Настройте автозапуск перед деплоем. Это минимально жизнеспособная автоматизация — несовершенная, но работающая с первого дня.
Сколько тестов нужно для стартапа?
Начните с десяти критических сценариев. Добавляйте один тест на каждую значимую новую фичу. К моменту найма первого QA у вас будет 30–50 тестов как основа для масштабирования.
Когда нанимать QA в стартап?
Когда: ручное тестирование занимает больше дня перед каждым релизом, продукт достаточно сложный что разработчики не могут держать всё в голове, команда разработки больше трёх человек. До этого — инструмент с минимальной автоматизацией критического пути.
Что делать если тесты написаны но никто их не поддерживает?
Это признак что тестов слишком много или они слишком хрупкие. Оставьте только критические десять. Остальные удалите или поставьте в skip. Лучше десять надёжных тестов чем сто которые падают по непонятным причинам и которые все игнорируют.