Online QADay 2023 #2
СВІТЛАНА ЯКОВЛЄВА
«Реформування QA підходу – як це було і що з цього вийшло»
telegram: https://t.me/+UtTRnxkNIG1UL3db
fb: www.fb.com/goqaevent
fb: www.fb.com/qaday.org
linkedin: https://www.linkedin.com/company/goqa/
Сайт: www.qaday.org
2. ЦІЛІ
Підняття рівня задоволеності клієнта продуктом.
Визначити та затвердити уніфіковані процедури для всіх команд.
Покращити комунікацію між P2H та customer QA
Teams.
Зменшити кількість ризиків та проблем з продуктом після релізу.
3. СПОСОБИ РЕАЛІЗАЦІЇ
Уніфікувати QA підходи
Підтримувати взаємну організацію тестових
процесів
Організувати комунікацію з customer QA team на регулярній
основі
Дизайн та Розробка спільного аудиту технічних
лідів
Стандартизація тестових
артефактів
Дизайн та Розробка метрик для моніторингу якості
Визначення приймальних критерій
5. ПІДХІД ДО СКЛАДУ КОМАНДИ
P2H & QA
2 BE Engineers
1-2 FE Engineers
0.5 DevOps
0.5 Solution Architect
1 Business Analyst
2 Manual QA Engineers
1 QA Automation Engineers
6. РОЛІ ТА
ОБОВʼЯЗКИ
QA ENGINEER(S)
Аналіз вимог
Планування процесу тестування
Проведення тестування
Ідентифікація проблемних областей
Аналіз результатів
тестування
Підтримка тестової документації
AQA ENGINEER(S)
Аналіз вимог
Планування автоматизації тестування
Розробка, тестування та доставка
автоматизованих сценаріїв
Ідентифікація проблемних областей
Аналіз результатів
тестування
7. ТЕСТОВІ АКТИВНОСТІ
ANALYZE
Ревʼю
Уточнення
вимог
Декомпозиція
Requirement
PLAN
Створення QA
Jira тікетів
Оцінка задачі
Встановлення дат
спринта
Estimate
PREPARE
Створення матриці
покриття
Розробка
тест-кейсів
Підготовка
тестових даних
Test Cases
TEST
Виконання тест-
кейсів
Створення баг
репортів
Re-test уражених
областей
Регресійне
тестування
Bug Reports
REPORT
Актуалізація Jira
тікетів
Створення
тестового репорту
Аналіз спринта
Test Report Retro
8. ІНСТРУМЕНТИ ДЛЯ ПІДТРИМКИ
QA ПРОЦЕСІВ
Jira Python Postman
Confluence Selenium Swagger
Google documents BrowserStack
QTest Burp Suite Playground for GraphQL
JMeter Owasp ZAP Pgweb
BlazeMeter Fiddler
10. МЕТРИКИ
Кількість пройдених тест-кейсів, % Кількість провалених тест-кейсів, %
Кількість заблокованих кейсів, % Кількість знайдених багів на етапі внутрішнього тестування
Кількість дефектів, знайдених після релізу чи внутрішнього тестування (escaped bugs)
Відсоток покриття Автоматичними
тестами
Розподіл дефектів за компонентом (BE, FE etc.)
Матриця покриття вимог
Розподіл дефектів за показником Severity
11. ПРИЙМАЛЬНІ КРИТЕРІЇ
КОЛИ STORY/TASK ПОТРАПЛЯЄ ДО P2H
QA
Задача має відповідний статус в Jira
Тестування зі сторони розробника завершене
Вся необхідна для тестування технічна документація
готова
Всі тестові дані отримані та підтверджені
12. КРИТЕРІЇ ПРИЙОМУ
Задача має відповідний статус в Jira
Вся необхідна для тестування технічна документація
готова
Всі тестові дані створені та підтверджені
Етап внутрішнього тестування пройден у відповідності до Вихідних критеріїв
Результати тестування додані до відповідного Jira
тікету
КОЛИ STORY/TASK ГОТОВА ДО
UAT
13. ВИХІДНІ КРИТЕРІЇ
Всі тест-кейси та автотести 1-го пріоритету
пройдені
Всі Blocker, Critical та Major severity дефекти знайдені та
пофікшені
Щонайменше 80% дефектів з Low та Medium severity пофікшені
Підтвердження щодо готовності продукту до UAT
отримано
Відповідні Регресійні сценарії пройдені успішно
Всі ризики та існуючі проблеми узгоджені з PO
Всі бізнес вимоги покриті тест-кейсами
14. АНАЛІЗ ПЕРШОПРИЧИН БАГІВ
Define
the problem
STEP 1
Identify
Causal
Factors
STEP 2
Collect Data
STEP 3
Identify
the Root
Cause(s)
Recommend &
Implement
Solutions
STEP 4 STEP 5
15. …ПРОЙШОВ РІК
90% проектних команд слідують стандартному підходу
регулярні аудити
збір та аналіз метрик
покращена комунікація з клієнтом
покращена якість продуктів