Successfully reported this slideshow.

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

1

Share

1 of 18
1 of 18

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

1

Share

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

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

More Related Content

More from QAFest

Related Books

Free with a 14 day trial from Scribd

See all

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. Запитання

×