Рекомендации по ведению проекта в EQATOR
В данном разделе приведены рекомендации и лучшие практики по использованию EQATOR в проектной деятельности.
EQATOR - система тест-менеджмента, то есть система, которая используется для реализации процесса тестирования.
Процесс тестирования в совокупности с EQATOR подразумевает корректное ведение проекта, используя инструменты, предоставляемые системой. Разберем детально нюансы процесса тестирования с использованием EQATOR.
1. Создание тестовой документации
Проект по разработке той или иной системы начинается с требований. Требования определяют вектор проекта и являются основой для действий для всех исполнителей проекта: аналитики переводят требования в понятный для разработчиков "язык", разработчики пишут код в соответствии с требованиями, тестировщики, в свою очередь, проверяют выполнение результата на соответствие исходным требованиям. Перед проверкой происходит перевод требований также на "свой язык" - написание тест-кейсов - пользовательских сценариев или наборов проверок, которые необходимо пройти, чтобы определить корректность работы системы.
Не забывайте использовать функцию прикрепления файлов к тест-кейсу: иногда одно изображение или видео может оказаться гораздо нагляднее текстового описания, а доступ к материалам будет обеспечен как при создании кейса, так и при его просмотре в рамках тестового прогона.
Тест-кейсы являются компонентами "ядра" проекта, то есть основой для того, чтобы предпринимать какие-либо действия с ними.
Для лучшей организации кейсов и структурирования тестового репозитория в целом есть возможность включения тест-кейсов в тест-сьюты.
2. Согласование тестовой документации
Написать тестовую документацию может обычный тестировщик, знакомый с разрабатываемой системой, но для того, чтобы реализовать проверку кейсов на корректность опытным тестировщиком на проекте (тестлидом) имеется функция "Одобрить" для каждого создаваемого кейса. Все новые кейсы при создании создаются в статусе "Черновик" и не могут быть включены в прогоны. Одобрение позволяет согласовать тест-кейс, чтобы использовать его в тех местах, где будут необходимо включать наборы кейсов для проверки.
Также имеется возможность одобрить сразу все тест-кейсы в статусе "Черновик" одновременно, используя кнопку "Одобрить все".
3. Формирование тестовых прогонов
Когда тестовая документация готова можно запускать ее в проверку. Для запусков проверок кейсов используются тестовые прогоны. Прогоны позволяют осуществлять разные виды ручного тестирования: смоук, регрессионное и т.д. посредством включения необходимых тест-кейсов и их проверки.
Если тест-кейс можно назвать атомарным случаем (сценарием), то прогон является комплексной "историей" пользователя или набором "историй", т.е. чаще всего создается для проверки больших сценариев.
4. Прохождение тестовых прогонов
Для запуска прогона обязателен исполнитель - тот, кто будет осуществлять тесты. Переведя прогон в статусе "В работе" он дает понять, что начал непосредственно тестирование системы. При тестировании кейсов и/или шагов тест-кейсов исполнитель должен переводить их в соответствующие статусы, чтобы фиксировать корректность работы системы на данных шагах.
При выборе статуса "Провален" (Failed) для тест-кейса или его шага (в зависимости от типа тест-кейса) система предложит оставить комментарий о проблеме и создать баг в Jira, форма которого будет иметь привычные поля для тех, кто уже создавал баги в данной системе трекинга. Подробнее о настройке интеграции с Jira описано по ссылке.
Завершение работ по тестированию сценариев (кейсов) фиксируется завершающим статусом - "Выполнено" и означает, что прогон завершен и изменения в него не могут быть внесены.
5. Привязка к релизам системы
Релизы системы являются результатом "выливки" нового кода на тестовые или production площадки, а, следовательно, и появлением нового функционала, который необходимо протестировать.
Таким образом, релизы в EQATOR имеют привычный для разработки вид формата n.n.n, где n - номера версии релиза (например, 1.2.0). Релизы могут включать в себя тестовые прогоны, тест-кейсы в которых необходимо проверить. Так, можно планировать прохождение прогонов на будущие релизы и брать их в работу непосредственно при "выливке" нового (или исправления ошибок старого) функционала системы.
Что ещё важно учитывать при ведении проекта в EQATOR?
Помимо соблюдения описанных выше нюансов процесса тестирования также необходимо помнить о следующих разделах и функциях системы:
О проекте
При создании/редактировании проекта старайтесь указывать как можно больше информации о нем: описание предметной области, полезные ссылки. Это поможет в том, чтобы сохранять в тестовом репозитории все полезные материалы и ресурсы.
Команда проекта
В разделе "Участники" можно управлять командой проекта, которая выражена в формате следующего набора ролей:
- Тестлид - ответственный за процесс
- Тестировщик - ключевой исполнитель процесса
- Руководитель проекта - следит за проектом
При формировании команды важно понимать кому необходимо принимать участие в процессе тестирования и своевременно включать их в перечень участников проекта в соответствии со своей ролью в данном процессе.
Отчеты
В разделе "Отчеты" лицо принимающее решения (тестлид или руководитель проекта) может в наглядной форме просмотреть текущее состояние проекта в разрезе пройденных прогонов - количество проваленных кейсов, время, потребовавшееся на прохождение прогона, и т.д.
Интеграции
Если у вас активно используется Jira для работы с разработчиками (постановка задач на разработку, правка багов и т.д.), то в разделе "Интеграции" вы можете настроить ее, чтобы, как было упомянуто ранее, иметь возможность создавать баги без входа в саму Jira, а в дальнейшем формировать интеграционные тест-планы.