Похоже, что стремление “сдвинуть” тестирование влево, к началу конвейера, в сторону разработчиков для ускорения разработки приложений и их развертывания зашло в определённый тупик. Недавний опрос, проведённый компанией Perforce (специализируется на разработке средств автоматизации тестирования) среди 102 ИТ-специалистов, принимающих непосредственное участие в тестировании приложений в своих организациях, показывает, что только 18% компаний тестируют приложения внутри групп разработчиков. Остальные продолжают полагаться на отдельные команды в той или иной форме. При этом более половины респондентов (56%) автоматизируют менее четверти своих тестовых сценариев.
Результаты опроса показывают, что, когда речь заходит об автоматизации тестирования в средах DevOps, то и в них всё ещё продолжает существовать большая зависимость от ручного тестирования. Уровень автоматизации тестирования в среднем составляет менее 50%. Почти 40% команд автоматизируют менее четверти своих тест-кейсов, лишь малая часть – 9% – автоматизируют три четверти своих сценариев тестирования, говорится в исследовании.
Если оценивать частоту выпуска, то в среднем только 14% респондентов ответили, что выпускают код ежедневно. 39% отметили, что выпускают код еженедельно, а 46% – ежемесячно. Получается, что большинство организаций всё ещё используют подход “Большого Взрыва” к тестированию, который приводит к тому, что большинство проверок проводится после того, как большие объёмы кода уже были объединены, а не тестируются разработчиками одновременно с разработкой кода. В этой части 66% участников опроса сказали, что они тестируют код лишь после того, как проект разработки готов, 54% – что тестируют по готовности каждой сборки. Это сопоставимо с теми 43% респондентов, которые запускают тесты при каждом изменении кода, и 41% использующих тесты на старте очередного спринта разработки.
Основная причина, по которой многие организации не выпускают код быстрее, хотя могли бы – использование ручного тестирования. Опрос показал, что ручное тестирование является наиболее трудоёмкой частью процесса тестирования (72%), за ней следуют настройка тестовой среды (28%), создание / настройка сценариев (27%) и анализ цикла тестирования (19%).
Можно составить небольшой список проблем, с которыми сталкивается организация, проранжировав их по важности. На первом месте в нём по результатам опроса – достижение полной автоматизации тестирования (47%), за ним следуют нестабильность тестирования / ложные срабатывания (44%) и нехватка или отсутствие навыков составления сценариев тестирования / разработки сценариев тестирования (41%).
Что касается общих приоритетов, то респонденты поставили во главу угла сокращение времени регрессионного тестирования (46%), сокращение числа необнаруженных (“ускользающих”) дефектов (43%) и автоматизированное тестирование (43%).
Да, вполне возможно, что не удастся автоматизировать весь процесс тестирования, но уже ясно, что многие организации могут автоматизировать подпроцессы тестирования более низкого уровня для ускорения разработки и развёртывания приложений. Если рассматривать ситуацию на перспективу, то опрос показывает, что 46% респондентов планируют инвестировать в автоматизацию тестирования в текущем году.
Независимо от выбранного подхода к тестированию, очевидно, что команды, занятые тестированием, нуждаются в большей проявленности и видимости в конвейере DevOps. Организации явно недооценивают, сколько времени требуется для тщательного тестирования приложений, поэтому чем раньше команды тестирования смогут увидеть, что именно разрабатывается, тем быстрее они смогут создать наборы соответствующих сценариев тестирования.
Странная немного ситуация. При наличии инструментов на рынке проблема действительно существует. Корни видимо в области психологии, поскольку повторюсь – на рынке уже давно присутствуют инструменты, позволяющие успешно решать данные задачи.