О пирамидах в тестировании и реальных сложностях автоматизатора

Давайте поговорим про пирамиду в тестировании и миражи, которые она создаёт.

Речь идёт про эту дефолтную картинку из интернета, которая взята с непонятно какого сайта:

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

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

А в чём проблема?

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

Я предлагаю рассмотреть следующие возможные ситуации, когда на проекте начинает организовываться автоматизация в тестировании и понять, чего ждать от автоматизации в каждом конкретном случае руководителям и начинающим автоматизаторам.

Рассмотрим основные ситуации, в которых оказывается начинающий тестировщик, приходя на проект, в котором хотят реализовать автоматизацию тестирования:

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

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

Можно рассмотреть ещё пограничные варианты, когда вообще ничего нет или есть только ручное тестирование, но не будем вдаваться в крайности. Давайте рассмотрим только эти два случая.

Поговорим о реальных сложностях автоматизатора

— 1. Итак, в первом случае основная трудность автоматизатора в тестировании заключается, во-первых, в том, что он занят в большом объёме UI-тестами, которым нет конца и края. При этом он не может оценить, насколько что покрыто, потому что в таких случаях, как правило, проект уже большой, а знаний у автоматизатора не хватает на то, чтобы оценить, что модульные тесты покрывают, а что нет, и от каких UI-тестов можно отказаться, заменив их интеграционными и системными, которые будут проверять бекэнд.

Со стороны руководства здесь, как правило, следует полное безразличие к эффективности, т. к. есть ручные тестировщики и UI-тесты, продукт выпускается, а значит, всё в порядке, но ведёт это к долгим прогонам тестов и т. п. Что делать в таком случае автоматизатору, который хочет повысить эффективность процесса тестирования?

Однозначно, повышать свою квалификацию в части того, как работает бекэнд, повышать навыки в программировании и начинать к существующим UI-тестам докручивать модули, которые будут проверять и бекэнд, постепенно отказываясь от какой-то группы UI-тестов в пользу системных, тем самым сокращая время тестового прогона и увеличивая эффективность тестирования за счёт того, что происходят более глубокие проверки.

— 2. Во втором случае автоматизатор сталкивается с другими трудностями. Прежде всего, это отсутствие какой-либо документации на продукт, в т. ч. отсутствие требований к нему. При этом времени и желания сидеть и расписывать их, как правило, ни у кого нету, а протестировать всё надо было ещё вчера. Что делать в таком случае?

Опять же изучать архитектуру проекта, то, как он развёртывается. И начинать с простых тестовых сценариев, возможно даже с тех, которые будут в начале тестировать только бекэнд, постепенно переходя к UI.

Что общего у обоих сценариев?

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

На этом пока всё, оставляйте комментарии!