В последнее время автоматизацию тестирования называют «серебряной пулей» от всех проблем проекта. Многие приступают к автоматизации очень спонтанно и лайтово, не просчитав все «за» и «против», плюсы и минусы, сопровождение и окупаемость.
А вообще автоматизация тестирования – очень дорогой и специфический инструмент. Поэтому к ней нужно подходить с должным уровнем зрелости кода и самого проекта. Иначе можно потратить миллионы часов и денег, а эффект получить микроскопический или не получить его вообще.
В этой статье я постарался:
- осветить «детские болячки» тест-менеджмента, стремящегося автоматизировать все, что не приколочено,
- пояснить, какую пользу может нанести бюджету проекта автоматизация тестирования без детального анализа ее скоупа и должной подготовки,
- составить Roadmap для подготовки к автоматизации проекта.
Источник
Тенденция такова, что сейчас автоматизацией тестирования затыкают дыры во всех проектах, фактически заколачивая микроскопом гвозди. Доходит до того, что тестировщику без навыков автоматизации становится сложно найти работу, т.к. в большинстве вакансий пропущены навыки в тест-анализе и тест-дизайне, но обязательно требуется опыт в автоматизации чего-либо.
Хочется верить, что со временем все мы переболеем навязчивым желанием автоматизировать все и сразу, а пока нам бы очень помог некий чек-лист для определения, нужны ли вообще автотесты в проекте и готов ли проект для них.
Собственно с этими мыслями я пошел выступать с докладом на «Стачку-2019» и потом на его основе написал этот пост.
Говорить мы будем о больших, серьезных end-to-end автотестах, которые автоматизируют регресс в части UI и веб-сервисов. А также о том, что с ними связано. Тему Unit-тестов, которые пишут или должны писать разработчики, мы затрагивать не будем. Это отдельный пласт автотестирования, и о нем написано уже много статей:
Проект я называть не буду, только скажу, что это – информационная система, рассчитанная на несколько десятков миллионов пользователей. Она интегрирована с несколькими государственными порталами, а также с десятками, а то и сотнями, региональных и коммерческих порталов. Отсюда повышенные требования к надежности, отказоустойчивости и безопасности. Ну и вообще, чтобы это все «крутилось и не падало».
Наше кредо на всех проектах ЛАНИТ по тестированию — непрерывные улучшения. В общем, все, что позволяет нам тестировать быстрее, лучше, выше, сильнее, экономит силы и время тестировщиков, а, как следствие, и бюджет. Мы реализовали на этом проекте, наверное все best practices, которые нам позволяли сроки и задачи. В итоге из крупных нереализованных фишек осталась только автоматизация регресса. Сама эта тема довольно долго витала в воздухе, и мы долго от нее отказывались, упираясь всеми конечностями, потому что профит был не очень понятен. Но в конце концов решились автоматизировать. А дальше был затяжной прыжок в холодную воду.
Небольшое отступление. Способы автоматизации
Основных способов автоматизации UI тестирования два.
Автоматизация силами ручных тестировщиков
За примерами далеко ходить не надо – все есть на Хабре. Не буду называть компании. Те, кто интересовался темой, наверное, видели эти полуторачасовые вебинары, как у них все классно, здорово, как у них вся команда ручных тестировщиков научилась Java, пошла автоматизировать, все покрыто, все здорово, все работает, светлое будущее уже наступило. Есть такой подход.
Проектный подход
И есть второй подход: набирается команда автотестировщиков – с опытом, со знаниями и навыками в ООП, и автоматизация выполняется непосредственно силами этой команды, а команда ручных тестировщиков выступает в роли заказчиков и экспертов. Да, они могут перетекать в команду автоматизаторов после обучения, отбора, но никогда не совмещают две роли одновременно.
Ниже я описал особенности этих подходов, но специально не маркирую их как «плюсы» или «минусы» — каждый определит знак для себя сам.
Особенности автоматизации «своими силами»
1) Когда мы автоматизируем силами ручных тестировщиков, мы получаем быстрый эффект «смотрите, этот тест раньше проходил день, теперь я могу заменить его роботом, он проходит 2 дня, но моего участия здесь нет». Естественно, это повышает квалификацию и расширяет кругозор специалистов: они начинают разбираться в коде. Но нет какого-то четкого, осязаемого результата для бизнеса. Сколько часов потрачено на разработку, а сколько можно было потратить, если бы это делал человек с опытом? Сколько часов сэкономлено? Как часто будет запускаться тест-кейс? Где? Кем сопровождаться? Сколько это стоит? Для меня это не очень хорошо, потому что я, к сожалению пока не видел заказчиков, которые готовы платить деньги бесконечно – за процесс. Поэтому для меня всегда важен четкий, осязаемый результат.
2) Нет сроков. С одной стороны, хорошо: никто команду не подстегивает, «давай быстро все автоматизируй, давай быстро изучай», у человека не растет напряженность. Он продолжает тестировать руками и спокойно погружается в автоматизацию. С другой стороны, нет сроков, спросить о результатах не можем, понять, когда будет готово — тоже.
3) Нет поддерживаемости и преемственности кода. С одной стороны, разные подходы, изыскания рождают лучшие способы написания, иногда, переписывая с нуля, можно ускорить автотест в несколько раз. Но это мегазатратно. К тому же кто все это будет сопровождать, если специалисты покинут проект, а такое бывает, если они уйдут в другую бизнес-область или в другую команду? Тоже не очень понятно.
Особенности проектного подхода
1) В этом случае мы говорим уже о проекте. А проект – это что? Это ресурсы, время, деньги. Соответственно, здесь идет расчет бюджета, учитывающий все нюансы, которые есть в этом проекте. Обсчитываются все риски, обсчитываются все дополнительные работы. И только после согласования бюджета принимается решение о запуске.
2) Исходя из этого, этап подготовки, скорее всего, будет не быстрый, так как расчет бюджета на чем-то должен строиться.
3) Естественно, предъявляются повышенные требования к тем специалистам, которые будут участвовать в проекте.
4) Сюда же я запишу и сложные инфраструктурные решения, но об этом чуть позже.
5) Модернизация существующих процессов тестирования и выпуска. Потому что автотестировщики – новый элемент команды. Если он раньше не был предусмотрен, соответственно, нужно его встроить в процесс. Автотестировщики не должны болтаться справа, слева, сбоку от проекта.
6) Проектный подход дает планомерность, последовательность, хотя, с другой стороны, его реализация может быть более медленной, чем реализация первого подхода.
7) Ну и отчетность. Много отчетности. Потому что за любой бюджет с вас спросят. Соответственно, вы должны понимать, как у вас работают автотесты (плохо, хорошо), какие тенденции, какие тренды, что нужно увеличивать, что улучшать. Это контролируется отчетностью.
Долгая дорога в светлое будущее
Disclaimer: Мы сразу были такими умными (на самом деле — нет).
Здесь классификация проблем, с которыми мы столкнулись. Разберу каждую по отдельности. Сделаю это намеренно, чтобы вы принимали во внимание эти «грабли». Потому что эти проблемы, не будучи решенными на старте проекта, напрямую отразятся, как минимум, на его длительности, как максимум – они увеличат его бюджет или могут вообще закрыть проект.
- Разные команды — разные подходы.
- Слабая погруженность автоматизаторов в функционал.
- Неоптимальная структура тест-кейсов.
- Документирование фреймворка.
- Проблемы в коммуникациях.
- Своевременная покупка лицензий.
Разные подходы к автоматизации
Пыпытка номер раз
Первая попытка у нас была по первой модели (см. способ №1). Небольшая (но гордая) инициативная группа тестировщиков решила попробовать автоматизацию. По большому счету, мы хотели посмотреть на то, что вообще из этого получится. Сейчас мы бы, конечно, такого делать не стали, но тогда опыта не было, и мы решили попробовать.
У нас был один тимлид с опытом автоматизации, 3 горящих желанием автоматизировать тестировщика и много желания освоить этот путь. Тимлид, правда, был приходящий и не мог уделять проекту много времени, но положительным эффектом его работы стало то, что мы написали свой фреймворк. Мы посмотрели на те фреймворки, которые есть, они были дорогие и классные либо бесплатные, и к ним прилагалась инструкция «после сборки доработать напильником по вкусу». В общем по ряду причин мы не могли их использовать. Соответственно, решили написать свой фреймворк. Сам выбор и процесс написания — тема для отдельной статьи, а то и не одной.
Не сказать, что эта попытка была провальная, просто она себя изжила и закончилась. Когда мы поняли, что нужен бюджет, нужны дополнительные силы, нужны скилы, нужная другая организация команды. Мы автоматизировали порядка 100 кейсов, посмотрели, что это работает, и закруглились.
Попытка номер два
Ничто так не манит, как надкушенный бутерброд.
Через некоторое время мы опять вернулись к теме автоматизации.
Но, помня о первом опыте, перешли к способу №2. Здесь у нас уже была довольно «скилованная» команда, автоматизировавшая не один проект. Но тут мы столкнулись с другой бедой. Эта команда пошла на поводу у команды UI-тестирования. Как это произошло?
— Мы хотим вот это автоматизировать!
— Может, подумаем?
— Нет, мы не хотим ничего думать, мы хотим вот эти автотесты.
Титаническими усилиями они это автоматизировали, и оно даже заработало. Но с течением времени стабильность запусков начала падать, а когда мы собрали свою собственную команду автоматизаторов и стали передавать проект им, оказалось, что половина тестов сделана на костылях, половина проверяет то, что предполагал автоматизатор, а не то, что хотел ручной тестировщик.
А все потому, что автотесты бегали по сырому коду, который ежедневно подвергался правкам. Т.е. изначальный набор кейсов был не верный. Мы должны были погрузиться сами в ту тематику, которую хотим автоматизировать, с точки зрения ее автоматизируемости (здесь и далее масло масляное). Очень критично подойти к кейсам, которые мы отдаем на автоматизацию, и на определенном этапе какие-то из них отбросить, какие-то разделить и так далее. Но мы этого не сделали.
Что в итоге. Мы автоматизировали еще кусочек, порядка 300 кейсов, после чего проект закончился, т.к. стабильности запусков не было и понимания, как это сопровождать — тоже. А мы поняли, как делать не надо… во второй раз.
Попытка номер три
К третьей попытке мы подходили, как пугливая лань к водопою.
Кругом видели риски (и срывы сроков). Подходили критично, в первую очередь, к тест-кейсам и их авторам – тестировщикам UI – как к заказчикам процесса. Нашли такую же критически мыслящую команду автоматизаторов и стартовали уже нормально обсчитанный (как мы считали), полностью готовый (ха-ха) проект.
Грабли уже лежали и ждали нас.
Слабая погруженность автоматизаторов в функционал
На первом этапе (здесь и далее речь о третьей попытке), когда еще были слабо налажены коммуникации, автотестировщики работали за некой ширмой: им на вход поступали задачи, они что-то там автоматизировали. Мы запускали автотесты. Видели статистику, что у нас все плохо. Копали логи автотестов. А там, к примеру, падение на орфографической ошибке в наименовании выгружаемого файла. Понятно, что тестировщик, который тестировал этот функционал руками, заведет минор и поскачет проверять дальше. Автотест же падает и валит всю цепочку, которая базируется на его основе.
И когда мы стали погружать автотестировщиков в функционал, объяснять, что именно мы проверяем в кейсах, тогда они стали понимать эти «детские» ошибки, как их избегать, как их обходить. Да, опечатки есть, есть некие несоответствия, но автотест при этом не падает, просто логирует их.
Неоптимальная структура тест-кейсов
Это, наверное, наша самая большая головная боль. Она дала больше всего проблем, больше всего временных затрат, больше всего часов и денег мы на них потеряли. Как следствие, теперь такую проблему мы будем решать в первую очередь, если будем что-то еще автоматизировать.
Проект у нас довольно большой, в нем крутится несколько десятков информационных систем, они объединены по рабочим группам. И вроде бы стандарты написания кейсов у всех одинаковые, но у одной группы этот кусочек называется «функция», у другой называется «полномочие», а автотестировщик читает и «функцию», и «полномочие», и впадает в ступор. Это просто как пример. Таких ситуаций на самом деле были сотни. Пришлось все это стандартизировать, причесывать.
С чем еще столкнулись, кроме таких двусмысленностей? У нас обнаружились не атомарные тест-кейсы. Это тест-кейсы, которые на каком-то из шагов могут выполниться вариативно. К примеру, в условии, написано «вы можете выполнить шаг 2 под таким полномочием и под таким полномочием», а на шаге 3, например, в зависимости от использованного полномочия «нажать либо кнопку «А», либо кнопку «С». С точки зрения ручного тестировщика, все нормально. Тестировщик понимает, как это пройти, автотестировщик не понимает, как это пройти. В плохом варианте он сам выберет путь, в хорошем – он придет с уточнением. На преобразование не атомарных тест-кейсов мы потратили изрядное количество времени.
Документирование фреймворка
Всегда нужно думать о тех, кто придет после тебя. Как они будут разбирать твой код, анализировать и т. п. Хорошо, если там есть грамотные инженеры, программисты. Плохо, если их нет. Тогда можно столкнуться еще и с тем, что нужно разбирать наследие прошлых «побед», документировать заново, привлекать дополнительных людей, тратить дополнительное время.
Проблемы в коммуникациях
1. Отсутствие регламентов по взаимодействию
Пришла команда автоматизаторов, они не знают, как общаться с командой ручного функционального тестирования, и никто их, собственно, не знает, что за люди, чем заняты. Да, есть лиды, которые между собой коммуницируют, а все остальные – просто соседи по проекту.
2. Наличие регламентов по взаимодействию
Потом были написаны регламенты, но ребята уже некоторое время проработали друг без друга, и, когда были написаны регламенты, они восприняли это как единственный инструмент для взаимодействия. Все, что выходило за его рамки, игнорировалось.
То есть сначала ребята просто не знали, как между собой общаться, вроде бы они в одних чатах, но можно ли тут задавать вопросы или нельзя, они не знают. А когда они уже поработали некоторое время в таких условиях, у них сложились свои неформальные закрытые сообщества: мы – «ручники», мы – автоматизаторы. Как общаться? Вот у нас есть регламент – по регламенту.
Своевременная покупка лицензий на специализированное ПО
В какой-то момент, оказалось, что для разработки части кейсов нам все же потребуется платное ПО, но на него нет лицензии. Пришлось приобретать его в пожарном порядке (опять же дополнительные затраты в деньгах и простои по времени).
Roadmap
Соответственно, теперь у нас есть Roadmap, как проводить старт такого рода проектов, он состоит, собственно, из этапов, каждый этап разбит на определенные пункты.
Предварительный этап
Нам нужен тимлид
Тимлид, архитектор, в общем тот, кто будет с нами всю дорогу, тот, кто понимает в автоматизации, кто технически подкован, грамотен. Желательно, чтобы это был разработчик со стажем 5 лет в определенных языках программирования, которые используются на нашем проекте. Потому что так или иначе наш фреймворк будет работать с нашим проектом. Соответственно, лучше всего, если и фреймворк, и проект будут использовать один и тот же стек технологий.
Должна быть фокус-группа
Причем это не должна быть фокус-группа из автоматизаторов. Это должны быть лица, которые в дальнейшем будут принимать решения. Лучше их подружить в самом начале, чтобы было понимание, какие они решения принимают, для чего и зачем.
Оценка состояния базы тест-кейсов
Про оценку состояния базы текст-кейсов я уже говорил выше, соответственно, это тоже делается на самом предварительном этапе.
Выясняем, что не подлежит автоматизации
Зачастую есть желание автоматизировать все, что движется (а все, что не движется, двигать и автоматизировать), на самом деле порядка 40% тест-кейсов обычно настолько дороги в реализации, что в принципе никогда не окупятся. Поэтому здесь нужно очень четко себе представлять, что вы хотите: автоматизировать все и вылететь в трубу или вы хотите автоматизировать определенный кусок функционального тестирования, который поможет вам.
Оценка пилотного проекта
Оцениваем на предварительном этапе пилотный проект (сколько он будет стоить) и выполняем его на самых сложных (обратите внимание) кейсах.
Пилот
Нормализация тест-кейсов
Набранный пул кейсов подлежит нормализации. Устраняются двусмысленности и лишние предусловия.
Подготовка фреймворка
Пишем свой фреймворк, дописываем имеющийся или используем какой-то покупной.
Инфраструктура
Готовим инфраструктурные решения.
Тут очень важно не прогадать: у вас будет непреодолимое желание использовать на первом этапе какой-то домашний компьютер под столом для запуска автотестов. Этого делать не нужно (тесты будут тормозить и отвалятся, когда кто-то случайно вырубил комп или пролил на него кофе). Нужно использовать готовые инфраструктурные решения, виртуальные машины, смотреть практику применения. Соответственно, сразу же рассчитывать его мощность как на этот проект, так и на последующий большой. Для этого нам нужен специалист по автоматизации.
Промежуточные итоги и корректировки
Пишем первые кейсы. Проводим оценку скорости работы всего этого счастья. Оцениваем дополнительные потребности в людях, поскольку мы уже понимаем, сколько будут автоматизироваться эти кейсы. То есть мы автоматизировали пять штук, теперь мы должны понять, сколько нам нужно людей, чтобы автоматизировать, условно, еще 5 тысяч. Какие-то дополнительные лицензии, железо для стенда, причем как для стенда, который будет запускать автотесты, так и для стенда самого приложения. Ну и, собственно, необходимость доработки тест-кейсов — насколько все плохо.
Подведение итогов пилота
Подводим итоги, пишем отчет и принимаем решение, будем мы идти в автоматизацию или нет.
Я уже писал ранее, что может так случиться, что и не пойдем. То есть, если, например, окупаемость 18 лет, а срок вашего проекта – 5, стоит подумать, зачем вам это надо.
Этап запуска
Пункты перечислены последовательно, но на самом деле они все должны выполняться параллельно.
- Запускаем подбор команды.
- Определяем лидов.
- Приоретизируем скоуп кейсов.
- Нормализуем тест-кейсы.
- Решаем «инфраструктурные сложности».
- Пишем регламенты и инструкции, налаживаем коммуникации, устраняем узкие места.
- Улучшаем фреймворк для одновременной работы нескольких автотестировщиков и распараллеливания групп запускаемых тестов.
- Делаем модуль отчетности и статистики (разовой и накопительной).
- Приступаем к написанию автотестов.
Основной этап
На основном этапе все просто (хаха): пишутся автотесты, осуществляется поддержка написанного, оцениваются результаты запусков, принимаются управленческие решения, подкручиваются мощности, добавляются потоки, и, собственно, коммуникация и еще раз коммуникация с командой UI. Все должны плыть в одной лодке и грести в одну сторону.
Этап сопровождения
Этап сопровождения немногим отличается от основного этапа. Существенное отличие – в его длительности. К тому же в нем гораздо меньший процент разрабатываемых новых автотестов. По нашим оценкам, 6-10% за релиз, в остальном он очень похож на основной этап.
Что в итоге?
Мы автоматизировали порядка 1500 end-to-end кейсов. Стабильность успешных запусков держится уже несколько релизов на отметке 92-95%.
Затраты на регресс сократились почти в 2,5 раза. Сами прогоны проходят за 3-4 часа, делается это ночью, чтобы к утру иметь готовые результаты.
Подробности технической реализации изложены в цикле статей моих коллег:
- Автоматизация End-2-End тестирования комплексной информационной системы. Часть 1. Организационная
- Автоматизация End-2-End тестирования комплексной информационной системы. Часть 2. Техническая
- Как сделать базовый тест-класс для Selenium тестов и выполнить инициализацию через JUnit RuleChain
Если мы сейчас будем запускаться с учетом всего, о чем я написал, думаю, что мы сильно сэкономим нервы, время и бюджет.
Спасибо за внимание. Задавайте вопросы, будем обсуждать.
Автор: SidneyXP
