Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.
Defect Prevention
Сергій Цимбал
Про себе
• Сергій Цимбал
• DENTSPLY Implants (раніше –
Materialise Dental)
– Програмне забезпечення для
медичної галузі
– ...
Контроль Якості → Забезпечення Якості
The practical guide to defect
prevention
Дефект, якого запобігли:
• Не потрібно
виправляти
• Покращує якість
• Не потрапит...
Модель запобігання дефектів
Виявлення
Аналіз та
передбачення
Запобігання
Огляд технік для виявлення та
запобігання дефектів
• QA: TestabilityСтарт проекту
• Команда: Requirements reviewВимоги гот...
Виявлення: Testability
• Тестувати ваш продукт
повинно бути просто
• Тяжко тестувати →
тяжко використовувати
• Не забувайт...
Виявлення: Requirements review
• Дефект у вимогах
дешевше виправити, ніж
в коді
• Що перевіряти:
– Повнота
– Правильність
...
Виявлення: Code review
• Деякі дефекти простіше
знайти під час огляду
коду, ніж під час
тестування кінцевого
продукту
• Ог...
Аналіз: Risk management
• Починайте тестування з
областей з найвищою
вірогідністю виникнення
дефектів
• Високий ефект вкін...
Аналіз: Root Cause Analysis
•Виправляйте причину, а не
симптом
•Метод індукції
•Коли застосовувати:
–Beta feedback
–Servic...
Аналіз: 5 whys
5 раз запитайте, чому виникла проблема
1. Чому на підлозі під пресом знаходиться масло?
‒ Швидко подивились...
Аналіз: Fishbone diagram
• Покажіть можливі причини проблеми
Аналіз: Defect taxonomies
• Висновки на основі
багатьох помилок
• Дедуктивне мишлення
• Microsoft: зв’язок
помилки з класо...
Аналіз: Ретроспективи
• Навчайтесь на
отриманому досвіді
• Підготовка важлива
• Починайте з позитиву
• Постійне покращення...
Запобігання дефектів
• Продовжуйте тестувати
• Послідовно використовуйте методики знаходження
та аналізу дефектів
• Зміна ...
Висновки
• Запобіганне дефектів –
прекрасна інвестиція
• Раніше залучайте QA
інженерів
• Розумно
використовуйте, щоб не
бу...
Запитання
Upcoming SlideShare
Loading in …5
×

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

671 views

Published on

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

Published in: Technology
  • Be the first to comment

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

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

×