SlideShare uma empresa Scribd logo
1 de 17
Baixar para ler offline
1
Мистецтво успішного
полювання на дефекти
Yevhenii Pasieka | Lead Test Engineer,
Quality Assurance
Skype: zerikua; linkedin: yevhenii-pasieka
2
— Ви вмієте малювати? Шкода. Я,
на жаль, теж не вмію.
Ільф і Петров,
“Дванадцять стільців”
3
4
5
6
Підходи, Методи та Техніки
7
Quick Attacks
Сильні сторони:
• Дозволяє виконувати швидкий аналіз у
стиснуті терміни.
• Дієвий спосіб познайомитися з системою,
навіть при відсутності специфікації
• Підхід для отримання розвитку і досвіду
• Швидка оцінка системи чи її компонентів.
• Спосіб виявити слабкі місця продукту.
Слабкі сторони або обмеження:
• Пошук помилок, які можуть мати низкий
рівень важливості.
• Спрощений підхід (Примітивний).
8
Equivalence and Boundary Conditions
Сильні сторони:
• Зменшення нескінченного тестового набору
(керованність тестовими наборами)
• Механізм для охоплення вимог
(Забезпечення покриття).
Слабкі сторони або обмеження:
• Недоцільно використовувати з логічними
типами данних.
• Зі збільшенням діапазону значень може
падати ефективність тестів
9
Common Failure Modes
Сильні сторони:
• Допомагає виявити загальні проблеми для
платформи, проекту або команди.
• Дозволяє швидко реагувати на повторювані
дефекти.
Слабкі сторони або обмеження:
• З плином часу втрачає свою ефективність.
• Підхід тісно переплітається з наявним
досвідом команди.
10
State-Transition Diagrams
Сильні сторони:
• Наочне або табличне представлення
поведінки системи, що дозволяє перевірити
рівень охоплення проілюстрованих умов.
• Експертиза на снові командної оцінки
діаграм допомагає знайти прогалини вимог,
дефекти і різні очікування серед членів
команди.
Слабкі сторони або обмеження:
• Наочне або табличне представлення може
не відображати, як працює програмне
забезпечення насправді.
• Ілюзію достовірності
• Для великих систем складно зобразити усі
стани системи.
11
Soap Opera Tests
Сильні сторони:
• Підхід “Soap Opera “ дозволяє уникати
покрокових інструкцій з очікуванним
результатом.
• “Історії” дозволяють збільшити свободу і
зменьшити обсяг тестів.
• Підхід для виялення непередбачених
проблем на основі гіперболізованих
(перебільшенних, драматичних) сценаріїв
• Підхід дозволяє у стиснуті терміни
випробувати велику кількість
функціональних аспектів системи
Слабкі сторони або обмеження:
• Залежить тільки від навичок творця.
• Часто потребує взаємодії з досвідченими
користувачами.
12
Use Cases
Сильні сторони:
• Візуалізація взаємодії між актором і
системою від початку і до кінця, для
досягнення конкретної задачі.
• Дієвий спосіб виявити дефекти інтеграції.
• Опис набільшімовірного використання
системи, включаючи основний і додаткові
(альтернативні) сценарії.
• Включає передумови, післяумови та опис
кінцевого стану системи.
Слабкі сторони або обмеження:
• Погано підходять для документування
вимог не заснованих на взаємодії з
системою (таких як алгоритм або
математичні вимоги) або нефункціональних
вимог (такі як платформа, продуктивність,
синхронізація, безпека).
• Залежить тільки від навичок творця.
• Формальний тип документів
13
Code-Based Coverage Models
Сильні сторони:
• Перевірка коду що дозволяє оцінити
відсоток покриття операторів (тверджень) а
також покриття умов.
Слабкі сторони або обмеження:
• Потребує спеціальних навичок або знань
• Не гарантує що вся логіка буде перевірена.
• Забезспечує не повне покриття.
14
Regression and High-Volume Test Techniques
Сильні сторони:
• Сбір і аналіз повторюваних результатів
• Ефективний підхід оцінки ризиків
пов'язаних зі змінами.
• Підхід що дозволяє порівнювати поведінку
програмного забезпечення для різних
версій.
Слабкі сторони або обмеження:
Ресурсномісткі техніки.
Потребують автоматизації і роботизації.
Необхідне покритя тестами навіть при
незначних змінах у коді.
15
Поєднання методів
16
17
Дякую за увагу !!!

Mais conteúdo relacionado

Mais de Stfalcon Meetups

Conversion centered design 3
Conversion centered design 3Conversion centered design 3
Conversion centered design 3Stfalcon Meetups
 
Stfalcon QA Meetup 31.01.2020
Stfalcon QA Meetup 31.01.2020Stfalcon QA Meetup 31.01.2020
Stfalcon QA Meetup 31.01.2020Stfalcon Meetups
 
Design of the_future_30_05_2019
Design of the_future_30_05_2019Design of the_future_30_05_2019
Design of the_future_30_05_2019Stfalcon Meetups
 
Global sales - a few insights
Global sales - a few insightsGlobal sales - a few insights
Global sales - a few insightsStfalcon Meetups
 
How to build your own startup
How to build your own startupHow to build your own startup
How to build your own startupStfalcon Meetups
 
Первая и последняя встреча с клиентом
Первая и последняя встреча с клиентом Первая и последняя встреча с клиентом
Первая и последняя встреча с клиентом Stfalcon Meetups
 
Парнерство нидерланды
Парнерство нидерландыПарнерство нидерланды
Парнерство нидерландыStfalcon Meetups
 
Риси гарного менеджера
Риси гарного менеджераРиси гарного менеджера
Риси гарного менеджераStfalcon Meetups
 
Между заказчиком и разработчиком
Между заказчиком и разработчикомМежду заказчиком и разработчиком
Между заказчиком и разработчикомStfalcon Meetups
 
майстер-клас “Управління ризиками”
майстер-клас “Управління ризиками”майстер-клас “Управління ризиками”
майстер-клас “Управління ризиками”Stfalcon Meetups
 
Kubernetes: від знайомства до використання у CI/CD
Kubernetes: від знайомства до використання у CI/CDKubernetes: від знайомства до використання у CI/CD
Kubernetes: від знайомства до використання у CI/CDStfalcon Meetups
 
Як ефективно працювати в мережі LinkedIn
Як ефективно працювати в мережі LinkedInЯк ефективно працювати в мережі LinkedIn
Як ефективно працювати в мережі LinkedInStfalcon Meetups
 

Mais de Stfalcon Meetups (20)

Conversion centered design 3
Conversion centered design 3Conversion centered design 3
Conversion centered design 3
 
Discovery phase
Discovery phaseDiscovery phase
Discovery phase
 
Stfalcon QA Meetup 31.01.2020
Stfalcon QA Meetup 31.01.2020Stfalcon QA Meetup 31.01.2020
Stfalcon QA Meetup 31.01.2020
 
Stfalcon PM Meetup 21.11
Stfalcon PM Meetup 21.11Stfalcon PM Meetup 21.11
Stfalcon PM Meetup 21.11
 
Stfalcon PM Meetup 21.11
Stfalcon PM Meetup 21.11Stfalcon PM Meetup 21.11
Stfalcon PM Meetup 21.11
 
Design of the_future_30_05_2019
Design of the_future_30_05_2019Design of the_future_30_05_2019
Design of the_future_30_05_2019
 
2 5404811386729530203
2 54048113867295302032 5404811386729530203
2 5404811386729530203
 
Team evolution
Team evolutionTeam evolution
Team evolution
 
Mobile&Privacy
Mobile&PrivacyMobile&Privacy
Mobile&Privacy
 
Global sales - a few insights
Global sales - a few insightsGlobal sales - a few insights
Global sales - a few insights
 
How to build your own startup
How to build your own startupHow to build your own startup
How to build your own startup
 
Первая и последняя встреча с клиентом
Первая и последняя встреча с клиентом Первая и последняя встреча с клиентом
Первая и последняя встреча с клиентом
 
Парнерство нидерланды
Парнерство нидерландыПарнерство нидерланды
Парнерство нидерланды
 
Риси гарного менеджера
Риси гарного менеджераРиси гарного менеджера
Риси гарного менеджера
 
Между заказчиком и разработчиком
Между заказчиком и разработчикомМежду заказчиком и разработчиком
Между заказчиком и разработчиком
 
Cv vs resume
Cv vs resumeCv vs resume
Cv vs resume
 
Vue.js
Vue.jsVue.js
Vue.js
 
майстер-клас “Управління ризиками”
майстер-клас “Управління ризиками”майстер-клас “Управління ризиками”
майстер-клас “Управління ризиками”
 
Kubernetes: від знайомства до використання у CI/CD
Kubernetes: від знайомства до використання у CI/CDKubernetes: від знайомства до використання у CI/CD
Kubernetes: від знайомства до використання у CI/CD
 
Як ефективно працювати в мережі LinkedIn
Як ефективно працювати в мережі LinkedInЯк ефективно працювати в мережі LinkedIn
Як ефективно працювати в мережі LinkedIn
 

Stfalcon QA Meetup 31.01.2020

  • 1. 1 Мистецтво успішного полювання на дефекти Yevhenii Pasieka | Lead Test Engineer, Quality Assurance Skype: zerikua; linkedin: yevhenii-pasieka
  • 2. 2 — Ви вмієте малювати? Шкода. Я, на жаль, теж не вмію. Ільф і Петров, “Дванадцять стільців”
  • 3. 3
  • 4. 4
  • 5. 5
  • 7. 7 Quick Attacks Сильні сторони: • Дозволяє виконувати швидкий аналіз у стиснуті терміни. • Дієвий спосіб познайомитися з системою, навіть при відсутності специфікації • Підхід для отримання розвитку і досвіду • Швидка оцінка системи чи її компонентів. • Спосіб виявити слабкі місця продукту. Слабкі сторони або обмеження: • Пошук помилок, які можуть мати низкий рівень важливості. • Спрощений підхід (Примітивний).
  • 8. 8 Equivalence and Boundary Conditions Сильні сторони: • Зменшення нескінченного тестового набору (керованність тестовими наборами) • Механізм для охоплення вимог (Забезпечення покриття). Слабкі сторони або обмеження: • Недоцільно використовувати з логічними типами данних. • Зі збільшенням діапазону значень може падати ефективність тестів
  • 9. 9 Common Failure Modes Сильні сторони: • Допомагає виявити загальні проблеми для платформи, проекту або команди. • Дозволяє швидко реагувати на повторювані дефекти. Слабкі сторони або обмеження: • З плином часу втрачає свою ефективність. • Підхід тісно переплітається з наявним досвідом команди.
  • 10. 10 State-Transition Diagrams Сильні сторони: • Наочне або табличне представлення поведінки системи, що дозволяє перевірити рівень охоплення проілюстрованих умов. • Експертиза на снові командної оцінки діаграм допомагає знайти прогалини вимог, дефекти і різні очікування серед членів команди. Слабкі сторони або обмеження: • Наочне або табличне представлення може не відображати, як працює програмне забезпечення насправді. • Ілюзію достовірності • Для великих систем складно зобразити усі стани системи.
  • 11. 11 Soap Opera Tests Сильні сторони: • Підхід “Soap Opera “ дозволяє уникати покрокових інструкцій з очікуванним результатом. • “Історії” дозволяють збільшити свободу і зменьшити обсяг тестів. • Підхід для виялення непередбачених проблем на основі гіперболізованих (перебільшенних, драматичних) сценаріїв • Підхід дозволяє у стиснуті терміни випробувати велику кількість функціональних аспектів системи Слабкі сторони або обмеження: • Залежить тільки від навичок творця. • Часто потребує взаємодії з досвідченими користувачами.
  • 12. 12 Use Cases Сильні сторони: • Візуалізація взаємодії між актором і системою від початку і до кінця, для досягнення конкретної задачі. • Дієвий спосіб виявити дефекти інтеграції. • Опис набільшімовірного використання системи, включаючи основний і додаткові (альтернативні) сценарії. • Включає передумови, післяумови та опис кінцевого стану системи. Слабкі сторони або обмеження: • Погано підходять для документування вимог не заснованих на взаємодії з системою (таких як алгоритм або математичні вимоги) або нефункціональних вимог (такі як платформа, продуктивність, синхронізація, безпека). • Залежить тільки від навичок творця. • Формальний тип документів
  • 13. 13 Code-Based Coverage Models Сильні сторони: • Перевірка коду що дозволяє оцінити відсоток покриття операторів (тверджень) а також покриття умов. Слабкі сторони або обмеження: • Потребує спеціальних навичок або знань • Не гарантує що вся логіка буде перевірена. • Забезспечує не повне покриття.
  • 14. 14 Regression and High-Volume Test Techniques Сильні сторони: • Сбір і аналіз повторюваних результатів • Ефективний підхід оцінки ризиків пов'язаних зі змінами. • Підхід що дозволяє порівнювати поведінку програмного забезпечення для різних версій. Слабкі сторони або обмеження: Ресурсномісткі техніки. Потребують автоматизації і роботизації. Необхідне покритя тестами навіть при незначних змінах у коді.
  • 16. 16