Думают ли автотесты об электробагах

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

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

    В этой статье я постарался:

    • осветить «детские болячки» тест-менеджмента, стремящегося автоматизировать все, что не приколочено,
    • пояснить, какую пользу может нанести бюджету проекта автоматизация тестирования без детального анализа ее скоупа и должной подготовки,
    • составить 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 часа, делается это ночью, чтобы к утру иметь готовые результаты.

    Подробности технической реализации изложены в цикле статей моих коллег:


    Если мы сейчас будем запускаться с учетом всего, о чем я написал, думаю, что мы сильно сэкономим нервы, время и бюджет.

    Спасибо за внимание. Задавайте вопросы, будем обсуждать. 

    Источник 

    А еще ждем к себе в команду юных тестировщиков!
    У нас открыты Школы тестирования в Москве, Ижевске, Уфе и в Челябинске.

    ГК ЛАНИТ
    Ведущая многопрофильная группа ИТ-компаний в РФ

    Комментарии 12

      +4

      Большое спасибо за статью. Подскажите, пожалуйста, сколько времени прошло от первой попытки до текущего результата? Прошу прощения, если упустил это в статье.


      Часто сталкиваюсь с ситуацией, когда компания страдает от недостатка автоматизации и нанимает сеньора/лида/команду со словами "мы хотим, чтобы вы сделали, как надо". Однако потом оказывается что-то в духе "у нас уже есть 5 E2E ручных тестов, которые мы гоняем раз в месяц, но хотим ежедневно. Осталось только заскриптовать." Или, что ещё хуже: "наши эксперты-программисты уже написали фреймворк для вас, но у них нет времени поддерживать, пока этим занимаются ручные тестировщики, но они тоже начали жаловаться на недостаток времени". И в том, и в другом случае команда автоматизации тратит больше времени не на то, чтобы "сделать, как надо", а на то, чтобы объяснить, что текущие практики не соответствуют (физически не могут, к сожалению) ожидаемым результатам, и показать (читай "продать") те baby steps, которые приведут к качественным изменениям. При этом менеджеры искренне удивляются, почему нанятые специалисты до сих пор не могут сделать автоматизацию стабильной. Достаточно типичным является диалог, когда автоматизатор предупреждает, что данная попытка приведёт к ситуации


      "стабильности запусков не было и понимания, как это сопровождать — тоже"

      на что менеджеры говорят что-то в духе "откуда ты знаешь — ты же не пробовал в нашей компании? Не сравнивай нас с другими — мы другая компания". Фактически, автоматизаторов просят пройти весь путь от первого подхода и первой попытки заново.


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

        +3
        Подход к автоматизации должен зависеть только от типа приложения, но никак не от предприятия. А скитания по Граблестану неизбежны. Приложение живет, развивается, меняется. Автоматизация, всегда бежит позади и адаптируется. Готовые решения есть только под стандартные задачи, а где вы видели стандартные задачи, ведь под них уже есть готовые решения.
        Казалось бы, можно заложиться на эту тенденцию к динамике изначально, при выборе архитектуры автоматизации. Но на практике никогда не дают времени хоть сколько нибудь достаточно всмотреться в перспективу и продумать более менее безболезненный путь. Тебя всегда гонят вперед.
        Автоматизация для менеджеров состоит только из преимуществ и единственный ее «недостаток» это ее стоимость. Поэтому они считают всякие ROI. У меня от этого слова глаз дергаться начинает, простите.

        Я обычно так обьясняю: задача тестирования предоставлять критическую информацию о состоянии продукта. Автоматизация этого процесса, дает соответственно повторяемость, разгрузку человеческого ресурса, бескомпромиссную точность (которая часто для начинающих оборачивается сюрпризом в виде нестабильных тестов). В результате у нас появляется поток информации, который нужно обработать. Разбирать, является ли остановка ошибкой в системе автоматизации или в продукте. Соответственно, роли немного меняются. Теперь тестировщик занимается анализом того, что выдала автоматизация, и уже по результатам анализа заводит репорты.
        У нас например в день вываливается столько результатов тестов, по всем билдам, что просмотреть их все физически невозможно. И тут это промах менеджмента заказчика, что им важно количество автотестов. А то, что генерируемую этими тестами информацию невозможно обработать никакими силами, уже никого не волнует. И получается такая ситуация как «горшочек, не вари». И это я молчу про то, сколько бывает тестов, которые пишут лишь бы цифры сходились. Поставь неправильную цель и загубишь все. А происходит все оттого, что заказик сам знает как правильно, и никого ни о чем не спрашивает.

        А вот теперь самое интересное, касательно эффективности.

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

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

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

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

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

        Бонусом ко всему вышесказанному добавлю, что автоматизатор должен разбираться в архитектуре приложения. Это обязательно, чтобы правильно писать тесты, и чтобы писать правильные тесты. Например, при использовании «серых» методов управления программой, это позволит понять, какие слои приложения будет охватывать сценарий. Если я дёрну какую-то внутреннюю функцию в приложении для чего-то там, эквивалентно ли это тому, что будет происходить при использовании вживую. Очень важно четко понимать где твой автотест заходит за черту своей целесообразности.
        Я например пишу е2е тесты под эмулятор приложения. И иногда, несмотря на шестилетний опыт, обжигаюсь на том что забываю, что реальный, назовем его — «бекэнд», будет вести себя не так как моки. Т.е. я проверяю работу приложения с моками «бекэнда». Часто моки ведут себя идеальнее «бекэнда». Тут на помощь приходят разработчики и говорят, что тестировать эту функцию на моках нет смысла. Поэтому нужно разбираться в архитектуре и слоях приложения, чтобы не тратить силы на то, на что тратить силы не нужно, а тратить их на то, что действительно полезно.

        P.S. У нас сейчас идет пятая инкарнация автотестирования за восемь лет, самая живучая и перспективная пока, но не без проблем конечно. Правда, проект серийный, поэтому заказчик может себе позволить сеять, сжигать и сеять заново.
          +4
          Спасибо, это уже не комментарий, а целая статья)
          Даже сложно что-то добавить, но я попробую)
          1) автоматизаторов нужно плотнее интегрировать в остальную команду и это не только тестировщики но и разработка. Многие проблемы решаются в разы быстрее, если налажено такое взаимодействие.
          2) Позволю себе не согласиться с единственной метрикой автоматизации. Да, она повысит плотность, но не сама по себе, а высвобождая ресурсы ручных тестировщиков. Поэтому метрик наверное будет как минимум на 1 больше — высвобождаемое время ручных тестировщиков. Полезных метрик конечно)
            0
            1) Совершенно согласен, подтверждено личным опытом.
            2) Я имею ввиду это конечная метрика в которую вливается все. Плотность обнаружения ошибок повышается, конечно, в большой степени при помощи людей, которые теперь получат больше времени на нужные, но сложные для автоматизации сценарии для проверки руками. И, при хорошо настроеной автоматизации заведение репортов на тривиальные ошибки должно сократиться. А само по себе высвобожденное время никакая не метрика эффективности автоматизации тестирования. Ведь у нас нет цели освободить людей от работы. А скорее, с помощью компьютерных технологий увеличить эффективность человека, по большому счету.
              0
              Согласен)
          0
          Добрый день.
          Спасибо за проявленный интерес.
          Все описанное в статье заняло около 3х лет. ± 2 месяца.

          Мы тоже искренне надеемся, что наш опыт кому-то поможет.
          0
          >мы получаем быстрый эффект «смотрите, этот тест раньше проходил день, теперь я могу заменить его роботом, он проходит 2 дня, но моего участия здесь нет
          Странная автоматизация, когда время на прохождение автотеста, больше времени ручного тестирования=)
            0
            Странная, если бы сам не видел, не поверил бы)
              0

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


              У меня было несколько примеров на практике: тестирование совместимости и compliance testing (прошу прощения, не знаю, как это нормально переводится на русский). Представьте, что у вас есть приложение, которое теоретически может конфликтовать с антивирусами (драйвера, системные перехваты и т.п.). Скорее всего вам придётся регулярно проводить тестирование на машинах с разными антивирусами. Ручные тестировщики делают это так: держим машины с установленными антивирусами, а сам процесс тестирования выглядит следущим образом:


              1. обновляем версию антивируса, устанавливаем последние модули проверки;
              2. делаем новый снепшот машины для следующего прогона;
              3. устанавливаем наш продукт;
              4. тестируем;
              5. откатываем на снепшот;
              6. удаляем самый старый снепшот для экономии ресурсов.

              В данном случае тестирование очень небольшое, потому что нам достаточно буквально несколько (максимум пару десятков) тест-кейсов, чтобы убедиться, что не возникают deadlock'и или прочие конфликты с антивирусом. В итоге оказывается, что большую часть времени тестировщики тратят на пункты 1, 2 и 5, 6, т.е. те, которые с нашим продуктом вообще не связаны.
              К сожалению, в то время, когда я этим занимался, руками обновлять или конфигурировать антивирусы было в 100 раз проще, чем надёжно автоматизировать (попробуйте надёжно кликнуть кнопку "Обновить" в кастомных GUI под Windows).
              В итоге, в данном случае пожертвовать временем ради освобождения ручных тестировщиков будет вполне себе разумной идеей. Автотесты автономно гоняются раз в неделю, пусть это даже будут 2 машинодня по выходным и 2 человекачаса в понедельник на разбор результатов. И это будет примерно в 4 раза лучше чем 1 человекодень каждую неделю.


              Аналогичная история с compliance'ом: если вам раз в месяц нужно проверить совместимость с обновлениями Windows, освобождение ручных тестировщиков от этой задачи будет ценнее сэкономленных машиночасов. Да и если посмотреть, то подобных задач не так уж и мало. Другой вопрос, что в большинстве своём они связаны с нефункциональными требованиями, куда автоматизация не всегда успевает (или физически может) добраться, кроме, может быть, требований производительности и надёжности под нагрузкой.

                0
                Добрый день, спасибо за комментарий!
                Можно немного пояснений? Не могу уловить, почему автотесты у вас работают дольше, чем ручной тестировщик при выполнении всех пунктов 1-2-3-4-5-6 последовательно? То что вы их запускаете в нерабочее время понятно. Это разумно. Но почему дольше?)
                Или вы имели ввиду, что время одинаковое, просто вы экономите рабочее время?
                Тогда тут нужно считать затраты на разработку и сопровождение этого теста.
                  0

                  Разница во времени появлялась из-за того, что пункт 1 (обновление антивируса) был очень тяжёл для автоматизации. Вот несколько проблем, которые легко решаются вручную, но сложны в автоматизации:


                  1. Какие-то антивирусы не предоставляли возможность конфигуации/обновления на клиенте — это означает, что надо каким-то образом тригернуть обновление с серверной компоненты.
                  2. Антивирусы не склонны, по понятным причинам, предоставлять возможность конфигурации/обновления извне (CLI, например). У некоторых антивирусов есть возможнось импортировать настройки, за что им огромное спасибо. У большинства (по крайней мере, на тот момент) вся конфигурация жила в кастомных UI. Это касается и серверных компонент из предыдущего пункта.
                  3. Обновление лицензии. Если лицензия кончилась, человек знает, что делать. А для автотестов это, естественно, головная боль.

                  В конечном итоге, мы автоматизировали тесты только для тех антивирусов, для которых нашли надёжные решения проблем выше (осталось примерно 3-4 штуки). Сам процесс стал другим:


                  1. Установка антивируса на чистую машину.
                  2. Установка/выбор триальной лицензии.
                  3. Обновление модулей.
                  4. Запуск автотестов.

                  В данном случае получилось ещё избавиться от хранения машин с антивирусами и сэкономить на лицензиях (жаба особенно душила покупать лицензии, чтобы использовать раз в месяц). Но, естественно, пришлось провести анализ модулей, которые присутствуют в триальной лицензии, чтобы понимать, что тестирование совместимости действительно имеет смысл.
                  Плюс ещё получилось иметь возможность тестировать разные версии одного антивируса (процесс установки редко меняется).
                  Естественно, этот процесс намного медленнее пункта 1 (обновление антивируса вручную), даже с учётом того, что пункты 2, 5 и 6 (управление снепшотами) больше не нужны.


                  Надеюсь, достаточно подробно ответил на Ваши вопросы.

            0
            Пункты перечислены последовательно, но на самом деле они все должны выполняться параллельно.


            Как-то странно написано и сразу же за этим идет последовательность.

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

            У меня есть очень больные примеры, когда инфраструктура определялась заранее и главное — на нее были потрачены огромные деньги, а потом оказывалось, что она не подходит.

            Про электробаги в статье ничего не написано, но тема автотестирования железа — это вообще песня сегодня.
            Тут поле непаханное граблей и люди, приходящие из софта, думают, что все это очень легко автоматизировать, так как «питон и фреймворки все порешают». Ага, конечно. Только учти, что вот эту кнопочку надо нажать ручками, а тут у нас хитрый электрический интерфейс на мотор. А саму плату управления мы еще не заказали, но ты же умными тестами гарантируешь ноль багов в прошивке, правда?..

            Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.

            Самое читаемое