Автор: Майкл Болтон (Michael Bolton) Оригинал статьи Перевод: Ольга Алифанова
Повсеместно распространено убеждение, что "предотвращение проблем на ранней стадии процесса разработки ПО приведет к продуктам более высокого качества, нежели тестирование на более поздних стадиях". Это не так.
Это неправда, но не по той причине, которая может прийти в голову большинству. Проблема не в том, что ранний поиск проблем – плохая идея. Обычно это действительно отличная идея.
Проблема в том, что утверждение бессвязно. Тестирование само по себе, неважно, рано или поздно выполненное, вообще не приводит к продуктам более высокого качества.
Предотвращение проблем, улучшение продукта и тестирование – это разные процессы внутри цикла разработки. Эти виды деятельности связаны друг с другом, но тестирование не может ни предотвращать проблемы, ни улучшать продукт. Помимо тестирования, должно произойти что-то еще.
Исходящее от меня, учителя и адвоката грамотного тестирования, это утверждение может показаться безумным, но это истина: тестирование не улучшает продукт.
В конце ноября состоялся первый релиз нашей платформы для подготовки к собеседованиям IT Resume. И знаете с чего он начался? Правильно — нас сразу купил Гугл на нас сошла лавина баг-репортов. Если точно — почти несколько сотен за неполных 2 дня! Но это было лучшее, что с нами произошло за долгое время! :)
Однако обо всем по порядку.
Пролог
Для начала накидаем немного контекста, чтобы вы могли лучше прочувствовать наше положение и понять наши мотивации.
Мы начали пилить платформу для подготовки к собеседованиям в апреле. В ноябре состоялся релиз. За это время были разработаны дизайны, написан фронт, развернуто полноценное API и создан обработчик кода со всеми наворотами типа лексических анализаторов.
Уточнение: Фронт был сначала написан, а потом еще раз переписан на другом фреймворке.Классика.
Все это делалось силами нескольких программистов. Команда была небольшая: бекендер на фултайм + фронтендер и дизайнер на парт-тайм.
200+ задач и тестов разрабатывались силой все той же команды. Для каждой задачи нужно было прописать формулировку, подсказки, решения и оформить юнит-тесты.
Лирическое отступление: сначала казалось, что работы по созданию задач будет немного. Оказалось много.
Мы решили не тратиться на рекламу. Собирались привлекать пользователей на платформу из своих социальных сетей (кстати, будем рады вас видеть: ВКонтактеТелеграмИнстаграм).
