Online QADay 2023 #2 АНАСТАСІЯ РУСОВА «Побудова якості в команді без тестувальників – міф чи реальність» 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

1. ЯКІСНИЙ ПРОДУКТ БЕЗ QC
МІФ ЧИ РЕАЛЬНІСТЬ
Реальна історія одного проекту,
в ході якого жоден розробник не постраждав

2. ЧОТИРИ НАТИВНІ ЗАСТОСУНКИ ДЛЯ
iOS/Android + БЕКЕНД ДЛЯ НИХ
ЗАЛЕЖНОСТІ ВІД CORE ЗАСТОСУНКІВ. БАГАТО
ЗАЛЕЖНОСТЕЙ
3 КОМАНДИ РОЗРОБНИКІВ. НІ BA, НІ QC
ПОВНА ВІДПОВІДАЛЬНІСТЬ КОМАНДИ ЗА
ФІЧУ: ВІД ІДЕЇ ДО РЕЛІЗА
ОДИН ЗІ СВІТОВИХ ЛІДЕРІВ В ПРОДУКТАХ
ДЛЯ МЕНЕДЖМЕНТУ ПРОЄКТІВ
ЛАНДШАФТ

3. МАНУАЛЬНО
АВТОМАТИЗАЦІЯ БУДЕ. КОЛИСЬ. КОЛИ
НАПИШЕТЕ
ВАЖЛИВА ДЕТАЛЬ – МОВА ПРО ON PREMISE
ДЛЯ КОЖНОГО КАСТОМЕРА
ХОРОША НОВИНА – ВСЕ В РУКАХ КОМАНДИ,
НАД ДУШЕЮ НІХТО НЕ СТОЯТИМЕ
НАВЧИТИ РОЗРОБНИКІВ ТЕСТУВАТИ
ЗАДАЧА
НУ І ТАМ ЩЕ ВСЯКЕ…
ВСЯКЕ in question – нетріажений баг-беклог
на 300+ тікетів, купа фідбеку від
користувачів, вічні питання Баг чи Фіча….

4. ПЛАН
• Чого не вистачає?
• А нащо це нам
взагалі?
• Думай як
тестувальник –
краш-курс для
девів
• Горить
• Не горить
• Йой, най буде
• Де ми є?
• Хто ми є?
• І як нам далі з
цим жити?
Аудит Приорітети
Процеси
Навчання

5. АУДИТ
Крок 3
Створити високорівневий план з розбивкою по основних зонах
(процеси, автоматизація, знання продукту тощо) та таймлайном
Крок 2
Проаналізувати критичні процеси та знайти можливі обхідні
шляхи
Крок 1
Пройтися по больових точках проекту і оцінити масштаби лиха

6. ПРИОРІТЕЗАЦІЯ
Аналіз найболючіших проблеми
(нерозуміння обсягів та складності задач,
відсутність ownership’а, проблеми з
налаштуваннями кожного конкретного
замовника….) –> дорожня карта з
короткостроковими, середньостроковими і
довгостроковими задачами
До короткострокових задач (~ 6 місяців)
ввійшли:
• налаштування базових процесів
• навчання
• хелсчек після 6 місяців

7. ПРОЦЕСИ
ГОЛОВНІ РИТУАЛИ ЗАБЕЗПЕЧЕННЯ ЯКОСТІ
• Quality Kick-off
• Quality Demo
• Blitz
ГОЛОВНІ ДОКУМЕНТИ
• Життєвий цикл різних типів багів
• Реліз процес
• RCA (також відомий як postmortem)
ВЗАЄМОДІЯ
• Налагодження комунікації з core-командами

8. QUALITY KICK-OFF
§ Драйвер мітинга – девелопер, який
працює над фічею/тест менеджер
§ Задача – відповісти на питання типу
«Що ми можемо зламати, якщо це
зробимо?» або «А якщо ми зробимо
отак, яку відповідь маємо отримати?»
§ Всі результати (відкриті питання,
залежності, edge cases і т.д.) вносяться
в user story і є частиною DoD

9. QUALITY DEMO AKA PEER REVIEW/OVER-THE-SHOULDER
§ Проводиться до мерджу функціоналу в
майстер
§ Розробник демонструє команді
базовий функціонал, команда задає
питання, просить натистнути он ту
кнопку показати додаткові сценарії чи
пояснити логіку…
§ Всі знайдені проблеми мають бути
пофікшені

10. БЛІЦ Aka All-Hands Testing
§ Відповідальний за реліз готує сторінку з
усіма фічами, фіксами і т.д.
§ Тестує вся команда одночасно
§ Всі знайдені проблеми тріажаться на місці
(якщо можливо), створюються відповідні
баги
§ В кінці команда приймає рішення про
go/no go

11. НАВЧАННЯ
ОСНОВИ ТЕСТУВАННЯ
• Принципи тестування
• Exploratory Testing
• Impact Analysis
• ”How to break it” замість “How to make it”
КОРИСНІ ШТУКИ
• Красивий баг-репорт
• User empathy (бо опис фіч пишемо теж
ми)
• Баг чи фіча – як визначитися?

12. РЕЗУЛЬТАТ
ПРОЦЕСИ
• З попереднього баг беклогу нам нічого знову не
прилетіло, тож вбили ми його абсолютно виправдано
• Core-команди включили перевірку роботи мобільних
застосунків на нових версіях в їх перед-релізну
підготовку
• Запровадили RCA для інцидентів, які спіймали
випадково/в скоупі інших задач (т.з. Near-miss)
ЦІКАВІ ВІДКРИТТЯ
• При наведенні ладу в користувацькому фідбеку знайшли
кілька потенційних фіч, які в результаті впровадили
• Фіча-лід (людина, яка відповідає за весь процес від опису
сторі до релізу) - крута практика, яка сильно прокачала
девів