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

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

Почти все наши проекты были выполнены на основе методов 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 под названием Texo. Имея весь этот опыт, мы на практике постоянно используем разные управленческие и логические подходы к тестированию, в том числе 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. Это был фреймворк собственной разработки для одного клиента, для которого мы затем ещё создали тесты поверх этого фреймворка, что дало возможность создавать автотесты бизнес-аналитику или владельцу продукта.