Посещая митапы разработчиков и технических специалистов, а также общаясь с тестировщиками из других компаний, я обратил внимание, что всегда поднимается вопрос о том, как сложно внедрить автоматизацию тестирования в рамках одного спринта. Поэтому я решил рассказать о том, как приобрел (и продолжаю накапливать) свой опыт в автоматизации тестирования. Обратите внимание, что это мой личный способ и он сработал на тех проектах, в которых я участвовал.
Для успешной работы метода требовался определенный бэкграунд, который сформировался благодаря обсуждениям и изучению материалов по автоматизации.
Перевод статьи «How I automate tests (or try to) inside Sprint».
Подпишитесь на наш ТЕЛЕГРАМ КАНАЛ ПО АВТОМАТИЗАЦИИ ТЕСТИРОВАНИЯ
Компания
В самых успешных кейсах, компания (или хотя бы некоторые ее руководители) активно поддерживает стремление внедрять гибкие методологии (Agile), независимо от того, какой именно используется подход — Scrum, Kanban или другой. Если команда на каком-то этапе терпит неудачу, ее мотивируют делать новые попытки для достижения результата, а не наказывают за ошибки.
Иногда заинтересованные стороны хотят управлять процессом по классической, последовательной методологии (waterfall), где все планируется заранее и изменять что-то по ходу крайне сложно. Если ваша компания соглашается на работу по такой методологии только для того, чтобы не потерять заказчика, вероятность неудачи внедрения будет высокой.
Команда
Здесь мы будем рассматривать команду как группу людей, работающих вместе для достижения общей цели, а именно – для повышении ценности продукта.
Команда должна делиться информацией, идеями, переживаниями, успехами и неудачами, работая как единое целое.
Команда отличается от группы сотрудников тем, как люди себя в ней ведут. В группе каждый делает свою работу, не задумываясь о том, как она может повлиять на результат. А что если спринт провалился? “Ну и что? Я сдал работу в срок, я тут ни при чем”. Или еще хуже, указывать пальцем: “Вот он не справился со своей работой”.
Я бы добавил еще одну категорию — “псевдокоманда”. Такая команда знает как работать в группе, но выполняет только то, что предписано в требованиях. Ее участники могут даже думать об улучшениях, но если цель достигнута, зачем делать что-то еще?
Если вы находитесь в группе сотрудников, то скорее всего, не сможете автоматизировать задачи во время спринта. Работая же в команде вероятность этого высока. А если вы являетесь членом “псевдокоманды”, почему бы вам не попытаться сделать ее настоящей командой? Поделитесь своими идеями по интеграционному тестированию на ретроспективе в конце спринта или предложите обсудить их с командой после дейли митинга, пока вы все вместе.
Воображение
Для автоматизации новой фичи нужно немного воображения. Если у вас уже есть макеты страниц, это упрощает задачу, но если их нет — представьте себе, как будет проходить процесс. В первую очередь написанный вами код будет автоматизировать такие функции, как заполнение поля или нажатие кнопки, вне зависимости от её положения на экране, цвета или формы.
“Но я не знаю id элементов !” – скажете вы. На это у меня есть два варианта решения:
- Оставьте поле пустым или укажите, что заполните его позже, или
- Создайте переменную, которая позволяет использовать конструкцию ключ-значение (например, hash, hashmap или dict). Заполните её так:
variable_name [ключ]. А затем просто заполните вторую часть равенства значениями, которые вы узнаете потом.
Используя этот метод, я уже написал свой код одновременно с разработчиком! И затем вам надо будет просто заполнить id элементов и внести небольшие корректировки если потребуется. И вот, функциональность уже автоматизирована!
Мой процесс автоматизации
Все начинается на планировании, где мы определяем бэклог спринта. Предположим, что цель спринта – реализовать вход в систему (всегда пример про страницу авторизации…).
Запишите все возможные сценарии для страницы логина. Прежде чем приступать к автоматизации, определите, что будет покрыто модульными тестами, что – на уровне API, и что — на уровне UI (фронтенда).
Возьмите на себя конкретные задачи и автоматизируйте в первую очередь “позитивные сценарии” – такие, при которых все происходит идеально. Нет смысла тестировать функциональность, если она не выполняет свою задачу, даже когда пользователь делает всё правильно.
После этого, напишите все возможные сценарии успешной авторизации, например:
#login.feature Feature: Successfull login Background: Given I am on the login screen Scenario: Successful login using username When I log in using "username" Then I should be directed to the main page Scenario: Successful login using email When I log in using "email" Then I should be directed to the main page Scenario: Successful login using ID When I log in using "ID" Then I should be directed to the main page
Функционал: успешная авторизация
Предусловие:
Дано я на странице логина
Сценарий: успешная авторизация через username
Когда я авторизовался через username
Тогда я должен попасть на главную страницу
Сценарий: успешная авторизация через электронную почту
Когда я авторизовался через email
Тогда я должен попасть на главную страницу
Сценарий: успешная авторизация через ID
Когда авторизовался через ID
Тогда я должен попасть на главную страницу
Пропишите все, что ваша система будет поддерживать.
Реализация сценариев автоматизации
Здесь подключается воображение. Сценарии будут реализованы только на основе макета страницы входа.
Мой файл шагов тестирования, без конкретной реализации, выглядит примерно так:
#login.steps.rb
Given ("I am on the login screen") do
pending # напишите здесь код, который приведет вас на страницу авторизации
end
When ("I log in using {string}") do | string |
pending # напишите здесь код, чтобы авторизоваться через {string}
end
Then ("I should be directed to the main page") do
pending # напишите здесь код для проверки, что вы попали на главную страницу
end
Обратите внимание, что хотя в моем файле функций несколько сценариев, в нем всего три шага для реализации. Когда вы пишете код, очень важно думать о его переиспользовании. После реализации “с помощью моего воображения” шаги будут выглядеть так:
#login.steps.rb
Given ("I am on the login screen") do
@login_page = LoginPage.new
@login_page.load
end
When ("I log in using {string}") do | user |
@login_page.user_field.set USER[user]
@login_page.password_field.set PASSWORD[user]
@login_page.btn_login.click
end
Then ("I should be directed to the main page") do
current_page_is?(NAMES['current_page'])
end
А также файлы с описаниями объектов страниц, переменными и методами взаимодействия, которые написаны с использованием фреймворков SitePrism и Capybara:
#login.po.rb class LoginPage < SitePrism::Page set_url "" element :user_field, "" element :password_field, "" element :btn_login, "" end
#methods.rb def current_page_is?(page) page.has_title? page end
#variables.rb
NAMES = {
'main_page' => ''
}
USERS = {
'username' => '',
'email' => '',
'ID' => ''
}
PASSWORDS = {
'username' => '',
'email' => '',
'ID' => ''
}
Смотрите также: “Что такое Cucumber?”
Теперь нужно просто подождать, когда страница авторизации будет готова, дописать код, и вот, функция уже автоматизирована! Не сказал ни один тестировщик в мире…
Даже если вы замените всё правильно, вероятность ошибки при первых запусках очень велика. Приведенный выше пример – это лишь основа. Исправляйте ошибки по мере их появления в логах. Даже при наличии таких ошибок проще и быстрее вносить исправления по ходу работы, чем ждать полной готовности функционала для начала написания кода. Со временем количество ошибок уменьшится.
Завершение работы над фичей не означает, что дальше можно просто сидеть и ждать. В команде, работающей по Agile, всегда есть чем заняться. Поговорите с тем, кто отвечает за DevOps, чтобы узнать, как можно настроить автоматический запуск автотестов (CI/CD), обсудите с разработчиками задачи из бэклога, удобство использования приложения (usability). Взаимодействуйте с командой, предлагайте улучшения, указывайте на проблемы (по возможности, предлагайте их решение). Вы несете ответственность за качество продукта, а не только за автоматизацию тестирования.
Не забывайте о ручном исследовательском тестировании
Всегда уделяйте время исследованию своего продукта. Только так вы будете иметь полное представление о том, как он работает. Не автоматизируйте только те сценарии, что описаны в тз. Многие вопросы и даже новые идеи для автоматизации появятся в процессе использования приложения. Автоматические и ручные тесты дополняют друг друга, а не заменяют.
Я бы осмелился сказать, что даже сегодня, при большом спросе на автоматизацию, QA все равно должны не забывать про ручное тестирование.
Надеюсь, вы сможете уловить общую идею этой статьи и применить ее в вашей компании.