В конце ноября состоялся первый релиз нашей платформы для подготовки к собеседованиям IT Resume. И знаете с чего он начался? Правильно — нас сразу купил Гугл на нас сошла лавина баг-репортов. Если точно — почти несколько сотен за неполных 2 дня! Но это было лучшее, что с нами произошло за долгое время! :)
Однако обо всем по порядку.
Пролог
Для начала накидаем немного контекста, чтобы вы могли лучше прочувствовать наше положение и понять наши мотивации.
Мы начали пилить платформу для подготовки к собеседованиям в апреле. В ноябре состоялся релиз. За это время были разработаны дизайны, написан фронт, развернуто полноценное API и создан обработчик кода со всеми наворотами типа лексических анализаторов.
Уточнение: Фронт был сначала написан, а потом еще раз переписан на другом фреймворке.Классика.
Все это делалось силами нескольких программистов. Команда была небольшая: бекендер на фултайм + фронтендер и дизайнер на парт-тайм.
200+ задач и тестов разрабатывались силой все той же команды. Для каждой задачи нужно было прописать формулировку, подсказки, решения и оформить юнит-тесты.
Лирическое отступление: сначала казалось, что работы по созданию задач будет немного. Оказалось много.
Мы решили не тратиться на рекламу. Собирались привлекать пользователей на платформу из своих социальных сетей (кстати, будем рады вас видеть: ВКонтактеТелеграмИнстаграм).
Как прямая автоматизация тест кейсов приводит к громоздким и раздутым наборам автотестов, которые практически не приносят пользы.
Общепринятой практикой в индустрии является использование тест кейсов в качестве основы для автоматизации тестирования. QA инженеры разрабатывают их на основе user stories в рамках обычного тестирования, а затем автоматизируют эти тесты. С каждой итерацией тестируется больше историй, автоматизируется больше тестовых случаев, и набор автоматических тестов становится всё больше. Руководители продвигают такие метрики, как, например, «процент покрытия» и хвалят команды с высокими показателями. Некоторые компании даже специально нанимают «инженеров по автоматизации», чья единственная работа состоит в том, чтобы брать тест кейсы и автоматизировать их.
К сожалению, автоматизация тест кейсов и навязывание «процента покрытия» — это антипаттерн обеспечения качества, который неизбежно приводит к раздутым и сложным в обслуживании наборам тестов, которые приносят мало пользы. Хотя автоматизация имеет решающее значение для agile delivery, этот чрезмерно упрощенный подход «фабрики автоматизации» не является хорошим способом автоматизации тестирования.
В этой статье мы продемонстрируем, почему «фабрики автоматизации» неэффективны и опишем более правильный подход к автоматизации, который гарантирует, что автоматизация тестирования поддерживает и ускоряет скорость разработки.
