Автоматическое функциональное тестирование веб приложении на уровне пользовательских истории

Аннотация. Автоматизация тестирования приложений на сегодняшний день является одним из важных компонентов всего процесса разработки программного обеспечения. Есть функциональное, нефункциональное автоматическое тестирование, существует много подходов автоматизации такие как TDD(Test Driven Development), BDD(Behaviour driven Development). Согласно пирамиде автотестирования, самым верхним уровнем является GUI тестирование. И таких тестов, на уровне GUI должно быть меньше всех. В данной статье рассмотрим решение вопроса покрытия тестами продукта, путем написания автоматических конечных тестов, которое однозначно облегчит жизнь QA-инженерам и в разы оптимизирует ручной процесс тестирования какого либо проекта.

Abstract. Application testing automation today is one of the important components of the entire software development process. TDD (development through testing), BDD (behavior-driven development). According to the autotest pyramid, the topmost level is GUI testing. And such tests, at the GUI level should be the least. In this article, we will consider the solution of the question about the product under test, in which automatic final tests are written, which are uniquely suitable for life and allow us to optimize the process of testing manually for any project.

Ключевые слова: Автоматическое функциональное тестирование, пирамида автотестирования, паттерны автоматизации, TDD, BDD.

Keywords: QA Automation, automation pyramid, automated testing patterns, TDD, BDD.

Введение

В настоящее время, в крупных компаниях, занимающихся производством серьезных бизнес приложений, трудно представить процесс тестирования без автоматизации. Если лет 10 назад об этом говорили и писали не повсеместно, то сейчас автоматизация тестирования является обыденным процессом. Разработаны много подходов, приемов и техник реализации автоматизации. Есть разные виды тестирования, функциональное нефункциональное тестирование. Согласно пирамиде авто тестирования, на основе пирамиды должны быть модульные тесты, затем интеграционные тесты, и последним уровнем является GUI тесты. Но, обычно, QA инженеры при ручном тестировании, не проверяют на модульном  уровне все методы и классы, так же проверка ручным способом всех взаимодействии модулей невозможно, как правило, специалисты по тестированию, проверяют приложения на уровне пользовательских истории. Рассмотрим процесс автоматизации тестирования с точки зрения пользовательских истории.

Что автоматизировать ?

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

Стоимость качества

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

Рисунок 1. Стоимость исправления

Важность автоматизации

Есть как минимум 6 причин автоматизировать регрессионное тестирования:

1. Ручное тестирование требует длительного времени.
2. Сокращение подверженных ошибкам задач тестирования.
3. Освобождение времени для выполнения более высокоуровневых задач.
4. Быстрое получение отклика о качестве кода
5. Автоматизированные тесты являются самой актуальной документацией
6. Возврат инвестиций

Виды автоматических тестов

Функциональное автоматическое тестирование - выполнение пользовательских сценариев основанных на техническом задании, автоматизированным путем, с помощью скриптов. На сегодняшний день скрипты пишутся на следующих языках Java, Python, PHP, JavaScript, Ruby и т.д.

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

Уровни автотестов

Приложения автоматический тестируются на 3 уровнях:

• Модульное тестирование. Модульные тесты, это проверки работоспособности и корректной работы, одного метода, класс, либо пакета.
• Интеграционное тестирование. Проверка совместной работы двух или нескольких модулей приложения.
• Функциональное тестирование.  Тестирование на уровне пользовательских сценариев.

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

TDD, BDD тестирование.

TTD (Test driven development) - техника разработки программного обеспечения, когда сперва пишуться модульные тесты, а затем сам функционал.  Цикл разработки TDD:

• Добавление теста
• Запуск тестов, убедиться, что новые тесты не проходят
• Написать сам код функционала
• Запуск всех тестов, убедиться что все тесты проходят
• Рефакторинг
• Повторить цикл

Рисунок 1. Цикл TDD разработки

BDD (Behaviour driven development) - техника разработки программного обеспечения, основная идея которого является совмещение в процессе разработки чисто технических интересов и интересов бизнеса, позволяя тем самым управляющему персоналу и программистам говорить на одном языке.

Согласно пирамиде тестирования, в проекте должно быть очень много модульных тестов, но даже покрыв на 90 процентов кодовой базы приложение модульными тестами, инженер по качеству не может гарантировать корректность работу прилОжения. Соответственно необходимо писать сквозные тесты, для гарантирования работы пользовательских сценарии. Ведь когда тестировщик проводит ручное тестирование, он проверяет именно посредством пользовательских сценарии.

Рассмотрим пример некого приложения, скажем так интернет доска объявлений, где можно подать объявление, искать, удалять, добавлять в избранный и много другое.  Предположим, что у этого приложения есть порядка 300 бизнес пользовательских сценариев. Допустим для ручного тестирования, данного набора тест кейсов, в рамках полного регрессионного тестирования, на проверку одного тест кейса нам понадобиться 5 минут, то для полного тестирования нам понадобиться 5 минут * 300 кейсов = 1 500 минут ~ 25 часов ~ 3 рабочих дня. Получается чтобы проверить одну задачу на полный регресс требуется 3 рабочих дня. Представьте в месяц команда разработки в среднем закрывает 40 задач, то есть, в таком случае для тестирования 40 задач, потребуется 120 дней, при том, что за месяц есть всего лишь 22-23 рабочих дня.

А покрывать весь код модульными тестами, очень затратно по времени, и не всегда команды и менеджеры готовы этому делу посвятить какое то внимание. Соответственно, в таких случаях на помощь приходят именно автоматическое тестирование пользовательских истории на самом высоком уровне. То есть если покрыть как минимум 90 % своих бизнес сценариев автотестами, то можно уже быть уверенным что эти 40 задач не ломают ваше приложение.

Заключение

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