зачем нужна автоматизация тестирования
Зачем нам нужно автоматизированное тестирование?
Автоматизация — один из лучших способов проверить, насколько хорошо работает текущее программное обеспечение по сравнению с его предыдущими версиями. Иными словами, автоматизация — это обнаружение регрессий и обкатка различных вводов. До тех пор, пока не появится возможность писать автоматизированные скрипты для вашего приложения, множество ошибок, которые могут быть обнаружены в процессе написания скриптов, уже будут успешно найдены и устранены.
Многие ошибки, связанные с автоматизацией, обнаруживаются во время непосредственного написания автоматизированных скриптов. Во время непосредственного осуществления автоматизации может быть обнаружено лишь несколько новых программных ошибок, хотя ошибки могут быть найдены при выполнении автоматизации в различных конфигурациях или через наборы данных.
Тем не менее, автоматизация ассоциируется с управлением, поскольку она позволяет сэкономить время, уменьшить количество используемого оборудования, ресурсов и тестировщиков ПО, которые привлекаются компанией по тестированию программного обеспечения для получения высококачественного продукта. Для многих проектов автоматизации трудно определить, что от них ожидалось, поскольку те, кто выполняет автоматизацию, не понимают, что автоматизация — это просто еще один инструмент, который можно использовать для тестирования программного обеспечения.
Автоматизированное тестирование в большей или меньшей степени используется почти в каждом проекте. Оно не дает никаких гарантий и не защищает продукт от плохой работы, в то время как тестирование программного обеспечения влияет на повышение качества продукта. Плохо реализованная автоматизация в конечном итоге будет стоить больше времени и усилий, чем ее отсутствие. Тем не менее, если ее реализовать, она принесет значительные выгоды. Необходимо понимать, что автоматизация нужна только для того, чтобы оценивать регрессии и быть «monkey tester», что не означает выполнение одного и того же теста каждый день одним и тем же способом. Не обращая внимания на эту задачу, тестировщики ПО могут выполнять простые действия и использовать свои творческие и интеллектуальные способности для поиска новых ошибок.
Только 5-20% всех ошибок программного обеспечения обнаруживаются во время автоматизированного регрессионного тестирования. Учитывая тот факт, что автоматизация тестовых случаев может быть в 10 раз дороже, чем их ручное выполнение, без учета поддержки и сопровождения тестового кода, тестовые случаи для автоматизации следует выбирать очень тщательно.
Чтобы стать хорошим автоматизатором, нужно знать не только языки программирования и фреймворки для автоматизации, но и теорию тестирования. На двухдневном онлайн-интенсиве мы узнаем, что такое тестирование и откуда оно появилось, кто такой тестировщик и что он делает. Изучим модели разработки ПО, жизненный цикл тестирования, чек листы и тест-кейсы, а также дефекты. На втором занятии познакомимся с одним из главных трекеров задач и дефектов — Jira, а также попрактикуемся в TestIT — отечественной разработке для решения задач по тестированию и обеспечению качества ПО. Присоединяйтесь!
Когда нужны тесты и автотесты, взгляд из надсистемы
Нужно ли автотестирование? Когда оно нужно? Какую ценность оно приносит?
В статье разобраны когда и зачем нужно тестирование как таковое и в каких случаях нужна его автоматизация.
В ходе дискуссии по этому вопросу, проводимой в клубе им. Френсиса Бекона (“ВебПосиделки КиФБ” в teleram), коллеги обменялись опытом и записали свои мысли.
Автоматизация тестирования нужна, если это приносит ценность. Когда же само тестирование приносит ценность? Выявлено два случая.
Если процесс отлавливает ошибки в ПО перед выкладкой на бой
Если тестирование новой версии выявило ошибки, которые были в последующем исправлены, то это тестирование было проведено не зря.
Но что если ситуация обратная? Если тестирование не нашло ошибки, но они проявились на бою? Если ошибки при этом были обнаружимы на тестовом стенде (в т.ч. тестовый стенд настроен наиболее близко к бою).
Утверждается, что в этом случае тестирование проведено некачественно.
Как измерять качество тестирования? Для этого случая пригодна метрика = количество ошибок на тестовом окружении / (количество ошибок на тестовом + боевом окружении). При этом количество ошибок берется взвешенное по уровню их критичности.
А что если тестирование не нашло ошибок и их не было обнаружено на боевом сервере?
Утверждается, что этом случае тестирование, как таковое, не принесло ценности и эти работы были сделаны зря (за исключением следующего случая, про который мы расскажем позже). С точки зрения Lean это потери.
Когда возможна такая ситуация? Когда тестируемый модуль не изменялся. Что может изменить модуль?
Когда нужно писать автотесты в этом случае?
Начнем с того, что автоматизированное тестирование не отменяет тестирование постановки, тестирование дизайна и написания тест кейсов по постановке! И не заменяет их. Если этого нет, то и автоматизацией не следует заниматься. При этом под автотестами следует понимать не только само выполнение сценария, но и подготовку к их прогону и использование результатов.
Если писать автотесты после создания кода, то это приведет к увеличению time2market (что автоматически приведет к увеличению связного капитала). Поэтому если принято решение покрывать код автотестами, то следует писать эти автотесты параллельно основному коду, в парадигме разработки “TestFirst” или “TDD”.
Основная ценность создаваемая при этом автоматизацией тестирования — это сокращение time2market за счет более быстрой выкладки новой версии.
Тесты нужны для гарантии работоспособности критических процессов
Несмотря на то, что автомобиль ни разу не загорелся, тем не менее наличие огнетушителя в нем не бесполезно.
Ошибка на сайте с большим трафиком, не позволяющая добавлять товар в корзину, может привести к более значимым потерям, чем расходы на разработку и проведение тестирования этой функции за год.
Следовательно, нужно выделить критические процессы, которые войдут в регулярные проверки (которые стоит делать если происходит какое-то изменение). Сопоставлять следует:
Это возможно через запуск нескольких инсталляций решения и тестирования новых beta-версий на “кошечках”, если это технически возможно и если найдутся такие добровольцы. После выкладки новой версии мониторится телеметрия и производится откат, в случае деградации показателей. (Напомним, что телеметрия на бою обязана быть вне зависимости от наличия тестирования).
Еще один случай полезности регрессионного автотестирования — это тестирование API (тестирование контракта API), если это API требуется для обеспечения критического процесса. Особенно это важно, если разработчики чужого модуля что-то меняют и не делают качественное тестирование изменений на своей стороне.
Когда не нужна автоматизация тестов
Если вам достался большой объем унаследованного не очень качественного кода. Покрывать автотестами такой хаос это увеличивать хаос.
В этом случае стоит выделить из этого решения логический модуль. После выделения слоя взаимодействия этого модуля с остальным кодом нужно покрыть взаимодействие автотестами. Это обеспечит гарантии сохранности поведения модуля и целостности после его перекодирования.
Автотесты не заменяют ручного тестирования. Ручное тестирование чаще всего провести быстрее и дешевле чем написать и в последующем сопровождать автотесты. В частности, если тестирование проводится после разработки кода, то из этого тестирования автоматизировать нужно только тот кусок, который войдет в регулярное тестирование критического функционала.
И напоследок — чеклист готовности компании к автотестам
Сразу оговоримся, этот чек лист не для всех, он написан для тестировщиков компаний, для которых разработка софта есть основной источник дохода.
Что дает автоматизация тестирования
При создании IT-решений ошибки обходятся дорого, это особенно заметно в медицине, где от качества ПО зависят человеческие жизни, или в сфере банкинга, где возможны крупные финансовые потери. Автоматизация тестирования позволяет организовать постоянную проверку качества продукта. Давайте разберемся, в каких случаях она необходима.
Одни компании ошибочно считают, что автоматизация – пустая трата времени и средств, другие – что это крутой тренд и «таблетка» от всех болезней. Рассмотрим, где золотая середина и в чем смысл автоматизации.
Зачем тестировать
Малейшая ошибка в программном обеспечении грозит огромными расходами. Чем лучше выстроены процессы разработки, тем меньше риски. Однако, если обратиться к фактам, мы видим, что недочеты допускают даже такие гиганты, как Google, Microsoft или ведущие банки.
Например, одна из знаменитых “аварий” финансового мира произошла в Первом национальном банке Чикаго в конце 90-х: в одночасье счета клиентов безосновательно выросли на 900 миллионов долларов. Тогда старший вице-президент банка Джеймс Ланкастер признал, что дело в «программной ошибке в компьютере» – которую, к счастью, никто не успел использовать.
Дорогостоящие ошибки бывают и в других отраслях, казалось бы, не связанных напрямую с IT. Известный пример – аварии при запуске космической техники, в частности, в 2017 году Роскосмос утратил спутник стоимостью 2,6 млрд рублей.
При работе с масштабными IT-решениями, например, системами дистанционного банковского обслуживания (ДБО), важно постоянно тестировать не только работу отдельных функциональностей, но и их взаимодействие. В условиях сжатых сроков, когда ведущие банки каждый месяц обновляют свои приложения, проверить все вручную невозможно – на это как минимум не хватит времени.
При создании IT-продуктов для бизнеса обычно сочетают два подхода:
Что дает автоматизация
Это одно из достаточно новых направлений в разработке, окруженных большим количеством мифов. Чаще всего бизнес обращается к автоматизации, веря, что она:
В свою очередь, два последних утверждения действительно справедливы: грамотная автоматизация тестирования помогает и в ускорении релизов, и в увеличении покрытия кейсов. При этом ручное обеспечение качества и автоматизация, как правило, одинаково важны и используются в комплексе. Кроме того, каждый проект индивидуален, и иногда в автоматизации нет необходимости.
Когда автоматизация обязательна
Задачи автоматизации
Как правило, мы привлекаем экспертов SDET для решения следующих задач:
Результаты
Автоматизация помогает выстроить баланс:
Кроме того, при необходимости можно ускорить релизы. Например, если в спринте разработки нужно проверить около 400 кейсов, то их ручная проверка займет до двух недель, а автотесты можно провести ночью и проанализировать за 4 часа.
Бизнес, благодаря автоматизации, получает возможность в любое время убедиться в том, что ключевые функции системы работают правильно и проверить, нет ли ошибок (а если они есть, то в чем заключаются).
Пример
Предположим, что на текущий момент в мобильном банке нужно проходить до 700 кейсов, каждый – от 70 до 100 раз в год. Ручной проверки требуют менее 25% кейсов, остальные 75% можно автоматизировать.
Затраты времени при ручной проверке:
Затраты времени при автоматизации:
Ночной прогон тестов занимает 8 часов, но без участия человека, поэтому не учитывается.
Прочие затраты времени:
Конечно, каждый кейс имеет свои особенности, поэтому временные затраты могут быть разными. Мы постоянно анализируем, сколько времени нужно на написание автоматических тестов, поддержку, анализ результатов.
В среднем, автоматизация экономит от 30 до 50% времени как минимум, позволяя выделить больше времени, например, на развитие и улучшение продукта.
Как происходит автоматизация тестирования
У каждой IT-компании есть свои особенности в автоматизации тестирования, как и в других рабочих процессах. Мы в SimbirSoft придерживаемся следующих методов, которые помогают оперативно выстроить работу с проектами наших клиентов.
Процесс тестирования начинается с разработки стратегии – тест-плана, основы для составления отдельных тест-кейсов. Для автоматизации SDET инженеры выбирают ключевые, часто используемые сценарии работы пользователя с продуктом – такие сценарии дают около 80% бизнес-ценности.
После этого мы создаем основу для дальнейших автотестов, настраиваем стенды и workflow по работе с ними, CI для регулярного запуска тестов на различных ветках. Мы выбираем, какие подходы к подготовке тестовых данных мы будем использовать (API, доступ к базам данных, генерация синтетических данных, использование данных с прода). Инженеры SDET пишут тесты, которые покрывают ключевые сценарии работы с продуктом, анализируют полученные результаты и необходимость дальнейшей автоматизации.
Мы разрабатываем автоматизированные тесты, используя все наиболее востребованные языки программирования – Java, Python, Kotlin и др. Наши основные инструменты и технологии – Appium, TestNG | JUnit, RobotFramework | Pytest, Selenium | Senenide, Allure, TeamCity, Jenkins, JMeter.
Какие тесты нужно автоматизировать в первую очередь – зависит от особенностей конкретного продукта. Большинство компаний автоматизируют smoke тесты, регрессионные тесты для проверки уже готовых функциональностей, а также кейсы для проверки различных параметров (например, валидных и невалидных данных при регистрации).
Мы в своей практике выстраиваем процессы автоматизации тестирования уже на старте разработки, параллельно с ручным тестированием. Эта работа – не единоразовая, она ведется непрерывно, особенно на крупных проектах, в том числе банковских.
Подводя итоги
Баланс ручного и автоматизированного тестирования позволяет постоянно контролировать качество IT-продукта. Некоторые проекты проверяют вручную, другие задачи можно успешнее решить с помощью автоматизации. Тестирование вручную используют в тех случаях, когда люди незаменимы, например, если нужна локализация, описание ошибок, ручная проверка юзабилити. В небольших проектах часто тесты пишут сами разработчики.
Ручное тестирование в комплексе с автоматизацией проводят при создании крупных IT-продуктов, где работает несколько команд (например, в банковских приложениях), где есть сложные алгоритмы и бизнес-логика. Этот метод помогает выстроить процессы тестирования продукта и снизить риск дорогостоящих ошибок, что бывает особенно важно при работе в условиях жесткого графика релизов.
Спасибо за внимание! Надеемся, что статья была вам полезна!
Блеск и нищета автоматизации тестирования
Принято считать, что наличие автоматических тестов — это безусловное благо. Если разработчики пишут тесты — это хорошо, чем больше тестов, тем лучше. При этом, в реальности их чаще не пишут, а все тестирование делают вручную.
Не стоит списывать такое положение дел на некомпетентность, глупость или банальную лень разработчиков. По сравнению с ручным тестированием, автоматизированное имеет как достоинства так и явные недостатки. Если бы были одни только плюсы, и говорить было бы не о чем.
Преимущества автоматических тестов
Автоматизированное тестирование имеет ряд существенных преимуществ по сравнению с ручным тестированием.
Дешевизна — прогон автоматических тестов всегда дешевле ручной проверки на несколько порядков. Разработка автоматических тестов конечно дороже разового ручного тестирования.
Неутомимость — автоматические тесты можно запускать снова и снова, у них неограниченный рабочий день, они не устают, и не болеют.
Скорость — автоматические тесты выполняются на порядки быстрее, чем те же проверки, выполненные вручную. Конечно, бывают и сравнительно медленные тесты, но это скорее исключение, подтверждающее правило.
Точность — автоматические тесты проверяют ровно то, что описано в сценарии, во всех деталях и мелочах. Они не отвлекаются, не путают и не забывают.
Всеобъемлемость — автоматические тесты позволяют покрыть огромное количество сценариев и находить наведенные ошибки в таких далеких углах приложения, до которых ручной тестировщик никогда бы не добрался, кроме как случайно.
Преимущества ручного тестирования
Ручное тестирование, тем не менее, превосходит автоматизированное по многим аспектам.
Проворность — проверить что-то вручную в первый раз легко и быстро. Автоматический тест нужно прежде разработать. Практически всегда это гораздо медленнее ручной проверки.
Гибкость — ручное тестирование можно проводить гораздо разнообразнее, и изменение способа тестирования практически ничего не стоит. Давайте протестируем в Safari — пожалуйста, на Chromebook — нет проблем, IE6 — придется запустить виртуальную машину, но тоже можно.
Адаптируемость — умение быстро подстраиваться под изменения. Когда продукт серьезно меняется, и все начинает работать совсем не так, как раньше, ручные тестировщики легко могут забыть, как они тестировали прежде. Они просто будут тестировать то, что есть сейчас. Автоматические тесты в той же ситуации выдадут тысячи ошибок, и их придется исправить, прежде чем двигаться дальше.
Креативность — ручное тестирование позволяет найти проблемы, которые заранее не были известны, более того, даже не подразумевались.
Осмысленность — хотя каждая вещь в отдельности может быть абсолютно корректна, люди гораздо легче понимают, что вместе эти вещи не имеют никакого смысла.
Выразительность — мало найти проблему на уровне “ничего не работает!”, важно правильно объяснить, в чем она заключается и уметь ответить на дополнительные вопросы разработчика. И в этом люди также лучше автоматических тестов.
Аутентичность — большинство приложений мы пишем для людей, и именно поэтому люди лучше всего подходят для их тестирования.
Блеск парадоксов тестирования
Говоря о тестировании, и тем более о полном тестировании, мы немного лукавим. Очевидно что проверить все невозможно.
Все что мы можем сделать на практике, это осуществить некоторое достаточное тестирование. В результате мы с определенной долей вероятности сможем утверждать что большинство пользователей не столкнутся с проблемами.
Потратив на тестирование 1 день, мы добьемся 90% довольных пользователей. Тестируя неделю — 99%, тестируя месяц 99.5%. На достижение все меньшего и меньшего результата мы тратим все больше времени. Это нецелесообразно.
Исправляя проблемы быстро, можно добиться гораздо более высокого качества продукта, нежели вкладывая все имеющиеся ресурсы в достижение полного покрытия тестами. Соль в том чтобы найти баланс в приложении сил.
Ручное тестирование дает гораздо больше отдачи, если разрабатывать нужно быстро, особенно если приложение меняется инкрементально, в локальных предсказуемых частях. Причина в том, что проверить изменение руками гораздо быстрее, чем автоматизировать тот же тест.
Автоматическое тестирование дает очень маленькую отдачу на коротких дистанциях. В каждый отдельный момент, решая что выгоднее, писать тесты или не писать, второе всегда предпочтительнее.
Ситуация в корне меняется в длительной перспективе. Код приложения необходимо рефакторить, чтобы он не умер. Когда программисты все переделали — тестировщики должны все проверить. Полный цикл регрессионных тестов. Неделя? Две? Месяц? Или еще хуже: программисты обновили версию ключевой библиотеки. День работы, вроде все компилируется — отлично! И все равно тестировщики должны проверить все. Безумие. Пройдя через такое несколько раз, любой будет готов пойти на что угодно, лишь бы избежать подобных ситуаций в будущем. Для обеспечения стабильного базового уровня качества необходимо вкладываться в автоматизацию тестирования.
К сожалению, автоматические тесты не всегда являются решением, иногда они сами становятся проблемой.
Нищета автоматизации тестирования
Проблема: нужно уметь проверять приложение полностью и быстро, ничего не упуская, много раз подряд.
Решение: написать автоматические тесты, которые все это делают.
Но не все так просто.
Написание тестов — это разработка, точно такая же, как и разработка основной бизнес-логики. Она требует ресурсов и квалификации. Обеспечивая качественное покрытие кода приложения тестами мы одновременно замедляем разработку как таковую. И замедляем не на 10%, а вдвое, втрое или даже больше.
Скорость — понятие относительное. Каждый конкретный тест, конечно, выполняется очень быстро, особенно чистые unit-тесты, когда все проверки происходят локально. Интеграционные тесты, REST-тесты тоже сравнительно быстрые. Что такое 100 миллисекунд, ну пусть даже 1 секунда, даже десятки секунд для selenium тестов — ерунда по сравнению с ручным тестированием. Но когда количество тестов хоть сколько-нибудь существенно, быстрые тесты оказываются очень даже медленными. Прогон тестов за 5 минут? Полчаса? Три часа? Два дня? Еще даже не добившись полноценного покрытия бизнес-логики, всерьез встает вопрос о том как запускать не все тесты, или запускать тесты не каждый раз — иначе уже автоматические тесты начинают тормозить разработку.
Примечание: Тесты можно существенно ускорить, вложившись в железо — выделить под них отдельный сервер, 10 серверов, 50 и т. д. Некоторые компании могут позволить себе и 1000 тестовых серверов, но далеко не все.
Инструментарий плох. Ни одна из мейнстримных платформ программирования не проектировалась с целью обеспечить возможность максимально просто и полноценно разрабатывать тесты. В Java все тестовые фреймворки являются сторонними библиотеками. Запуск тестов, осуществление проверок, создание mock-объектов — все это есть, но по частям и вне платформы. В Go тестовый фреймворк уже добавили в экосистему языка изначально, но это только запуск тестов. Выбор подходящего инструментария для написания тестов это отдельная проблема, требующая решения.
Не такие уж они и хорошие. Тесты — такой же код, написанный такими же разработчиками. Они тоже содержат ошибки и все те же проблемы, что и любой другой код. Бывает, что тест ничего не проверяет. Бывает, что тесты тоже нужно рефакторить. Бывает, что по упавшему тесту очень трудно понять, в чем проблема. Бывает, что тесты падают просто так, когда ошибки на самом деле нет.
Блокируют изменения. По своей природе тесты призваны проверять, что ничего не изменилось. Если что-то начало работать не так — это баг. Но когда бизнес-логика меняется, даже если изменение корректно и полностью соответствует новым требованиям — тесты об этом ничего не знают. Изменений нескольких правил может привести к необходимости исправить десятки, если не сотни тестов, особенно если покрытие действительно хорошее.
Ограничивают рефакторинг. Тесты тоже нужно рефакторить, даже если бизнес-логика не меняется, и в коде происходят лишь косметические изменения. Это может привести к тому что нужно поправить 5 мест в основном коде и еще 80 в тестах. Каждый в такой ситуации задумается: а стоит ли делать что-то большее, чем переименование метода.
Сизифов труд — вот во что превращается разработка через тестирование, когда тесты пишутся до написания кода или хотя бы по ходу дела. Любой грамотный разработчик рефакторит код в процессе его написания по мере того, как он все глубже разбирается в проблеме и понимает, как реализовать решение лучшим образом. Но если он пишет тесты одновременно с кодом, кроме изменений в коде ему приходится менять еще и тесты. А в отличии от рефакторинга готового кода, рефакторинг кода в работе обычно гораздо масштабнее, значит и требуемые изменения в тестах будут соответствующими. И так — много раз еще до того, как код уйдет на ревью. Половину рабочего времени в мусор — легко.
Количество тестов обманчиво: 3000 тестов в сумме — на веб-интерфейс, REST API, бизнес-логику и юнит-тесты — могут проверять с натяжкой 1000 ситуаций. Все остальное — дублирование.
Автоматическая регрессия не отменяет ручную вопреки главной задумке. Все потому что автоматические тесты проверяют много чего, но далеко не все. Но что конкретно они проверяют, а что нет — никто не знает. Нам нужно проверить регистрацию. А еще у нас есть 18 927 тестов. Если какой-то из них красный — «все хорошо», можно вернуть задачу к разработчикам — пусть разбираются. Если все тесты зеленые — это ничего не значит до тех пор, пока человек, отвечающий за ручное тестирование, не будет уверен, что из логики регистрации проверяется автоматически, а что все еще нужно проверить вручную. А тестов почти двадцать тысяч — в этом невозможно разобраться. Результат — проверить вручную нужно все.
Неудивительно что некоторые уходят из разработки продавать пластиковые окна, обучать бильярду или варить кофе (и это все реальные случаи).
О том, какие выводы мы в Wrike сделали из собственных и чужих ошибок, расскажу в следующем посте.
Департамент разработки,
Подразделение мержа в мастер,
Отдел работы с гит,
Ведущий оператор баш консоли 1 разряда