Нам с вами, как тестировщикам, хочется верить в то, что без нас продукт не сможет полноценно функционировать. В нем будет много багов и пользователи просто откажутся от него.

Но может ли в реальности проект обойтись без тестировщика? Очень даже может.

Перечислю несколько ситуаций, в которых тестировщик может быть не нужен и не выгоден.

Небольшой стартап

Программист (или группа программистов) решили написать какую-то программу. Совсем небольшую. Они не знают, понравится она пользователям или нет. У них нет возможности вкладывать большие суммы в развитие своего проекта и пока нет в планах привлекать инвесторов.
Им просто интересно, зайдет их продукт или нет.

В этом случае нет никакого смысла нанимать тестировщика. Это будет финансово невыгодно. Да и на таком этапе можно проверить продукт собственными силами.

Ошибиться дешевле

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

Или, например, разрабатывается продукт, у которого нет ни ТЗ, ни даже четкого понимания, как в итоге он будет функционировать. Этот продукт будет использоваться однократно, разработка проходит в сжатые сроки.

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

Еще одна разновидность — разработка несложного или одноразового внутреннего продукта. Функциональность достаточно простая, им будут пользоваться только внутренние сотрудники. Ошибки в данном приложении не будут критично влиять на какие-либо процессы внутри фирмы.
Тестирование в этом случае не имеет смысла: основные фичи проверит разработка, про остальные баги расскажут сотрудники.

Продукт остается неизменным

Что такое тестирование? Это когда мы сомневаемся в работе нашего продукта. Почему же мы сомневаемся в ней постоянно? Потому что продукт постоянно меняется. А значит, что пишется новый код, который нуждается в проверке.

Если наш продукт статичен и не подлежит изменению, то и тестирование не нужно. Есть продукты, которые незначительно меняются 1 раз в несколько месяцев. Это, например, проекты на стадии поддержки. И зачем ради этого выстраивать процесс тестирования?

Тестирование превращается в поиск ошибок

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

Если тестирование превращается в поиск ошибок, то мы начинаем гнаться за их количеством, а не приоритетом и критичностью. Залезаем в самые нестабильные области, которые обычно менее приоритетны. Проверяем самые невероятные гипотезы.

В итоге это приводит к тому, что действительно важные и значимые области продукта остаются без проверки. А для чего нам «тестирование», которое оставляет в продукте критические баги?

Недостаточное финансирование

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

Недостаток финансирования может привести к тому, что множество баг-репортов, тест-кейсов и чек-листов будут храниться не в системах, которые подходят для данной компании, а в тех, на которые выделили деньги.

Все это скажется на качестве тестирования, которое оставит желать лучшего.

И здесь остается два пути: либо мы отказываемся от тестирования, как направления, либо находим средства.

Промежуточный вариант разработки

Компания может создавать прототипы для определенных целей (например, для показа проджект-менеджеру). Обычно это происходит на промежуточном этапе разработки продукта.

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

Важные выводы

От чего же зависит необходимость в тестировщике?Дмитрий Безносов дал исчерпывающий ответ на это вопрос:

Зависит от сложности продукта, требований к его качеству и ещё многих других факторов (в том числе — финансирования).

Без тестировщика можно, а вот без тестирования? На этот вопрос ответом будут рассуждения Ольги Журавлёвой:

Выбрала вариант «необходим как воздух», но не всегда как отдельный специальный человек, а как роль, как набор обязанностей. И уже не важно — покрывает ли девелопер юнит тестами или аналитик все сам тестирует. Главное что тестирование — важная и неотъемлемая часть разработки.

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