Изучите наиболее распространенные причины выхода из строя фреймворков автоматизации тестирования
За последние пять лет я имел удовольствие поддерживать и строить ряд фреймворков автоматизации для множества компаний. У каждой структуры был свой собственный набор проблем и преимуществ. Некоторые процветали, некоторые терпели неудачу.
Я многому научился из каждого своего опыта автоматизации, будь то лучшая практика или понимание шаблона, которого следует избегать (подробнее об этом см. В моей статье Анти-шаблоны JavaScript). На протяжении всего этого я отмечал ряд событий, которые, кажется, предсказывают отказ автоматизации.
Следующие пункты - это то, что я бы назвал наиболее распространенными ошибками, которые делают инженерные отделы при написании новых фреймворков автоматизации. Я нашел время, чтобы рассказать о том, что вы можете сделать, чтобы убедиться, что ваш фреймворк построен наилучшим образом, чтобы избежать этих ошибок.
1. Неправильный материал
Один из наиболее распространенных предикторов сбоя автоматизации - это неспособность обслуживать структуру с правильными знаниями или талантом. Часто недостаток технических знаний сочетается с фундаментальным недостатком знаний о структуре, что приводит к полному нарушению ремонтопригодности.
Я работал в компании, которая внедрила решение для автоматизации, не изучив должным образом, как использовать фреймворк и что он может предоставить. Магазин решил использовать Cypress.io, но предпочел использовать его скорее как средство запуска тестов, чем как комплексное решение для автоматизации. Вместо использования встроенной библиотеки запросов они решили использовать SDK. Вдобавок они написали сложные рабочие процессы в стиле Java, вызываемые cy.task(), вместо использования команд Cypress.
Дело не в том, что они ошиблись в своем дизайне - фреймворк подошел бы для сочетания Java и Selenium. Проблема в том, что они выбрали фреймворк JavaScript и реализовали решение Java.
Я потратил месяцы на рефакторинг, пытаясь приспособить фреймворк к самому Cypress. На самом деле, я, к сожалению, никогда не писал новых тестов для этой компании. Я потратил все мое пребывание на рефакторинге предыдущей работы, чтобы она была близка к завершению. Рамки были просто нарушены с самого начала - все из-за невозможности должным образом исследовать и проверять продукт.
Вместо того, чтобы выбирать фреймворк, потому что он кажется привлекательным, исследуйте предлагаемый продукт. Убедитесь, что фреймворк соответствует вашим потребностям. Проверьте его репозиторий на GitHub и изучите вкладку «Проблемы». Считайте это красным флагом, если какая-либо из поднятых проблем может повлиять на то, как вы тестируете свое приложение, например, Cypress не обрабатывает окна, когда вы знаете, что ваше приложение использует сторонние интеграции.
Самое главное, проявите должную осмотрительность. Намерение состоит в том, чтобы эта структура стала краеугольным камнем вашего процесса сборки.
2. Написание тестируемого кода
Одним из наиболее важных элементов построения успешной среды автоматизации является наличие приложения, которое легко тестировать. Есть множество инженерных мастерских, которые не рассматривают влияние программирования на тестирование. Эта цитата из книги Уроки, извлеченные при тестировании программного обеспечения достаточно хорошо резюмирует¹:
«Дело не в том, что они не заботятся о тестировании или качестве. Вероятно, они просто не понимают, какое влияние их действия оказывают на процесс тестирования ».
Проще говоря, не все инженерные команды разрабатывают идею автоматизации тестирования во главу угла. Это создает приложение, которое может быть трудно протестировать (или, в некоторых случаях, устойчивое к тестированию). Это может принимать форму зависимости от хрупких критериев селектора (неуникальные селекторы, такие как класс, идентификатор и xPath), ненадежной производительности приложения и отсутствия инструментов, ориентированных на качество, таких как метод API для удаления тестовых данных.
Если вы обнаружите, что ваш магазин не занимается программированием с учетом автоматизации тестирования, постарайтесь вместе с разработчиками выяснить, почему это проблема и как вы можете ее решить в команде. Медленно (но вдумчиво) работайте над тем, чтобы сделать ваш код более тестируемым с каждой проходящей итерацией, вводя такие концепции, как уникальные критерии выбора (data-id, data-testid или data-cy) или методы API с поддержкой контроля качества.
Выступайте во время встреч по разработке, планированию и подготовке (если вы работаете на основе Scrum) и обращайте внимание на то, насколько сложно протестировать функцию. Постарайтесь сформулировать решения, которые помогут упростить задачу как с точки зрения пользователя, так и машины.
Как арбитры качества программного обеспечения, мы должны гарантировать, что мы отстаиваем код, который написан с учетом автоматизации, чтобы уменьшить количество случаев, в которых элементы трудно автоматизировать .² В результате будет создано приложение, которое легко тестировать. как человеком, так и машиной, тем самым обеспечивая успех нынешним и будущим попыткам автоматизации.
3. шарить в темноте
Я хотел бы быть прозрачным и отметить, что я лично виноват в создании фреймворка автоматизации вне CI. На самом деле, я обратил внимание на то, что это довольно распространенное явление при создании новых фреймворков автоматизации. Основная проблема при построении фреймворка за пределами CI заключается в том, что неудачные запуски автоматизации не имеют последствий.
Неудачные сборки CI должны выступать в качестве катализатора для принятия мер как разработчиками, так и QA. Когда автоматизация выполняется за пределами CI, вероятность того, что ускользнет от него, попадет в промежуточную среду, среду проверки или производственную среду, экспоненциально выше. Это связано с тем, что работа за пределами CI ограничивает видимость и контроль. Только инженер, запустивший цикл, знает, что тест не удался. Тем временем остальная часть команды остается в неведении.
Почему бы просто не сообщить команде?
В CI у вас есть отчет с сообщениями об ошибках, журналами и другими критериями, которые помогают инженеру обосновать свое мнение о том, почему сбой должен быть устранен. Неудачный запуск за пределами CI не дает такой роскоши. Конечно, вы можете создать отчет о запуске, используя такой инструмент, как Allure, или такой пакет, как Pytest-HTML. Однако сборки CI позволяют автоматически передавать отказы всей команде, особенно через чат-приложения, такие как Slack.
Не нажимайте« Сохранить - комикс: он работает на моем компьютере»
Вчера вечером я видел концерт Louis CK вживую. Чертовски хороший материал. Этому парню стоит серьезно подумать о карьере в комедии… donthitsave.com »
Кроме того, существует давняя проблема «это работает на моей машине», как видно из комикса выше.
Локальный запуск автоматизации следует рассматривать как локальную сборку приложения. Тот факт, что он передается на вашу машину, не означает, что он пройдет в CI. Всегда проверяйте, проходят ли ваши пробежки в обоих случаях. Если нет, то вы должны исследовать сбой и определить следующие шаги.
4. Фанатичная автоматизация
Вы когда-нибудь работали в магазине автоматизации, который стремился автоматизировать все?
Идея автоматизации тестирования состоит в том, чтобы взять серию задач с высокой повторяемостью и передать их компьютеру. Такие задачи, как выбор одного фильтра из 20, отмена этого выбора, а затем выбор следующего фильтра. Выполненное вручную, поведение стало бы однообразным и утомительным. Это приводит к утомлению тестировщика, что может привести к побегам. В попытке снизить утомляемость тестировщиков и убедиться, что нас не раздавят под тяжестью ручного тестирования, мы автоматизируем серию задач.
Однако есть магазины, которые доводят это до крайности. Руководство нанимает инженера по качеству с опытом автоматизации и немедленно хочет автоматизировать каждый тестовый пример. К сожалению, 100% автоматизация не является достижимой целью. Основная причина в том, что автоматизация не может заменить ручное тестирование. Ручное тестирование нам так же необходимо, как и автоматизация - в настоящее время два метода тестирования неразделимы.
Так почему же так много магазинов хотят это сделать? Непонимание того, что может обеспечить автоматизация.
Для многих идея автоматизации означает конец вручную проверенных скриптов. Магазину больше не нужно беспокоиться о выполнении ручных тестовых примеров - теперь это может сделать компьютер.
Вместо того, чтобы стремиться писать автоматизацию для всего, мы должны тщательно выбирать, когда автоматизировать, и вручную тестировать, когда это невозможно.
5. Языковые вопросы
Однажды я фанатично подошел к вопросу о однородности языка между качеством и разработкой, построив платформу автоматизации на Clojure. Наши разработчики писали на Clojure и Clojurescript, поэтому я счел уместным с точки зрения качества писать и на Clojure.
Мы нашли средство для выполнения тестов (Kaocha) и веб-драйвер (Etaoin) и приступили к работе. Проект был успешным в течение нескольких недель, прежде чем была определена точка отказа: и веб-драйвер, и средство выполнения тестов обслуживались одним разработчиком, соответственно. Если какой-либо из разработчиков отвлечется от своего соответствующего проекта, наша структура может выйти из строя.
Какой урок я извлек?
Выбор языка программирования имеет значение при создании фреймворка автоматизации - то, что я не учел при выборе Clojure. В то время я хотел максимально тесно соединить качество и развитие. Я не думал, что сообщество автоматизации Clojure будет таким маленьким или что предложения по тестированию будут такими редкими. Я просто хотел совместить качество с развитием, чтобы упростить переход влево.
Я испытал это еще раз в другом магазине, хотя я подошел к выбору языка более тщательно и вдумчиво. Магазин изо всех сил пытался поддерживать стареющий фреймворк Ruby, который был разработан несколько лет назад. Мне было поручено провести аудит фреймворка и выбрать дальнейший путь, будь то рефакторинг или переписывание.
При поддержке инженерного менеджмента я и более старшие инженеры по качеству решили переписать с использованием Python, несмотря на очевидное желание использовать Cypress. Мы выбрали Python, так как он синтаксически похож на Ruby и его будет легче изучить нашим младшим инженерам.
К сожалению, компания была приобретена через несколько недель, поэтому вся автоматизация (за исключением моей команды) была приостановлена. Я продолжал разрабатывать фреймворк в одиночку в течение нескольких месяцев, пока другие команды снова не смогли автоматизировать. Однако к этому времени команды решили, что они предпочтут использовать JavaScript и Cypress, чем Python.
Ваш выбор языка имеет значение. При создании среды автоматизации проверьте (и еще раз проверьте), что язык, который вы используете, согласован. Не используйте язык, который может быть трудным для найма или популярность которого снижается. Используйте язык, который предлагает адекватные инструменты и возможности.
Резюме
Автоматическое тестирование может значительно повысить качество жизни и продуктивность любой команды разработчиков. Однако создание среды автоматизации может быть трудным процессом. Убедитесь, что вы вдумчиво и обдуманно выбираете язык и архитектуру. Сотрудничайте со своими разработчиками над программированием с учетом автоматизации.
Самое главное, реалистичные ожидания, когда дело доходит до автоматизации тестирования.
Ресурсы
- Канер, Джем и др. Уроки, извлеченные при тестировании программного обеспечения: подход, основанный на контексте. Wiley, 2002, стр. 10.
- Гибкое тестирование: Практическое руководство для тестировщиков и гибких команд, Лиза Криспин и Джанет Грегори, Аддисон-Уэсли, 2014 г., стр. 287-288.
- Лофверс, Джефф. Это работает на моем компьютере. Не нажимайте "Сохранить", donthitsave.com, 2016 г.
- Гибкое тестирование: Практическое руководство для тестировщиков и гибких команд, стр. 280.
- В то время это было правдой. У каждого проекта теперь есть большое количество участников на GitHub, что делает их более надежными.
- Состояние Октовселенной, octoverse.github.com/.
