Перевод статьи «Testing Under Pressure: How We Built an Autonomous Testing Framework».
Некоторое время назад я работал над проектом, в котором нам нужно было провести автоматизированное санитарное тестирование. Оно позволяет убедиться, что недавно добавленные или измененные функции в приложении работают так, как ожидалось.
Друзья, поддержите нас вступлением в наш телеграм канал QaRocks. Там много туториалов, задач по автоматизации и книг по QA.
У команды тестировщиков был всего один час, чтобы провести sanity-тестирование и сообщить о любых проблемах в приложении. Мы запустили автоматизированный набор тестов, содержащий около 100 тест-кейсов.
Представьте, что вы готовитесь запустить ракету в космос. Но прежде чем это произойдет, вы хотите убедиться, что все работает идеально – двигатели, гаджеты, все. Это похоже на то, что мы делаем с нашим приложением, только вместо ракеты – компьютерная программа.
Теперь самое сложное: у нас есть всего один час на эту проверку. Почему? Ну, это как сесть на поезд. Если вы пропустите его, вам придется ждать следующего, а это займет много времени. Для нас это будет означать задержку в релизе.
Мы должны быстро все проверить, чтобы убедиться, что наше приложение готово к работе. Если мы будем затягивать, это может привести к проблемам для нашей компании и наших клиентов. Поэтому важна каждая секунда.
Хотя тесты выполнялись параллельно, на их выполнение уходило не менее 30-45 минут. Набор тестов включает в себя простые, средние и несколько сложных тест-кейсов, которые оценивают наиболее важные функции приложения.
В процессе тестирования мы столкнулись с несколькими проблемами.
Проблема 1
В большинстве случаев при запуске тестов проблем не возникало, и мы успевали закончить тестирование вовремя. Однако время от времени во фронтенде происходили изменения, и это приводило к многочисленным сбоям в тестах. Команде приходилось анализировать все сбои за оставшиеся 15 минут.
Например, каждый тест должен проходить через страницу входа в систему. Если какие-либо характеристики веб-элементов на странице входа в систему изменятся, все тесты упадут. В этом случае тестировщику необходимо исправить тесты, а затем запустить их заново.
Страница входа в систему состоит из таких веб-элементов, как текстовые поля UserName, Password и кнопка Login. Если свойства кнопки входа, такие как Text, ID, Name или Tag, изменены, тест может не распознать эту кнопку из-за изменений.
В этой ситуации, если кнопка входа изменится, все тесты, использующие страницу входа, упадут за 5 минут. Следующие 5 минут тестировщик потратит на выяснение того, что пошло не так, и еще 5 минут на исправление затронутых тестов. Таким образом, из-за изменения одной кнопки уже потрачено в общей сложности 15 минут. Теперь осталось всего 45 минут.
Проблема 2
Проблемы, связанные с развертыванием, иногда приводили к многочисленным сбоям в тестировании. Некоторые были повторяющимися и быстро решались, но проанализировать все сбои в течение 15 минут и определить тип проблем было непросто.
Например, если тесты поиска в приложении проваливаются с конкретной ошибкой, мы знаем, что одна из зависимостей настроена неправильно. Мы сообщаем об этом разработчикам, чтобы они исправили настройки. Однако вручную разбираться во всех ошибках в тестах очень сложно.
Проблема 3
Санитарное тестирование проводилось после рабочего дня, при этом один человек выступал в качестве контактного лица, рассылая электронные письма по завершении развертывания. В тестировании участвовало не менее 10-12 команд. Задержки с развертыванием и ожидание выполнения тестов создавали дополнительное напряжение. Ответственные за запуск автоматизированных тестов постоянно проверяли электронную почту. Иногда из-за длительного ожидания они пропускали письма о развертывании. Были также случаи запуска тестов с неправильной конфигурацией, поэтому приходилось останавливать и перезапускать их с правильной настройкой.
Мы сообщили руководству об этих проблемах и попросили либо увеличить время проведения санитарных тестов, либо уменьшить количество тестов. Однако увеличение времени означало бы рост расходов. С другой стороны, сокращение количества тестов может поставить под угрозу качество приложения. В ответ на это руководство решило назначить двух дополнительных сотрудников, которые будут помогать нам в процессе тестирования.
Мы старались найти следующие решения наших проблем:
- Фреймворк для тестирования, способный адаптироваться к изменениям веб-элементов
- Метод быстрого анализа неудачных тестов и предоставления краткой информации о результатах тестирования
- Решение для автоматического запуска тестов сразу после получения писем о развертывании, способное выбирать правильную конфигурацию для выполнения тестов.
Решение
Мы продолжали исследования в течение длительного времени и в итоге нашли решение для каждой проблемы. Это привело нас к созданию автономного тестового фреймворка. Его функционал состоит из трех частей: чтение почты, самовосстановление и анализатор результатов теста.
Mail Reader
Mail Reader предназначен для запуска автоматизированных тестов сразу после получения писем о развертывании. Он способен понимать письма и выбирать правильную конфигурацию для выполнения тестов.
Давайте рассмотрим сценарий, описанный в разделе “Проблема 3”. Теперь у нас не будет случаев запуска теста с неправильной конфигурацией. Mail Reader запускает тест на выполнение сразу после получения письма о развертывании. Он использует базовые методы машинного обучения для классификации писем, различая те, что связаны с изменениями во фронтенде и бэкенде. Mail Reader быстро воспринимает содержимое письма, выбирает подходящую конфигурацию и автоматически запускает тесты на выполнение.
Self-Healing
В следующем видеоролике показано, как Self-Healing (“самовосстановление”) решает проблему динамически изменяющихся элементов пользовательского интерфейса.
Теперь давайте вспомним пример с кнопкой входа в систему, рассмотренный в разделе “Проблема 1”. Если свойства кнопки входа меняются и селектор веб-элементов в тестовом сценарии не может ее найти, срабатывает механизм Self-Healing. Он определяет новую кнопку входа в систему и обновляет селектор элементов в тестовом сценарии, позволяя продолжить выполнение теста. Это решение самостоятельно исправляет проблемы в течение 1-2 минут вместо 15, необходимых для ручного исправления.
Test Result Analyzer
Видео ниже демонстрирует, как Test Result Analyzer решает проблему быстрого анализа результатов тестирования.
В примере, приведенном в разделе “Проблема 2”, использование Test Result Analyzer решает проблему. Вместо того, чтобы вручную анализировать каждый неудачный тест, Test Result Analyzer составляет список уникальных ошибок, полученных в ходе выполнения теста, и связывает их с соответствующими тест-кейсами. Анализ результатов тестирования может быть выполнен быстро, менее чем за 5 минут, что значительно экономит время.
Заключение
Исходя из нашего опыта мы поняли, что важными факторами в работе являются гибкость и крепкая связь между членами команды. Мы сталкивались с разными проблемами, от изменений в интерфейсе до задержек с развертыванием, но главным достижением для нас стал автономный тестовый фреймворк, который мы создали. Надеемся, наш опыт будет вам полезен и даст идеи для решения ваших проблем с тестированием.