Home

Автор: Баз Дийкстра (Bas Dijkstra)
Оригинал статьи: https://www.ontestautomation.com/on-ending-the-regression-automation-fixation/
Перевод: Ольга Алифанова

Примечание: согласно моим наблюдениям, скриптованное выполнение тестов и тип регрессионных скриптов, о котором я говорю в статье, медленно отходят на второй план, однако многие организации все еще их используют. Не у всякой организации есть банда тестировщиков, работающих исследовательским методом с учетом контекста, и применяющих CI/CD, с релизами несколько раз в день. Если вы работаете в таком коллективе – отлично, эта статья, вероятно, не для вас. Но держите в уме, что многие компании все еще применяют традиционный подход к тестированию.

Последнее время я часто рассказывал о своих (неоднократных!) провалах на моем карьерном пути. К примеру, мой доклад на румынской тест-конференции начался с моего признания, что ретроспективно очень много проделанной мной до недавнего времени работы было в лучшем случае неэффективно – а в прочих случаях бессмысленно. Сейчас я медленно начинаю осознавать, что же такое автоматизация на самом деле, и как применять ее с большей пользой и эффективностью, не просто бросая в ее топку все больше и больше инструментов – эту точку зрения я поддерживал довольно долго.

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

Один из моих стандартных ответов на вопрос "С чего начинать, начиная автоматизировать" – это "В первую очередь автоматизируйте существующие регрессионные тесты". Звучит разумно, не так ли? Регрессионные тесты часто выполняются в конце цикла поставки, чтобы проверить, что существующая функциональность не была повреждена в результате добавления новых функций в продукт. Эти тесты зачастую довольно нудные – когда тестируешь что-то новое, это всегда увлекательно, а функциональность столетней давности – это скучно. Плюс регресс зачастую занимает много времени на прогон, а время – это то, чего под конец цикла разработки никогда не хватает. Итак, автоматизация регресса – хорошая мысль, правда?

Ну, возможно. Но, возможно, недостаточно хорошая.

Честно говоря, я не думаю, что начинать с автоматизации регресса – нынче плохая идея, или что она когда-то была такой (задним умом мы все крепки). Это может быть хорошим решением в некоторых ситуациях, но я могу навскидку назвать ряд случаев, когда это не так. Почему? На это есть две причины.

Регрессионные скрипты слишком длинны

Типичные регрессионные тест-скрипты, с которыми я сталкивался, неимоверно длинны и содержат десятки шагов с различными чекпойнтами. Это здорово, если тестирует живой человек, но когда они дословно переносятся в автоматизированный скрипт, то легко разваливаются.

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

Автоматизация же просто скажет "А не пошли бы вы все" и завершается с падением или ошибкой, не давая вам никакой обратной связи о поведении приложения на шагах 11-50.

Чтобы автоматизация была эффективнее, и риск раннего отказа снижался, нужно переписать и укоротить регресс-скрипты –в большинстве случаев превращая их в небольшие, независимо запускающиеся секции. Это занимает время и съедает предполагаемую скорость, ожидаемую от внедрения автоматизации. Более того, это раздражает людей, незнакомых с тестированием и автоматизацией, потому что вместо ста сценариев вам нужно автоматизировать триста или четыреста, а это выглядит, как гораздо более объемная задача!

Регресс-скрипты пишутся с точки зрения конечного пользователя

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

Чтобы превратить существующие сценарии в эффективные и быстрые автотесты, вам вновь придется внимательно посмотреть, в чем именно убеждаются эти сценарии, выяснить, где внедрено соответствующее поведение или логика, найти способ взаимодействия с приложением на этом уровне (возможно, через пользовательский интерфейс, но более вероятно – через API, класс или метод, или даже одну-две базы данных), и начинать с этого.

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

Итак, что же делать вместо этого?

Мой совет: забудьте про ваши регресс-тесты.

Вот. Я наконец-то это сказал.

Вместо этого задайте себе три вопроса, оценивая ваши усилия по тестированию:

1. На что я трачу время?
2. Что в моих действиях повторяется?
3. Какую часть моих усилий можно заменить или улучшить автотестом?

Ответ(ы) на эти вопросы могут (отдаленно) походить на то, что вы делаете во время регресса, но могут также вскрыть другие, более ценные пути применения автоматизации в вашем тестировании. Если это так, имеет ли смысл нацеливаться на "автоматизацию регресса"? Я думаю, что нет.

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

Обсудить в форуме