Home

Автор: Айжана Нургалиева

Оригинальная публикация: http://quality-lab.ru/bad_automation_testing_organization_example_and_its_debriefing/

Про автоматизацию

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

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

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

Итак, мы поговорили о параллельной вселенной, а теперь возвращаемся домой :). В нашей практике на каждое «вау» всегда находится свое «но», на каждый плюс – свой минус. И вот для того, чтобы эти минусы не потянули всю вашу разработку в пропасть, в тартары, вам просто необходимы «правильные» (внимание!) менеджерские подходы организации автоматизированного тестирования на проекте. Почему слово «правильные» заключено в кавычки? Да просто потому, что тестирование ПО – довольно молодая сфера человеческой деятельности, и здесь еще мало законов и постулатов. Существует ряд правил, выведенных эмпирическим путем, путем проб и ошибок старших товарищей. Наше же дело – смиренно внимать, наполняя свою чашу знаний.

Про мысли

Мысли – сущности нематериальные и витают в воздухе, а потому идея автоматизировать тестирование может зародиться в голове у абсолютно любого участника процесса разработки ПО. Опаснее всего, когда этой головой оказывается голова Заказчика, а в команде нет ни компетенций, ни экспертизы постройки процессов автоматизации. В конечном итоге такое несоответствие становится причиной недовольства Заказчика, убыточности автоматизированного тестирования и полного разочарования в автотестерах. Если вы не хотите столкнуться с подобной ситуацией – «замьютьте» мессенджеры, включите уже наконец-то мультик детям и посвятите 5 минут данной статье.

Правдивая история

Разрабатывала команда как-то банковское ПО, а именно кредитный конвейер. В принципе, обычное себе такое веб-приложение, но с некоторыми особенностями, а именно:

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

И однажды ЭТО свершилось: на отдел тестирования спустилась директива о тотальной автоматизации процессов, причем всех и сразу. Наспех выделили одного тестировщика со слабым (ну, хоть каким-то) знанием Java, поставили ему цели в рамках личного KPI организовать автоматизированное тестирование, пообещали со всех сторон поддерживать и консультировать (как показал опыт, обещания были пустыми). Компания обеспечила нашего специалиста всеми необходимыми инструментами и отодвинулась на задний план, дабы не мешать таинству автоматизации. У «избранного» голова сделалась горячей от карьерного взлета и всеобщего внимания, он сразу же углубился в написание GUI тестов.

И что же получила команда через месяц? Начнем с особенностей продукта. Время отклика сторонних систем было всегда разным, от нескольких минут до нескольких часов. Зачастую автотесты просто отваливались по таймауту; тестировщик долго ждал ответа систем, а затем руками перезапускал заявку.

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

В итоге регресс автотестами иногда занимал даже больше времени, чем ручной регресс. Материальная сторона вопроса также не радовала. Стоимость работы автоматизатора почти в два раза выше стоимости работы ручного специалиста. Нетрудно прикинуть, что в данном случае даже выход на нулевой показатель ROI (возврат инвестиций) мог бы считаться успехом; но что-то подсказывает мне, что команда была далеко в минусе. Конечно же, такой подход бросил тень на команду разработки ПО, и у Заказчика уже начали закрадываться сомнения в компетентности и профессионализме отдела тестирования.

Дальше вести повествование, наверное, не имеет смысла. Скажу только, что для всех участников история закончилась хорошо. О том, какие выводы можно сделать из этой «тру стори», читайте ниже.

Полезные советы

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

Важный шаг в планировании автоматизации тестирования – постановка цели. Конечно же, сегодня, имея много доступной информации по автоматизации, хочется получить все и сразу. Но, как говорится, за двумя зайцами погонишься – ни одного не поймаешь.

Имейте смелость выделить одну единственную цель и имейте храбрость отказаться от нее, если все идет не по плану. Как же вовремя отследить этот критический момент? Наметьте отрезок времени для вашей цели, поделите его на короткие периоды, затем проводите анализ каждого периода. Будет ли это ретроспектива или полноценный аудит – зависит от масштаба «производства». Но не забывайте, что при этом необходимо иметь измеримые критерии достижения вашей цели.

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

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

Заметим еще, что в нашем случае полезней было бы автоматизировать тестирование API, а не GUI. Написание GUI тестов считается в среде тестировщиков трудоемкой и дорогой работой. В нашей истории были реализованы сложные сценарии нажатий кнопок, переходов по формам, ожидания и получения откликов сторонних систем и т.д. Все это при прогонах требовало много времени – как раз того времени, которое команда планировала сократить с введением автоматизации.

Если на вашем проекте не удается избежать автоматизации GUI, то не забывайте о соблюдении классической пирамиды тестов (на 1000 юнит-тестов должно приходиться около 300 интеграционных тестов и порядка 30 UI). Важный момент – уровни не должны пересекаться (например, API не должно тестироваться GUI тестами).

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

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