Розкажу про перехід від процесу тестування до контролю та забезпечення якості. Поясню, що робити, щоб відкидати помилки в момент зародження та пораніше знаходити ті, що все ж таки зародились. Опишу теорію та практику використання таких понять як Testability, Risk Analysis, Requirements Review, Root Cause Analysis, 5 Whys, Fishbone diagram.

1. Defect Prevention
Сергій Цимбал

2. Про себе
• Сергій Цимбал
• DENTSPLY Implants (раніше –
Materialise Dental)
– Програмне забезпечення для
медичної галузі
– Desktop
– Потенційний вплив на пацієнта
• QA Manager:
– Тест менеджмент
– Ручне тестування
– Автоматизоване тестування
– Внутрішній аудитор
• tcymbal@gmail.com

3. Контроль Якості → Забезпечення Якості

4. The practical guide to defect
prevention
Дефект, якого запобігли:
• Не потрібно
виправляти
• Покращує якість
• Не потрапить до
кінцевих користувачів

5. Модель запобігання дефектів
Виявлення
Аналіз та
передбачення
Запобігання

6. Огляд технік для виявлення та
запобігання дефектів
• QA: TestabilityСтарт проекту
• Команда: Requirements reviewВимоги готові
• Dev: Code reviewПрограмний код готовий
• QA: Test Case reviewТестування
• QA: Risk analysisОпис дефектів
• Dev: Risk analysisВиправлення дефектів
• Команда: Root cause analysisРезультати валідації
• Команда: RetrospectiveЗакінчення проекту/ітерації

7. Виявлення: Testability
• Тестувати ваш продукт
повинно бути просто
• Тяжко тестувати →
тяжко використовувати
• Не забувайте про
безпеку
• Приклади: логи,
макроси, унікальні ID

8. Виявлення: Requirements review
• Дефект у вимогах
дешевше виправити, ніж
в коді
• Що перевіряти:
– Повнота
– Правильність
– Узгодженість
– Ясність

9. Виявлення: Code review
• Деякі дефекти простіше
знайти під час огляду
коду, ніж під час
тестування кінцевого
продукту
• Огляд коду продукту
– Microsoft: залучення тест
інженерів
• Огляд автоматичних
тестів

10. Аналіз: Risk management
• Починайте тестування з
областей з найвищою
вірогідністю виникнення
дефектів
• Високий ефект вкінці
проекту
• Залучення старших
інженерів

11. Аналіз: Root Cause Analysis
•Виправляйте причину, а не
симптом
•Метод індукції
•Коли застосовувати:
–Beta feedback
–Service releases
–Пізно знайдені дефекти
•Типи висновків:
–Додаткові тест кейси
–Зміна тестового підходу
–Зміна процесу

12. Аналіз: 5 whys
5 раз запитайте, чому виникла проблема
1. Чому на підлозі під пресом знаходиться масло?
‒ Швидко подивились: протікає шланг
2. Чому масло протікає з шлангу?
‒ Дослідження: перетирається ременем вентилятору
3. Чому шланг перетирається ременем вентилятору?
‒ Додаткове дослідження: недостатньо міцно закріплено кожух
4. Чому недостатньо міцно закріплено кожух?
‒ Додаткова перевірка: розбовталось кріплення
5. Чому розбовталось кріплення?
‒ Ніхто не оглядав прес останні пів року. Це і є першопричина проблеми

13. Аналіз: Fishbone diagram
• Покажіть можливі причини проблеми

14. Аналіз: Defect taxonomies
• Висновки на основі
багатьох помилок
• Дедуктивне мишлення
• Microsoft: зв’язок
помилки з класом
• Приклад: класифікація
по групам для
автоматизації

15. Аналіз: Ретроспективи
• Навчайтесь на
отриманому досвіді
• Підготовка важлива
• Починайте з позитиву
• Постійне покращення
• Ретроспектива тільки по
тестуванню – теж ок

16. Запобігання дефектів
• Продовжуйте тестувати
• Послідовно використовуйте методики знаходження
та аналізу дефектів
• Зміна процесу
• Configuration management audits
• Аналіз ризиків → Моделювання відмов (Failure
Mode and Effects Analysis, Fault Tree Analysis)
• Періодичний Root Cause Analysis → Постійний Root
Cause Analysis

17. Висновки
• Запобіганне дефектів –
прекрасна інвестиція
• Раніше залучайте QA
інженерів
• Розумно
використовуйте, щоб не
було бюрократії
• Розпочинайте з
requirements review

18. Запитання