Автоматизация тестирования

Опыт компании в автоматизации тестирования

Почти все наши проекты были выполнены на основе методов Agile/Scrum/XP, мы широко используем все виды автоматизации тестирования. Стараемся автоматизировать все, что делаем, как на уровне программирования, так и на уровне пользовательского интерфейса (в основном веб-интерфейса).

В случае каких-либо технических сложностей, наша компания привлекает партнеров с экспертным знанием и опытом в области автоматизации тестирования для консультирования и достижения лучших результатов для наших клиентов.

Наши сотрудники умеют работать с требованиями заказчика, в компании применяются все современные методы и средства – это и использование Google Docs и Google Excels, Trac/Jira, всех видов вики. Сотрудники хорошо знакомы с непрерывной интеграцией, в том числе Jenkins, а также с Maven и его системой репозиториев Nexus, без проблем используем SVN или Git (в том числе в связке с Gerrit).

Мы акцентируем внимание на управлении тестированием и всегда заботимся о высоком проценте покрытия Business Use кейсов. Такие термины, как регрессионное или smoke тестирование, также хорошо известны нашей команде.

Мы не просто “продаем” ресурсы, но и готовы предоставить BA специалистов, которые помогают нашим тестировщикам в понимании бизнес-логики системы. В то время, как координатор/менеджер проекта помогает улучшить взаимодействие между командами, и в случае необходимости принимает решение о привлечения специалистов с нужной технической экспертизой (например, наших Java экспертов).

Наше определение “хорошего теста”

В процессе разработки и для наших заказчиков мы всегда стремимся создавать хорошие тесты. Хорошие – это те тесты, которые отвечают следующим принципам:

• Независимость от других тестов, при этом не имеет значение очередность запуска теста. Это означает, что установка и отключение тестов должны быть сделаны корректно, и все подготовительные шаги должны быть выполнены в рамках этого теста.
• Повторяемость и стабильность. Если приложение не изменилось, то каждый раз, когда мы запускаем тест, мы должны получать тот же результат
• Информативность. В идеале мы должны понимать, что делает тест, взглянув на его имя (пакет, класс или метод).
• Простота в поддержке. Мы практикуем коллективное владение исходным кодом, когда каждый может изменить что-либо в коде, поэтому каждый должен помнить про красивый стиль кода, хорошее разделение методов и возможность повторного использования кода.
• Соответствие требованиям.
• Тесты должны быть достаточно быстрыми, чтобы иметь десятки тестов, при этом не боясь, что увеличение количества тестов приведет к значительному увеличению их продолжительности.
• Расширяемость, что позволяет QA команде легко проводить рефакторинг или изменять некоторые подходы, лежащие в основе архитектуры тестов
• Data Driven, в идеале должен позволять BA/владельцу продукта вводить различные значения тестов.
• Не должны содержать copy-paste.
• Иметь хорошую архитектуру.

JUnit экспертиза

Мы активно используем JUnit и все возможные расширения: Mockito, Easy mock, TestNG, JUnit3/JUnit4, также мы создавали наши собственные JUnit раннеры, кроме того, наш продукт XML2Selenium имеет хорошую интеграцию с JUnit Notifiers, т.е. мы знаем внутреннюю архитектуру JUnit на очень высоком уровне.

Мы делаем как модульное тестирование изолированных методов, где используем все виды техники для изоляции – Mocks, Dummy, Stubs, так и различные виды интеграционного тестирования. Здесь имеется в виду тестирование всех частей программного обеспечения на одной виртуальной Java машине с дополнительными связями с базами данных или сторонними веб сервисами, а также тестирование распределенного программного обеспечения.

Наша команда участвовала в создании архитектуры тестов для известного SOA фреймворка в крупной европейской компании (NDA), мы также принимали участие в создании среды для тестов для проекта Eclipse под названием Texо. Имея весь этот опыт, мы на практике постоянно используем разные управленческие и логические подходы к тестированию, в том числе Test Driven Development, Data Driven Тестирование и Behavior Driven Тестирование. Применяя DDT, мы используем разные хранилища данных. Это могут быть properties файлы, XML-файлы, а также электронные таблицы Excel, как это было сделано для одного большого продукта в Индии.

Все эти модели требуют хорошо продуманной архитектуры, чтобы иметь возможность прогонять наборы данных через тесты. И здесь у нас хорошее преимущество, так как в нашей компании мы делаем большой акцент на архитектуре, паттернах, ООП, UML. Хороший ООП дизайн позволяет сделать все более эффективным, и Вы действительно сможете применить на практике TDD и DDT.

Selenium/Web Driver экспертиза

Изначально мы работали с Selenium1, теперь перешли на Selenium2 (Selenium3) и Web Driver. Над этими фреймворками мы обычно выстраивали набор классов, помогающих нам в тестировании. Зачастую это Page Object паттерн, хотя мы использовали и другие методы написания и организации тестов. Иногда это просто набор вспомогательных классов без архитектуры, чтобы быстро создать тесты, а порой это целый фреймворк с собственным work flow. Обычно мы стараемся обернуть приложение тестированием с помощью ООП, а затем сосредоточиться на логике тестирования, и не думать о самом Selenium/Web Driver. Иногда мы делаем тесты с уклоном на BDD, когда BA/менеджеры могут быть интегрированы в среду тестирования, и даже могут расширять тесты бизнес-требованиями. Такой подход требует создания некоторых промежуточных слоев или определенной грамматики для тестов.

Мы можем использовать аннотации Selenium/WebDriver либо создать свои собственные аннотации, например, для нужд отчетности. Кроме того, мы также умеем настраивать и расширять JUnit, чтобы предоставить более подробную информацию о случившейся ошибке (например, чтобы показывать не только название классов и методов, но и логически показать, где появились проблемы). Наша компания имеет хороший опыт работы с логами Selenium/WebDriver тестов, а для одного из наших проектов мы кастомизировали логгеры, и при этом каждый тест имел свой собственный лог-файл.

Также мы делали много интересных вещей поверх Selenium, например, запись видео с помощью библиотек с открытым исходным кодом (можно было записать момент теста, где появлялись проблемы, чтобы лучше проанализировать его). Можем делать снимки тестируемых страниц, включая JS/CSS/изображений/HTML, для последующего анализа в случае поваленных тестов при запуске их на CI сервере. В данный момент в нашем продукте XML2Selenium есть 2 очень важных свойства. Первое – это возможность осуществлять удаленную отладку тестов на CI сервере, работая не с атрибутами Java (классы и переменные и т. д.), а с конкретными терминами DSL тестов (тест, тест кейс, шаг и т. д.). Другим важным аспектом нашего продукта является система, позволяющая сохранять в NoSQL БД результаты различных запусков тестов для возможности их дальнейшего анализа. Используя наш фреймворк, можно делать скрины со статистикой, какие тесты были стабильными в течение последних 10 итераций, а какие нет, а также автоматически получать статистику по проценту покрытия требований.

Наша компания часто в работе сталкивается с XML, где требуется знание XPath. Мы много работали с XSLT, в котором активно используется XPath. Мы понимаем все концепции XPath и понимаем, какой XPath хорош в использовании в тестах, а какой нежелательно использовать (например, может быть изменен, если разработчик внесет изменения в HTML). Кроме того, у нас в практике консультирование разработчиков: как лучше назвать элементы на странице, чтобы избежать проблем. Также большое внимание в компании уделяется такому свойству тестов, как их повторное использование.

Таким образом, мы можем сказать, что все рабочие моменты, связанные с Selenium/Web Driver успешно покрываются в нашей компании – логи, многопоточность, отчеты, связь с людьми бизнеса и владельцами продуктов, интеграция с методологией, которая используется для управления проекта. У нас есть опыт создания тестов и в качестве консультационных услуг для компаний, работающих над собственным продуктом, а также в создании тестов по проекту, который разрабатывался инженерами нашей компанией.

Использование других фреймворков для тестирования

Наша компания использует JMeter как для нагрузочного тестирования, так и просто в качестве инструмента автоматизации тестирования, с созданием кастомизированной системы, которая анализирует XML отчеты из JMeter и пишет HTML отчеты.
Кроме того, у нас есть хороший опыт в использовании Jubula с CRM приложением на основе Swing. Здесь мы также делали кастомизацию некоторых процессов заказчика, что позволило иметь реальную непрерывную интеграцию с тестами.

На одном из проектов в качестве системы репортинга мы использовали FitNesse для интеграционных тестов сервлетов. Он был интегрирован в CI, проект был на Maven.
Для тестирования веб-интерфейса, кроме всего прочего, мы использовали Concordium, интегрировав его с Selenium/WebDriver. Это был фреймворк собственной разработки для одного клиента, для которого мы затем еще создали тесты поверх этого фреймворка, что дало возможность создавать авто-тесты бизнес-аналитику или владельцу продукта.