Автоматизировать или нет: спорные кейсы, плюсы и минусы автотестов

Думаю сейчас в тусовке тестировщиков есть некий консерватизм относительно автотестов. Дескать жили без них хорошо и дальше так будем. В большинстве случаев все эти примеры разбиваются об следующее утверждение.

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

• Проблема: долгая подготовка инфраструктуры. Решение: унификация платформы запуска приложений в рамках компании, например k8s+RabitMQ+MySQL+Golang+React

• Проблема: необходимость исправлять много тестов (а почему для ручного тестирования это не считается проблемой?). Решение: правильная декомпозиция задач и последовательность разработки. Например, применение DDD.

• Проблема: сложность мокирования разных частей ПО. Решение: унификация механизмов взаимодействия, разбиение ПО на маленькие части. Например внедрение микросервисов с grpc.

Что получите, если решите эти проблемы:

• Быстрый регресс.

• Регресс (как и все остально) можно отрабатывать за пределами бизнес часов.

• Предсказуемость времени прогона.

• Возможность запускать тесты заранее (на ранних этапах разработки).

• Меньше сотрудников: для прогона старых тестов тестировщик не нужен.

От масштаба проекта еще зависит. Но с тем, что при решении в пользу автотестов с первого билда у тебя к моменту разрастания проекта будет какая-никакая "страховочная сетка" спорить трудно. Ты или вкладываешься в систему раннего обнаружения или нет. Потому что есть разница сколько сборок пройдет от ошибки до обнаружения. Разве плохо, если только одна? Причем устранена причина будет уже к следующей сборке.

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

А уж верстку человеку просто физически трудно проверять. Куда там что на пиксель съехало? Где там на два бита цветовой канал изменился? Тут без автомата никуда. Представьте себе, если бы на фабрике весь контроль качества производился руками и глазами. Вот это дорого и ненадежно. У человека есть недостатки которых нет у машины и наоборот. Не зря у японцев в ТPS (Toyota Production System) есть понятие Jidoka - "автоматизация с человеческим лицом".

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