Автоматизированное тестирование что это
Автоматизированное тестирование что это
Что такое автоматизированное тестирование?
Автоматизированное тестирование или автоматизация тестирования – это метод тестирования программного обеспечения, который выполняется с использованием специальных программных средств, которые, в свою очередь необходимы для выполнения набора тестовых примеров. Напротив, ручное тестирование выполняется человеком, сидящим перед компьютером и тщательно выполняющим каждый шаг теста «руками».
Программное обеспечение для автоматизации тестирования также может вводить тестовые данные в тестовую среду, сравнивать ожидаемые и фактические результаты и создавать подробные отчеты о тестах. Как правило, автоматизация тестирования требует значительных вложений денег и ресурсов.
Последовательные циклы разработки, особенно в крупных компаниях (Google, Facebook, Альфа-Банк, Газпром нефть и т.д.) потребуют многократного выполнения одного и того же набора тестов. Используя инструмент автоматизации тестирования, можно записать этот набор тестов и при необходимости воспроизвести его. После автоматизации набора тестов вмешательство человека не требуется. Это улучшило ROI автоматизации тестирования. Цель автоматизации – уменьшить количество тестовых примеров, которые нужно запускать вручную, а не полностью исключить ручное тестирование.
Какие тестовые случаи стоит автоматизировать?
В процессе автоматизации выполняются следующие шаги:
Выбор инструмента тестирования
Определяем объем автоматизации
На этом этапе выполняются сценарии автоматизации. Сценариям необходимо ввести тестовые данные, прежде чем они будут запущены. После выполнения они предоставляют подробные отчеты об испытаниях.
Выполнение может быть выполнено с использованием инструмента автоматизации напрямую или с помощью инструмента управления тестированием, который вызовет инструмент автоматизации.
Пример: Центр качества – это инструмент управления тестированием, который, в свою очередь, вызывает QTP для выполнения сценариев автоматизации. Скрипты могут выполняться на одной машине или на группе машин. Для экономии времени тестирование можно проводить ночью.
Обслуживание автоматизированного тестирования
Этот этап автоматизированного тестирования проводится для проверки того, как работают новые функции, добавленные в программное обеспечение: нормально или нет. Сопровождение в автотестировании выполняется, когда добавляются новые сценарии автоматизации, и их необходимо проверять и поддерживать, чтобы повышать эффективность сценариев автоматизации с каждым последующим циклом выпуска.
Приведенные выше рекомендации, если их соблюдать, позволят качественно выполнить автоматизацию тестирования.
Преимущества автоматизации тестирования
Инструменты автоматизации тестирования
На рынке доступно множество инструментов для функционального и регрессионного тестирования. В следующих выпусках расскажем в пользу чего делают выбор наши практикующие специалисты.
Это универсальный инструмент для автоматизации функциональных тестов пользовательского интерфейса, регрессионных тестов, тестов на основе данных и многого другого. Ranorex Studio включает простой в использовании интерфейс для автоматизации тестирования веб-приложений, настольных и мобильных приложений.
«Самый быстрый путь к отказоустойчивым сквозным тестам – без кода, с кодированием или и тем, и другим. Testim позволяет создавать удивительно стабильные тесты без кода, которые используют наш ИИ, а также гибкость для экспорта тестов в виде кода. Такие клиенты, как Microsoft, NetApp, Wix и JFrog, ежемесячно проводят миллионы тестов на Testim.
Это инструмент тестирования программного обеспечения, используемый для регрессионного тестирования. Это инструмент тестирования с открытым исходным кодом, который предоставляет возможность воспроизведения и записи для регрессионного тестирования. Селен IDE поддерживает только Mozilla Firefox веб – браузер.
Silk Test предназначен для выполнения функционального и регрессионного тестирования. Для приложений электронного бизнеса шелковый тест является ведущим продуктом для функционального тестирования. Это продукт поглощения Segue Software компанией Borland в 2006 году. Это объектно-ориентированный язык, как и C ++. Он использует концепцию объекта, классов и наследования. Его основная особенность включает
Правильный выбор инструмента автоматизации, процесса тестирования и команда – основные составляющие успеха автоматизации. Для успешного тестирования ручные методы и автоматизация идут рука об руку.
Автоматизация тестирования с нуля. Часть 1
Добрый день, уважаемые читатели.
Хочу рассказать об опыте построения системы автоматизации тестирования, когда на проекте или совсем нет тестирования, или ее степень минимальная.
Надеюсь статьи будет полезна начинающим автотестерам.
Когда делать автотесты?
Краткий ответ — как можно раньше.
А полный будет раскрыть ниже. В любом случае, когда проект работает 3 года, и все проверялось вручную, жить становится очень монотонно. И парк из 5000 сценариев автоматизировать за месяц-два проблематично. Как правило в таких проектах придется начинать прорабатывать сценарии заново. Потому что это окажется быстрее. И не факт, что старые получится автоматизировать без существенных изменений.
Почему?
Потому что автотетсы:
Накопленные сценарии
Чем больше парк автоматизированных сценариев, там больше вероятность найти регрессию, особенно если при каждом запуске данные изменяются.
Если автотест проходил стабильно и на какой-то ветке упал, то или меняли требования, или баг, или инфраструктура подвела.
Непредвзятость
Если меняли требования — автотест должен отправиться на переделку вместе с переделкой основного функционала. Именно поэтому тестировщики принимают участи в согласовании ТЗ.
Если прогон теста автоматически линкуется к задаче, то никто не сможет сказать, что это не тестировалось. Или наоборот, сможет. В общем проблем точно становится меньше.
Скорость
Если каждый тест удовлетворяет занудным условиям:
Предусловие — Тест — Постусловие
То такие тесты легко автоматизировать.
А потом легко распараллелить. Потому что они получаются независимыми.
Количество потоков — сколько выдержат тестовые сервера и чтобы не мешать другим.
Второй момент это сама по себе скорость. В ручном режиме прокликать создание товара, его поиск и покупку в интернет магазине это 5 минут. 4 браузера. Итого 20 минут. На всего лишь одном небольшом сценарии.
Автотест по этому сценарию проходит за 1,5 минуты. Но на 8 браузерах. (Последняя и предпоследняя версии каждого браузера).
С чего начать?
С пользовательских сценариев.
Ценность атомарных тестов все время падает, особенно на микросервисах. И вообще, в идеальном мире это зона ответственности программиста. Такие ошибки должны быть обнаружены на этапе юнит-тестирования.
QA должен работать от user story. Потому что программист обычно и не знает ее, и не хочет знать.
Соответственно логика 1 тест — 1 пользовательский кейс (бизнес сценарий) наиболее приближена к реальности.
Есть конечно сложности с подготовкой данных, например в случае интернет-магазина процесс оплаты картой требует наличия вещей в корзине, и или данных для нового пользователя, или данных авторизации существующего.
Да, иногда предусловия занимают больше времени, чем тест, но при переиспользовании сценариев сложности не несет.
Какие сценарии автоматизировать
Наименее подверженные изменениям в ближайшей перспективе. Чтобы автоматизация хоть сколько-то прожила.
Или наиболее часто используемые. Есть смысл помогать ручному тестированию в генерации тестовых данных. Например в доске объявлений есть смысл автоматизировать создание объявлений, т.к. далее любой сценарий требует созданного объявления.
Что конкретно делать?
Обычно в проектах есть
Поэтому предлагаю заняться Бэкэндом и Фронтом.
Выбираем сценарий
Допустим, у нас есть интернет-магазин.
Есть админка, есть клиентский и админский фронт.
Есть API, которое все это обслуживает.
С чего начать автоматизацию?
Есть клиенты, есть сотрудники.
У клиента первый кейс — просмотр и поиск товара, добавление его в корзину, и оформление.
У сотрудника самый распространенный кейс — добавление карточки товара.
Какой кейс автоматизируем первым? И как?
Самое важное для магазина — продажи.
Поэтому клиентская история наиболее важна для бизнеса. Поэтому найти товар, поместить в корзину и завершить оформление с любым способом оплаты это первое, что нужно сделать.
По API. Но без фронта. Тут можно поспорить, но скорее всего дизайн поменяется 2-3 раза еще, а вот бэкэнд вряд ли. Так что на 1 этапе придется интерфейс проверять вручную.
Далее сделать проверки на API редактирования карточки товара и ее фронт.
И вернуться к клиентскому. На этом этапе уже будет статистика наиболее частых действий пользователей, и наиболее частых путей клиента. Да, Яндекс Метрика и Вебвизор помогают и тестировщикам.
Нет никакого смысла на первом этапе проверять, работает ли функция оплаты на счет фирмы через сгенерированную платежку, если этой функцией пользуется 0,5% посетителей. Конечно можно задать менеджеру вопрос зачем это тут нужно, но тут не об этом.
Допустим у нас 40% человек платят на сайте картой, 30% наличкой, 20% наложенным платежом и 10% все остальные способы.
Какой тип оплаты будем проверять первым? Конечно картой.
То есть мы должны четко представлять, какой сценарий самый важный для бизнеса в данный момент. И его качество обеспечивать в первую очередь.
Постусловия
Мы насоздавали всего-всего в тестах. Намусорили. Надо бы за собой убрать. Нужно заранее предусмотреть, в каких тестах мы будем за собой убирать, а в каких — нет.
Если товар можно оставить в магазине, и ничего страшного не произойдет, то добавление прав администратора обычному пользователю нужно вернуть. А то следующий тест, связанный с правами может упасть. Или хуже — пройти позитивно, хотя должен был упасть.
Странности
Есть странный подход, когда автоматизируют сценарии, в которых пользователи находили баг. Обычно это очень экзотические сценарии, и тратить ресурс на них нет смысла. Была ситуация когда сломался функционал обновления данных банка-контрагента. Сбоила синхронизация со справочником БИК.
То есть новый БИК не обновлялся. Но новый банк заводился нормально.
Есть ли смысл автоматизировать этот сценарий? Если контрагенты меняются каждый день — может быть. И тогда это была недоработка планирования.
Если это делается 5-6 раз в год, то может лучше более приоритетной задачей заняться?
Что будет дальше?
В следующей статье я расскажу как быстро начать тестировать API, встроить эти тесты в релизы, распараллелить тесты, как подбирать данные для тестов и что нам это даст.
Напомню про эффект пестицида, и как его свети к минимуму.
Технологии: Java + maven + testng + allure + RestAssured + Pict.
Зачем нам нужно автоматизированное тестирование?
Автоматизация — один из лучших способов проверить, насколько хорошо работает текущее программное обеспечение по сравнению с его предыдущими версиями. Иными словами, автоматизация — это обнаружение регрессий и обкатка различных вводов. До тех пор, пока не появится возможность писать автоматизированные скрипты для вашего приложения, множество ошибок, которые могут быть обнаружены в процессе написания скриптов, уже будут успешно найдены и устранены.
Многие ошибки, связанные с автоматизацией, обнаруживаются во время непосредственного написания автоматизированных скриптов. Во время непосредственного осуществления автоматизации может быть обнаружено лишь несколько новых программных ошибок, хотя ошибки могут быть найдены при выполнении автоматизации в различных конфигурациях или через наборы данных.
Тем не менее, автоматизация ассоциируется с управлением, поскольку она позволяет сэкономить время, уменьшить количество используемого оборудования, ресурсов и тестировщиков ПО, которые привлекаются компанией по тестированию программного обеспечения для получения высококачественного продукта. Для многих проектов автоматизации трудно определить, что от них ожидалось, поскольку те, кто выполняет автоматизацию, не понимают, что автоматизация — это просто еще один инструмент, который можно использовать для тестирования программного обеспечения.
Автоматизированное тестирование в большей или меньшей степени используется почти в каждом проекте. Оно не дает никаких гарантий и не защищает продукт от плохой работы, в то время как тестирование программного обеспечения влияет на повышение качества продукта. Плохо реализованная автоматизация в конечном итоге будет стоить больше времени и усилий, чем ее отсутствие. Тем не менее, если ее реализовать, она принесет значительные выгоды. Необходимо понимать, что автоматизация нужна только для того, чтобы оценивать регрессии и быть «monkey tester», что не означает выполнение одного и того же теста каждый день одним и тем же способом. Не обращая внимания на эту задачу, тестировщики ПО могут выполнять простые действия и использовать свои творческие и интеллектуальные способности для поиска новых ошибок.
Только 5-20% всех ошибок программного обеспечения обнаруживаются во время автоматизированного регрессионного тестирования. Учитывая тот факт, что автоматизация тестовых случаев может быть в 10 раз дороже, чем их ручное выполнение, без учета поддержки и сопровождения тестового кода, тестовые случаи для автоматизации следует выбирать очень тщательно.
Чтобы стать хорошим автоматизатором, нужно знать не только языки программирования и фреймворки для автоматизации, но и теорию тестирования. На двухдневном онлайн-интенсиве мы узнаем, что такое тестирование и откуда оно появилось, кто такой тестировщик и что он делает. Изучим модели разработки ПО, жизненный цикл тестирования, чек листы и тест-кейсы, а также дефекты. На втором занятии познакомимся с одним из главных трекеров задач и дефектов — Jira, а также попрактикуемся в TestIT — отечественной разработке для решения задач по тестированию и обеспечению качества ПО. Присоединяйтесь!
Автоматизация тестирования: минусы
Автотест (автоматизированный тест) – это скрипт, имитирующий взаимодействия пользователя с приложением, цель которого – локализация ошибок в работе программного обеспечения.
Конечная цель автоматизации тестирования представляет собой некий набор автотестов, которые, при нажатии на кнопку «GO!», будут поочередно запускаться. Ну или всегда можно запустить какой-либо автотест отдельно, если для этого есть необходимость. Каждый такой скрипт проверяет правильность работы определенной части приложения и фиксирует ошибки в случае, если что-то работает не так.
О том, насколько выгоднее использовать автоматизированное тестирование чем ручное, а так же о плюсах автоматизированного тестирования хорошо написано в этой статье. Я же хочу описать возможные проблемы, с которыми может столкнуться тестировщик, решивший использовать автоматизированные тесты.
Отбор тестов для автоматизации
Стоимость
Далеко не всегда оказывается, что разработка и сопровождение автоматизированных тестов будет дешевле ручного тестирования. Необходимо потратиться на среду разработки, системных администраторов, наем программистов, их информационную поддержку (имеется ввиду поддержка при возникновении вопросов относительно тестируемой системы и тест кейсов), обеспечить им рабочие места. Все это выльется в немалую сумму и окупится только при тестировании больших систем, когда есть возможность автоматизировать довольно большое количество тестов. После разработки скриптов их нужно кому-то запускать и анализировать результаты. Не получится проводить тестирование по схеме «запустил – подождал – получил конечный результат». Нужен человек, который сможет анализировать выполнение автотестов: определять, нужно ли отправлять тест на доработку, действительно ли существует ошибка, найденная автотестом, подготавливать данные для тестирования. На подготовку среды для разработки, саму разработку уйдет масса времени.
Отдельная статья расходов на автоматизацию – это поддержка автотестов.
Поддержка
Автотесты всегда требуют поддержки. Так как написание автотестов – это программирование, то чтобы изменить\исправить логику автотеста нужно лезть в исходный код. Для этого нужно нанимать дополнительных специалистов, которые будут сопровождать написанные скрипты. Это новые расходы, без которых не обойтись и которые значительно повышают стоимость автотестов. Есть 2 основных случая, при которых может понадобиться вмешательство в исходный код:
1. Изменение входных данных к тесту
Хорошо, если при выполнении нескольких итераций тестирования приложения можно всегда подавать автотестам на вход одни и те же данные. Например, проверка занесения записи в базу данных, или проверка открытия какого-либо меню, где входные данные вообще не требуются.
Но бывает и так, что перед каждым запуском автотестов данные нужно готовить заново. При большом количестве тестов подготовка входных данных может занять много времени. Например, при тестировании банковской системы могут потребоваться счета в рублях, долларах, евро; счета с разными суммами, принадлежащими как физическим лицам, так и организациям. После прогона серии автотестов на всех счетах может остаться нулевой баланс, некоторые из них будут закрыты, некоторые заблокированы. При последующем тестировании необходимо будет использовать другие счета. В некоторых случаях данные могут быть хардкодом прописаны в скриптах автотестов, и происходить это может не из-за того что разработчику было лень сделать свой скрипт более гибким, а просто потому что такого хардкода требовал тест кейс. Через некоторое время тест кейс изменится (например название банка изменится с «хабрабанк» на «хабракредитбанк»), и потребуется изменение скрипта.
2. Изменение функционала
В обоих случаях многое зависит от разработчиков: процесс написания автотестов требует не меньших знаний и усилий чем процесс создания любого другого ПО. Следовательно, тут проявляются все проблемы, связанные с разработкой: сложность контроля качества и надежности, перенос сроков, изменение бюджета и многие другие.
И всё-таки
Эти минусы не означают, что нужно избегать автотестов любой ценой. От них тоже есть польза.
Как видно из графика, использование автоматизации дает лучшие результаты при тех же затратах. Но, еще раз повторюсь, эти результаты будут лучшими только при автоматизации тестирования больших проектов.
Процесс автоматизированного тестирования за 10 шагов
Во многих организациях качество является главным приоритетом. Если вы окажетесь в такой организации, но в ней все еще не будет формального процесса автоматизации тестирования, вы можете стать тем человеком, который его внедрит.
С ним ваша организация сможет создавать более качественные продукты за меньшее время и соответственно раньше будет выводить их на рынок.
В третьей части «Руководства по автоматизации тестирования», я расскажу вам о том, что такое процесс автоматизации тестирования и как начать автоматизацию тестирования в вашей организации. Важно понимать, какой шаг нужно сделать первым и почему.
Выполнение этих шагов поможет вам внедрить автоматизацию без проблем и позволит избежать распространенных ошибок, которые приводят с сбоям автоматизации.
10 шагов на пути к внедрению автоматизации тестирования
В этой статье процесс автоматизации тестирования представлен пошагово, поэтому вы получаете руководство, которое поможет вам внедрить автоматизированное тестирование.
Шаг 1. Убедите руководителей
Независимо от того, насколько вам хочется внедрить автоматизацию тестирования в вашей организации, вы ничего сможете сделать, если руководство не видит в нем преимуществ. Все знают, что автоматизация тестирования – это дорого. Инструменты – это дорого (лицензия HP QTP/UFT стоит около 8 тысяч долларов на машину). Есть и стоимость работы архитектора или инженера по автоматизации (которая, кстати, тоже немалая). После всего этого преимущества автоматизации тестирования уже не кажутся такими очевидными. Должно пройти 2-3 месяца, прежде чем скрипты будут готовы, проверены и будут хорошо работать, а только после этого вы сможете начать тестирование вашего приложения.
Вам нужно убедить руководство, что нужно понести все эти расходы и подождать, прежде чем автоматизация тестирования выдаст какой-то результат.
Так как же их убедить? Вам нужно показать им анализ рентабельности. Например, вы можете задаться вопросом, сколько вы тратите на тестирование BAT (Build Acceptance Testing) вашего приложения? Если оно занимает день, то вы сможете сказать, что с автоматизацией тестирования сможете протестировать его за 2 часа. Стоимость будет состоять из приобретения инструментов, обучения персонала и ожидания результатов в течение двух месяцев. Через два месяца мы сможем проводить BAT за два часа. Каждый раз при выпуске нового билда вы будете экономить 6 часов. Если билд выпускается 4 раза в месяц, то вы сэкономите 24 часа или 3 рабочих дня ручного тестирования!
Тем не менее, это не значит, что ручные тестировщики не будут ничего делать. Они используют свои 6 освободившихся часов, чтобы сосредоточиться на новых и важных функциях приложения, в то время как автоматизация позаботится о задачах регрессии. Такая установка в целом улучшит качество продукта в десятки раз.
Если ваше руководство не готово платить за качество своей продукции, то никто не заставит его это сделать. Они поймут это сами, когда клиенты будут жаловаться на продукт. Качество влияет на все. Оно влияет на ваши продажи, на ваши отношения с клиентами, на восприятие вас в глазах пользователей. Таким образом, грамотное руководство всегда будет инвестировать в качество своих продуктов.
Итак, пять пунктов, которые нужно запомнить, чтобы убедить свое руководство:
Подробно расскажите им о преимуществах автоматизации тестирования.
Скажите, что автоматизация тестирования как таковая – это дорого, и по началу будет стоить много, но затем стоимость будет снижаться, когда скрипты будут готовы и начнут работать.
Скажите им, что нужно будет подождать около трех месяцев, прежде чем появится какой-то результат от автоматизации тестирования.
Расскажите, что автоматизация тестирования не имеет целью заменить ручных тестировщиков, а наоборот помогает им, поскольку вместе они могут покрывать большие объемы задач.
Автоматизация тестирования — не значит увеличение объемов тестирования и уменьшение количества времени, затраченного на него, она значит, что вы сможете делать больше задач одновременно. (Если ручные тестировщики проводили BAT за 8 часов, теперь они смогут протестировать BAT и другой функционал за те же 8 часов при наличии автоматизации.)
Помните, что убедить руководство – это самый первый и самый важный шаг на пусти внедрения автоматизации тестирования в вашей организации. Если они не будут уверены в целесообразности, то про вашу идею с внедрением автоматизации можно забыть или уйти в другую организацию 🙂
Шаг 2: Поиск экспертов по работе с инструментами автоматизации
Есть два вида экспертов по автоматизации:
Архитекторы по автоматизации
Инженеры по автоматизации
Архитектор по автоматизации – редкий зверь. Их непросто найти, они дорого стоят, но при этом они крайне необходимы для успеха проекта автоматизации. Эти специалисты обычно отвечают за создание систем автоматизации. (Фреймворки автоматизации мы подробно обсудим в отдельной статье).
Архитекторы по автоматизации работают с различными инструментами и обычно знают сильные и слабые стороны каждого из них. Такой специалист может помочь руководству выбрать правильный инструмент для автоматизации, тщательно проанализировав приложение и технологии, используемые для его создания. Также они могут построить фреймворк, разработать соглашение об именовании и правила для скриптов. Архитекторы по автоматизации помогут выбрать какие тест-кейсы автоматизировать в первую очередь.
Если вы найдете правильного человека на должность архитектора по автоматизации, то уже полдела по внедрению автоматизации тестирования будет сделано.
С другой стороны, появятся инженеры по автоматизации – это люди, которые переводят ручные тест-кейсы в автоматизированные скрипты. Они будут работать под руководством архитектора автоматизации и будут отвечать за создание и выполнение скриптов.
Одни компании нанимают инженеров по автоматизации извне, а другие воспитывают самостоятельно, обучая ручных тестировщиков. Как бы то ни было, человек должен хорошо владеть программированием. Он/она должны хорошо знать ООП. Команда из одного архитектора по автоматизации и двух инженеров по автоматизации отлично подойдет для работы над большинством продуктов.
Шаг 3: Использование правильного инструмента для автоматизации
Этот шаг заслуживает отдельной статьи (и позже я ее напишу). Он является сложным этапом в процессе внедрения автоматизации. Рынок изобилует различными инструментами, но вам нужно выбрать те, которые будут лучше всего подходить для вашего приложения.
Короче говоря, в этом пункте я опишу самые важные мысли о выборе инструмента. Процесс выбора инструмента я подробно распишу в отдельной статье.
Наиболее важные аспектами, которые следует учитывать при выборе правильных инструментов:
Инструмент должен отвечать вашему бюджету. Средства автоматизации – это дорого. Поэтому у компании под них должен быть заложен бюджет.
Инструмент должен поддерживать технологии, используемые в вашем приложении. Если в нем используется Flash или Silverlight, инструмент должен их поддерживать. Если ваше приложение работает на мобильном устройстве, инструмент должен уметь выполнять скрипты на нем. Вы можете приобрести один инструмент, поддерживающий все технологии, используемые в вашем приложении, или приобрести отдельные инструменты под каждую технологию. Например, для веб-приложений вы можете использовать Selenium, для приложений на Android взять Robotium, а MS Coded UI для десктопных приложений. Каким бы ни было решение, оно должно вписываться в ваш бюджет.
У вас должны быть все необходимые квалифицированные специалисты, которые умеют пользоваться этим инструментом или могут изучить его в кратчайшие сроки. Например, если вы наняли архитектора по автоматизации, у которого есть только опыт работы с QTP, и покупаете лицензию MS Coded UI, то специалист может работать неэффективно. Инструменты – это как хорошие автомобили, но у вас должны быть хорошие водители, чтобы водить их.
У инструмента должен быть хороший механизм генерации отчетов, чтобы можно было показать результаты работы заинтересованным сторонам.
При выборе инструмента нужно учитывать и другие факторы, о которых мы подробно поговорим в отдельной статье.
Шаг 4: Анализ различных приложений и определение тех, которые лучше подходят для автоматизации
Если ваша организация работает над 5 приложениями, нет необходимости автоматизировать каждое из них. Вам нужно учитывать различные факторы при выборе приложения для автоматизации.
Приложение, которое нужно автоматизировать, должно обладать следующими факторами:
Приложение не должно находиться на ранних стадиях жизненного цикла. (В приложении все или основные модули должны работать стабильно и уже быть протестированы вручную.)
Пользовательский интерфейс приложения должен быть неизменным. (Он не должен часто меняться.)
Ручные тесты для этого приложения должны быть задокументированы.
Основная цель автоматизации состоит в том, чтобы убедиться, что если в одном билде нет каких-то определенных ошибок, то их не должно быть и в следующем. Ручной тестировщик не должен тратить свое время на поиск регрессионных проблем, они должны быть выявлены с помощью автоматизации.
Таким образом, чтобы обнаружить регрессию, нам нужно стабильное приложение и несколько собственных тест-кейсов. Команда автоматизации преобразует эти тест-кейсы в скрипты и будет запускать их при каждой сборке, чтобы убедиться, что регрессия не появляется.
Шаг 5: Обучение команды
После выбора инструмента и найма необходимых специалистов, следующим шагом должно быть их обучение.
Если ручные тестировщики превращаются в инженеров по автоматизации, они должны знать терминологию и концепции автоматизации. Если архитектор по автоматизации нанят извне, он должен получить информацию о тестируемом продукте, существующем процессе ручного тестирования и о том, что от него ждет руководство.
Дайте сотрудникам некоторое время, чтобы опробовать различные подходы, пока они, наконец, не придумают выигрышную стратегию автоматизации. Обучите их инструментам, которые организация уже использует для отслеживания ошибок и управления требованиями.
Хорошая подготовка и коммуникация между ручными тестировщиками, разработчиками и командой автоматизации действительно необходимы.
Шаг 6: Создание фреймворка автоматизации тестирования
Самая большая задача для архитектора по автоматизации – это разработать фреймворк автоматизации, который должен поддерживать автоматизированное тестирование в долгосрочной перспективе.
Фреймворк автоматизации – это набор правил и тщательное планирование скриптов, которые нужны, чтобы уменьшить количество требуемого обслуживания. Если что-то меняется в приложении, скрипты практически не нужно менять, чтобы удовлетворить этим изменениям. В этом и заключается прелесть системы автоматизации.
Есть пять типов фреймворков автоматизации: линейный, модульный, управляемый данными, управляемый ключевыми словами и гибридный. Все эти фреймворки с примерами мы подробно рассмотрим в отдельной статье этой серии.
Вы можете узнать больше о фреймворках автоматизации из следующих источников:
Шаг 7: Разработка плана выполнения
План выполнения подразумевает под собой выбор среды, в которой будут выполняться скрипты. Среда включает в себя операционную систему, браузер и различные аппаратные конфигурации.
Например, если тест-кейс требует проверки веб-сайта в трех браузерах, а именно Chrome, Firefox и IE, то команда автоматизации напишет скрипт таким образом, чтобы он мог выполняться в каждом браузере.
Об этом всегда следует упоминать перед тем, как писать скрипты, потому что тогда команда автоматизации обязательно об этом позаботится. В плане выполнения также нужно указать, кто будет выполнять их. Обычно команда автоматизации выполняет скрипты на каждой сборке, но тут все зависит от компании. Некоторые менеджеры поручают разработчикам выполнить скрипты на сборке перед релизом, а в некоторых компаниях даже есть отдельная команда, которая их выполняет. Также какие-то компании запускают скрипты в автоматическом режиме, на что, конечно, требуются дополнительные ресурсы.
Шаг 8: Написание скриптов
Когда фреймворк готов, план выполнения утвержден, а специалисты обучены работе с новым инструментом, самое время начинать писать скрипты.
Скрипты должны писаться организованно с применением соглашения об именовании. Исходный код должен храниться в системе управления версиями, чтобы не потеряться. Должен присутствовать контроль версий и история изменений. Автоматизация тестирования похожа на разработку программного обеспечения. При написании скриптов нужно учитывать все лучшие практики программирования.
Шаг 9: Отчеты
Функция создания отчетов обычно предоставляется инструментом. Но мы можем создать собственные механизмы генерации отчетов, например, отправлять результаты тестирования по электронной почте руководству автоматически.
Мы можем создавать отчеты после каждого выполнения в виде диаграмм и таблиц, если это необходимо руководству. Руководство всегда должно быть проинформировано о покрытии тест-кейсами, то есть о том, какие ручные операции охвачены автоматизацией, а какие так и остались ручными.
Шаг 10: Обслуживание скриптов
Если вы следуете лучшим практикам программирования и используете хороший фреймворк, то техническое обслуживание не должно стать проблемой.
Техническое обслуживание обычно необходимо, когда есть потребность в изменении приложения. Скрипты нужно обновлять, чтобы учесть изменения в коде и обеспечить безупречное выполнение.
Например, если раньше вы с помощью скрипта вводили текст в текстовое поле, а в новой версии приложения это текстовое поле стало выпадающим списком, то скрипт необходимо немедленно обновить.
Другие изменения могут возникнуть, если раньше ваши скрипты работали на английской версии приложения, а теперь их нужно менять, поскольку приложение будет поддерживать и китайский. Ваш фреймворк должен позволять вам обновлять скрипты без особых усилий, чтобы ваше приложение хорошо работало и на китайском! Именно поэтому архитекторы по автоматизации стоят дорого. 🙂
Если фреймворк получился не очень хорошим, а лучшие практики не используются, то техническое обслуживание станет вашим кошмаром. Большинство проектов по автоматизации терпят неудачу из-за плохого обслуживания наборов скриптов.
Заключение
В этой статье мы поговорили о том, что такое процесс автоматизированного тестирования и как шаг за шагом ввести практику автоматизированного тестирования в вашей организации. Если вы сможете выполнить все эти шаги, надеюсь, что у вас получится успешно внедрить автоматизацию.
Есть некоторые моменты (например, выбор инструментов автоматизации и фреймворков), о которых можно написать отдельные статьи. В следующих руководствах по автоматизации тестирования мы их обязательно рассмотрим.
Я постарался охватить все аспекты и использовал свой собственный опыт для написания этой статьи.
Если вы считаете, что я упустил что-то важное или какая-то часть этой статьи нуждается в дополнении, расскажите об этом в комментариях.