QA инженер корпоративного софта

Задача:

за 1-3 часа поднять кругозор по теме, вооружится инструментами и начать делать.

Ключевые обязанности QA-инженера

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

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

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

Документирование багов. Описывая баги, важно предоставить максимум информации об их природе и причинах возникновения.

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

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

логи отправление, при случае багов
скринкасты, скриншоты.

баг репорт: дефект без документации = нет дефекта. Нужна документация дефекта, то что не документируем, считаем не найденным.

Атрибуты баг-репорта:

краткое название.
название проекта
компонент приложения - в какой части функциональности произошла
номер версии
Критичность. Этот атрибут показывает влияние дефекта на функциональность системы. Например:

Blocker — дефект, блокирующий использование системы.
Critical — ошибка, которая нарушает основную бизнес-логику работы системы.
Major — ошибка, которая нарушает работу определенной функции, но не всей системы.
Minor — незначительная ошибка, не нарушающая бизнес-логику приложения, например, ошибка пользовательского интерфейса.
Trivial — малозаметная, неочевидная ошибка. Это может быть опечатка, неправильная иконка и т.п.

Приоритет — high, medium, low.
Статус. Статус исправления бага — to do, in progress, in testing (on QA), done. В зависимости от особенностей проекта возможны дополнительные статусы.
Автор баг-репорта.
На кого назначен. Баг-репорт отправляют тимлиду проекта или разработчику, который будет заниматься исправлением дефекта, в зависимости от принятых в команде договоренностей.
Окружение. Где найден баг: операционная система, наименование и версия браузера.
Предусловие (если необходимо). Необходимо для описания действий, которые предшествовали воспроизведению бага. Например, клиент авторизован в системе, создана заявка с параметрами ABC и т.д. Баг-репорт может не содержать предусловие, но иногда оно бывает необходимо для того, чтобы проще описать шаги воспроизведения.
Шаги воспроизведения. Один из самых важных атрибутов — описание шагов, которые привели к нахождению бага. Оптимально использовать 5-7 понятных и кратких шагов для описания бага, например:
1. Открыть (...)
2. Кликнуть (…)
3. Ввести в поле А значение N1
4. Ввести в поле B значение N2
5. Кликнуть кнопку «Calculate»
Фактический результат. Что произошло после воспроизведения указанных выше шагов.
Ожидаемый результат. Что должно произойти после воспроизведения шагов тестирования, согласно требованиям.
Прикрепленный файл. Логи, скриншоты, видеозапись экрана — всё, что поможет разработчику понять суть ошибки и исправить ее.

Инструменты для QA

Jira

Создание багов.
Подключение к релизам.
Релизы - это выпуск новой версии приложения, исправления в "актуальную" программу. Возможно текущий биллинг придется тоже версию назвать: и сформировать план вокруг этого релиза → проведенные исправления.
Спринт - это 2-ух недельный срок, "забег" работы команды.

логика статусов багов