SlideShare a Scribd company logo
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
Дякую за увагу !!!

More Related Content

PDF
Debug (ukr)
PDF
критерії оцінювання успішності навчальної роботи студентів
PDF
Anton Serputko Start performance-testing-from-scratch, BAQ
PPTX
cpp-2013 #3 OOP Basics
PPTX
Структура тест-кейсу та звіту про помилки.pptx
PPT
Lviv PMDay 2016 S Любов Самойлова: Управління вимогами у сфері проектного мен...
PPTX
ОЛЕГ ЗАРЕВИЧ «Shift left та Shift Right підходи до тестування»
PPTX
ЄВГЕН ГАЙДАЙ «Виділена команда автоматизації тестування. Досвід підтримки та ...
Debug (ukr)
критерії оцінювання успішності навчальної роботи студентів
Anton Serputko Start performance-testing-from-scratch, BAQ
cpp-2013 #3 OOP Basics
Структура тест-кейсу та звіту про помилки.pptx
Lviv PMDay 2016 S Любов Самойлова: Управління вимогами у сфері проектного мен...
ОЛЕГ ЗАРЕВИЧ «Shift left та Shift Right підходи до тестування»
ЄВГЕН ГАЙДАЙ «Виділена команда автоматизації тестування. Досвід підтримки та ...

More from Stfalcon Meetups (20)

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

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