Мне кажется, что каждый хоть раз да слышал этот вопрос. И не особо важно кем ты работаешь, разработчиком, менеджером или тестировщиком. В команде разработки у тестировщики самые непонятные ребята.
Если так посмотреть то в результате работы программистов получается код, дизайнеры рисуют макеты, менеджеры заполняют эксельки, а в результате результатом работы тестироващика является приложение, которое может быть и так работало.
Поэтому бытует мнение, что если нанять лучших программистов то можно обойтись без тестировщиков.
Как известно чем круче программисты: тем сложнее дебажить их баги. Поэтому да, в теории можно, и многие стартапы живут без них. Но это до тех пор пока компания не потеряет кругленькую сумму из-за того, что не досмотрели или не учли какой-то фактор. В общем, у тех, кто терял деньги вопросов в нужности тестировщиков не возникает.
Тестировщики по другому видят проект. В отличие от програмистов, они не делят приложение на модули классы и прочие абстракции, а смотрят на него целиком, так же как смотрит на него пользователь. В идеальном случае тестировщик — это такой придирчевый пользователь, который на каждую неисправность заводит тикет.
Но есть одна штука, которая страдает если все технические задачи проходят через бдительную проверку тестировщиком. Это такая штука, без которой мидл никогда не станет синьером, а джуниор мидлом. Ну а очень матерый зарзработчик без нее может потерять всякое желание работать над этой задачей. Я говорю про ответственность.
Смотри, когда разработчик выполнил фичу, он должен нести ответственность за ее работоспособность, а так же за работоспособность всего приложения в целом, после релиза.
Но если фича ушла на тестирование, то ответственность разделилась между разработчиком и тестировщиком, а в некоторых особо запущенных случаях и вовсе целиком легла на тестировщика.
Можно ли с этим бороться?
Думаю, да. Не надо делать из тестирования карго-культ, это полезный инструмент, но у него тоже есть своя цена.
Чтобы не происходило разделения отвественности, нужно сделать тестирование рекомендательным. Например, сделали фичу, отдали на тестирование. В процессе тестировщик подсвечивает проблемы и дает рекомендации к исправлению. Править или нет, это дело разработчика.
Так же нужно сохранить у разработчика возможность катить непроверенный релиз, разумеется под свою ответственность. Порядочный разработчик сильно переживает после неудачных релизов.
Ну и конечно, нужно ввести практику тестирования кода.
А как у вас в команде организовано тестирование?
Подписывайся на мой телеграм канал, там еще больше материалов про работу в крупных IT компаниях