QA Fest 2014. Cергей Цымбал. Defect prevention

Q
Defect Prevention
Сергій Цимбал
Про себе
• Сергій Цимбал
• DENTSPLY Implants (раніше –
Materialise Dental)
– Програмне забезпечення для
медичної галузі
– Desktop
– Потенційний вплив на пацієнта
• QA Manager:
– Тест менеджмент
– Ручне тестування
– Автоматизоване тестування
– Внутрішній аудитор
• tcymbal@gmail.com
Контроль Якості → Забезпечення Якості
The practical guide to defect
prevention
Дефект, якого запобігли:
• Не потрібно
виправляти
• Покращує якість
• Не потрапить до
кінцевих користувачів
Модель запобігання дефектів
Виявлення
Аналіз та
передбачення
Запобігання
Огляд технік для виявлення та
запобігання дефектів
• QA: TestabilityСтарт проекту
• Команда: Requirements reviewВимоги готові
• Dev: Code reviewПрограмний код готовий
• QA: Test Case reviewТестування
• QA: Risk analysisОпис дефектів
• Dev: Risk analysisВиправлення дефектів
• Команда: Root cause analysisРезультати валідації
• Команда: RetrospectiveЗакінчення проекту/ітерації
Виявлення: Testability
• Тестувати ваш продукт
повинно бути просто
• Тяжко тестувати →
тяжко використовувати
• Не забувайте про
безпеку
• Приклади: логи,
макроси, унікальні ID
Виявлення: Requirements review
• Дефект у вимогах
дешевше виправити, ніж
в коді
• Що перевіряти:
– Повнота
– Правильність
– Узгодженість
– Ясність
Виявлення: Code review
• Деякі дефекти простіше
знайти під час огляду
коду, ніж під час
тестування кінцевого
продукту
• Огляд коду продукту
– Microsoft: залучення тест
інженерів
• Огляд автоматичних
тестів
Аналіз: Risk management
• Починайте тестування з
областей з найвищою
вірогідністю виникнення
дефектів
• Високий ефект вкінці
проекту
• Залучення старших
інженерів
Аналіз: Root Cause Analysis
•Виправляйте причину, а не
симптом
•Метод індукції
•Коли застосовувати:
–Beta feedback
–Service releases
–Пізно знайдені дефекти
•Типи висновків:
–Додаткові тест кейси
–Зміна тестового підходу
–Зміна процесу
Аналіз: 5 whys
5 раз запитайте, чому виникла проблема
1. Чому на підлозі під пресом знаходиться масло?
‒ Швидко подивились: протікає шланг
2. Чому масло протікає з шлангу?
‒ Дослідження: перетирається ременем вентилятору
3. Чому шланг перетирається ременем вентилятору?
‒ Додаткове дослідження: недостатньо міцно закріплено кожух
4. Чому недостатньо міцно закріплено кожух?
‒ Додаткова перевірка: розбовталось кріплення
5. Чому розбовталось кріплення?
‒ Ніхто не оглядав прес останні пів року. Це і є першопричина проблеми
Аналіз: Fishbone diagram
• Покажіть можливі причини проблеми
Аналіз: Defect taxonomies
• Висновки на основі
багатьох помилок
• Дедуктивне мишлення
• Microsoft: зв’язок
помилки з класом
• Приклад: класифікація
по групам для
автоматизації
Аналіз: Ретроспективи
• Навчайтесь на
отриманому досвіді
• Підготовка важлива
• Починайте з позитиву
• Постійне покращення
• Ретроспектива тільки по
тестуванню – теж ок
Запобігання дефектів
• Продовжуйте тестувати
• Послідовно використовуйте методики знаходження
та аналізу дефектів
• Зміна процесу
• Configuration management audits
• Аналіз ризиків → Моделювання відмов (Failure
Mode and Effects Analysis, Fault Tree Analysis)
• Періодичний Root Cause Analysis → Постійний Root
Cause Analysis
Висновки
• Запобіганне дефектів –
прекрасна інвестиція
• Раніше залучайте QA
інженерів
• Розумно
використовуйте, щоб не
було бюрократії
• Розпочинайте з
requirements review
Запитання
1 of 18

More Related Content

More from QAFest(20)

QA Fest 2014. Cергей Цымбал. Defect prevention

  • 2. Про себе • Сергій Цимбал • DENTSPLY Implants (раніше – Materialise Dental) – Програмне забезпечення для медичної галузі – Desktop – Потенційний вплив на пацієнта • QA Manager: – Тест менеджмент – Ручне тестування – Автоматизоване тестування – Внутрішній аудитор • tcymbal@gmail.com
  • 3. Контроль Якості → Забезпечення Якості
  • 4. The practical guide to defect prevention Дефект, якого запобігли: • Не потрібно виправляти • Покращує якість • Не потрапить до кінцевих користувачів
  • 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