В данной статье пойдет речь о том, каких заповедей нужно придерживаться во время разработки автоматизированных тестов.
Заповедь №1: не нужно автоматизировать только по текущим тест-кейсам
Есть довольно-таки распространенное заблуждение о том, что вся автоматизация тестирования должна строиться исключительно на базе тест-кейсов.
QA-автоматизаторы оперируют только созданными тест-кейсами и превращают их в автоматизированные сценарии.
В таком подходе, конечно, можно уловить смысл, но если взять и другие методики проверки, то они тоже могут принести немало выгоды.
Если расширить термин автоматизации далеко за пределы «тест-кейс — инструмент — тестовый сценарий» до формулировки «продуманного использования технологий, с базовой целью помочь тестировщикам выполнять ежедневную работу», то можно применять технические мощности компьютеров под задачи, для которых они предназначены, а тестировщики пускай делают все остальное.
К большому счастью, во всех ситуациях, где люди молодцы, техника выступает плохо — ну и наоборот.
Заповедь №2: разработка автоматизации — это то же самое, что разработка программного обеспечения
Создание автоматизации — это и есть процесс по созданию определенного программного обеспечения. Даже если тестировщик просто использует самый легкий графический интерфейс для перетаскивания объектов из одного всплывающего окна в другое, где-то внутри системы за этими процессами стоит программный код.
Подход к процессу автоматизации по типу подхода по созданию ПО всего лишь означает, что автоматизатор должен учитывать массу процессов и типов профессиональной деятельности, которые требуются при создании ПО.
Например:
- Дизайн — нужно решить, что будет отображено в продукте, а что нет;
- Внедрение — стоит задача по написанию кода;
- Хранение — код должен где-то сохраняться;
- Тесты — автоматизацию, в любом случае, нужно тестировать — также, как мы тестируем ПО;
- Дефекты — и там и там есть и будут баги;
- Логи — если не разобрать их сущность, нам будет сложно понять, за что отвечает нами созданная автоматизация.
Заповедь №3: использование стандартов и идиом основ программирования
Кроме того, что обращаться с автоматизацией нужно по аналогии с процессом создания ПО, также не нужно забывать о процессах встраивания в ее структуру актуальных идей по ее последующему внедрению.
Любое программное обеспечение и язык программирования содержат свои «персональные» идиомы и тонкости, но общепринятые методы к процессу проектирования и имплементации, традиционно, пригодны для всего.
Заповедь №4: помните про поддержку и своевременное обслуживание
Нет программного обеспечения, которое можно было бы именовать самым идеальным и полностью завершенным. С автоматизацией дела обстоят так же. В ней постоянно будут ошибки!
С редактированием проверяемого приложения нужно будет менять и автоматизацию. Предотвратить подобное не в силах никто, но можно пробовать создавать ПО таким, чтобы максимально снизить затраты на его обслуживание.
Заповедь №5: сценарии автоматизации не должны зависеть друг от друга
Разработка тестового сценария, зависимого от итогов другого теста — очень мощный анти-паттерн.
Если тестовые скрипты зависят друг от друга, не нужно прогонять их по одиночке, и это весьма усложняет процесс отладки автоматизации и проблем ПО.
Дополнительно не рекомендуется запускать сценарии параллельно с теми, от которых они зависят.
Естественно, есть один граничный случай, когда все скрипты зависят от одного самого главного. Такой единичный скрипт может настраивать тестовое окружение и верифицировать тестовые данные.
При нынешних условиях автоматизации и постоянной развертки это очень большая редкость, но такой сценарий имеет право на жизнь в ситуации, когда используемые ранее фреймворки стали недоступны или попросту не подходят для оригинальной автоматизационной задачи.
Заповедь №6: внедрение только грамотных логов и тестовых отчетов
Грамотно построенные логи, итоги и сообщения о багах критично важны для осознания и поддержки уровня автоматизации на каждом проекте по отдельности.
Логи автоматизации — это, своего рода, детальный образ прогона каждого автотеста по отдельности: что и когда запускалось, что упало, а что смогло завершить работу корректно, какие выводы по итогу прогона можно сделать и прочее.
Естественно, если на стадии автоматизации было грамотно внедрено логирование, значит, в результате мы сможем получить нужную информацию по итогам, и, в конце концов, сможем проанализировать сильные и слабые стороны применения тех или иных основ автоматизации.
Заповедь №7: влиять нужно на тестируемость и автоматизируемость
Тестируемость и автоматизируемость — это не то, чем должны заниматься тестировщики по идее, но и они должны на них влиять. Осуществление такого влияния — задача первостепенная.
Программисты порой не знают, что тестировщикам нужно для проверки ПО, а что стоит передать для создания первоклассных автотестов.
Заповедь №8: остерегайтесь невозвратных задач
Порой, все из нас допускают ошибки и просчеты. Иногда это очень большие баги.
Мы должны извлекать максимум из предоставленной информации, которой располагаем в данный момент, но зачастую это может не сработать так, как нужно.
Если что-то пойдет не так, мы на инстинктах стараемся исправить ситуацию и будем это делать пока не достигнем приемлемого результата.
Но иногда нужно начать все с нуля, ибо рисковать временем и чужими деньгами — не практично.
Подобное принято именовать «ловушкой невозвратных затрат». Если очень кратко, ее суть заключается во мнении, что на проект была потрачена определенная сумма денег, что нужно будет потратить еще для реабилитации, чтобы постараться извлечь выгоду из уже потраченных и невозвратимых затрат.
Заповедь №9: долой хитроумные приспособления
Старайтесь даже не пробовать создавать то, что сложно поддерживать, нежели реализовывать такие задачи мануально.
Заповедь №10: тестовые данные не должны быть зависимыми от временных данных
Не стоит делать временных привязок, так как в один прекрасный день тестовый сценарий, который вы будете использовать, может попросту упасть, а это чревато поломкой большей части автоматизации.
А ситуации могут быть разными, и может случиться так, что починка такой мелочи как время может повлечь за собой нарекание со стороны менеджмента и недовольство клиента.
Оставить комментарий