Процес забезпечення якості програмних продуктів

01/29/15 Prepared by Lesya Symanyshyn
Test ProcessTest Process
FrameworkFramework
ППроцесроцес забезпечення якостізабезпечення якості
програмого забезпеченняпрограмого забезпечення
Prepared by Lesya Symanyshyn

01/29/15
Тестування в вузькому іТестування в вузькому і
широкому сенсіширокому сенсі
 Тестування у вузькому сенсі, або -Тестування у вузькому сенсі, або -
динамічне тестування, має на метідинамічне тестування, має на меті
виконання програмного коду (програмноговиконання програмного коду (програмного
продукту)продукту)
 Тестування в широкому сенсі частоТестування в широкому сенсі часто
називають верифікацією; воно включає іназивають верифікацією; воно включає і
інші методи (наприклад, переглядінші методи (наприклад, перегляд
програмного коду)програмного коду)
Ми розглянемо поняття верифікації, але будемо користуватися, в
основному, першим значенням терміну ‘тестування’

01/29/15
Відладка не є тестуваннямВідладка не є тестуванням
Відладка спрямована на встановлення точної природиВідладка спрямована на встановлення точної природи
відомої помилкивідомої помилки
Відладку розуміють як процес виправлення помилок,Відладку розуміють як процес виправлення помилок,
факт наявності яких встановлюється при тестуванніфакт наявності яких встановлюється при тестуванні

01/29/15
ВерифікаціяВерифікація
Щоб зрозуміти, що щось наступило, потрібноЩоб зрозуміти, що щось наступило, потрібно
вміти його вимірятивміти його виміряти
Енді Грув, корпорація ІнтелЕнді Грув, корпорація Інтел
 Верифікація («чи правильно миВерифікація («чи правильно ми
робимо?»)робимо?»)
 верифікаця продуктуверифікаця продукту:: критерії готовностікритерії готовності
((readiness criteria)readiness criteria)
 верифікація діяльностіверифікація діяльності: критерїї: критерїї
завершення (завершення (exit criteria)exit criteria)

01/29/15
Верифікація і валідаціяВерифікація і валідація
 ВерифікаціяВерифікація
 verusverus правильнийправильний => “правильність”=> “правильність”
 Відповідає на питання:Відповідає на питання: «чи правильно ми«чи правильно ми
робимо роботу?»робимо роботу?»
 ВалідаціяВалідація
 validusvalidus здоровийздоровий => “користь, цінність”=> “користь, цінність”
 Відповідає на питання:Відповідає на питання: «чи правильну роботу«чи правильну роботу
ми робимо?»ми робимо?»

01/29/15
Верифікація і валідаціяВерифікація і валідація
 ІSО 9000/2000 (не тільки програмний продукт):ІSО 9000/2000 (не тільки програмний продукт):
 Верифікація – перевірка продукту на відповідністьВерифікація – перевірка продукту на відповідність
вхідним данимвхідним даним (~проектним вимогам, специфікаціям)(~проектним вимогам, специфікаціям)
 Валідація – перевірка продукту на відповідністьВалідація – перевірка продукту на відповідність
потребам користувачапотребам користувача
верифікація
Потреби
користувача
Вхідні дані
Вихідні
дані
Проектування і
розробка
валідація

01/29/15
РозробкаРозробка
Статистичні і динамічні методиСтатистичні і динамічні методи
Вимоги Реалізація
Testing:
dynamic techniques
Архітектура Проектування
Verification:
static techniques
Technical Reviews, Formal Inspections,
Walkthroughs, Desk checks, Audits
Впровадження
Unit/Integration testing,
Prototype/Intermediate release testing,
Subsystem and System testing

01/29/15
Ціль тестуванняЦіль тестування
Загальноприйняте визначення:Загальноприйняте визначення:
 Ціль тестування – знизитиЦіль тестування – знизити
невизначеність нашогоневизначеність нашого
уявлення про якістьуявлення про якість
програмного продуктупрограмного продукту
 Іншими словами, виявитиІншими словами, виявити
помилки до того, як цепомилки до того, як це
зробить замовникзробить замовник

01/29/15
Ціль тестуванняЦіль тестування
(інше визначення)(інше визначення)
Більш широке визначення:Більш широке визначення:
 Ціль тестування – розпізнати дефекти в об`єктіЦіль тестування – розпізнати дефекти в об`єкті
тестування і збільшити імовірність того, що він притестування і збільшити імовірність того, що він при
будь-яких обставинах буде працювати належнимбудь-яких обставинах буде працювати належним
чином у відповідності з визначеними вимогамичином у відповідності з визначеними вимогами
 Роль тестування полягає в отриманні обєктивноїРоль тестування полягає в отриманні обєктивної
інформації, що допомагає приймати більш якісніінформації, що допомагає приймати більш якісні
ділові рішення.ділові рішення.
 Роль тестування – тримати в курсі всіх проблем, щоРоль тестування – тримати в курсі всіх проблем, що
мають відношеня до поставки продуктумають відношеня до поставки продукту

01/29/15
Тестування незалежне. Що цеТестування незалежне. Що це
означає?означає?
 Розробники ніколи не відповідають заРозробники ніколи не відповідають за
тестування (за виключенням unit testing)тестування (за виключенням unit testing)
 Тестові критеріТестові критеріїї визначаються довизначаються до
початкупочатку запуску тестуваннязапуску тестування
 Тести розробляються з вимогТести розробляються з вимог
 Дефекти повинні бути задокументованіДефекти повинні бути задокументовані

01/29/15
Анатомія тестуванняАнатомія тестування
develop
product
test
failures?
better
product
fix
test
failures?
product
раунд тестування
виправлень
Failure – розходження з потрібними результатами
Fix/debug – пошук помилок в продукті (причин) і їх виправлення
fix
No failures!
циклцикл тестуваннятестування

01/29/15
Варіації доробокВаріації доробок
Func design
Design
Build
Build
changed
product
changed
product
Design
Build
changed
product
‘failed’
product
‘failed’
product
‘failed’
product
Design
cause of
failure
Func design
Fix1:
Fix2: Fix3:
changed
product
Requirements
cause of
failure
cause of
failure
 FixFix11 ---- вада в коді програми; переробляється тільки кодвада в коді програми; переробляється тільки код
 FixFix22 ---- вада в специфікаціях (технічний дизайн); зміюються івада в специфікаціях (технічний дизайн); зміюються і
специфікації, і кодспецифікації, і код
 FixFix33 ---- вада в архітектурі/функціональному дизайні; звада в архітектурі/функціональному дизайні; зммінюєтьсяінюється
архітектура, специфікації і кодархітектура, специфікації і код

01/29/15
Тестування в V-моделіТестування в V-моделі
Requirements
Design
Construction
TestingDevelopment
Unit tests
Integration tests
Acceptance test
Architecture System test
fix1
fix2
fix4
fix3

01/29/15
Доробка як покращенняДоробка як покращення
 V-модель:V-модель:
 доробка = «систематичне виправлення»доробка = «систематичне виправлення»
 виникає «передбачено» (рівень), але часто звиникає «передбачено» (рівень), але часто з
запізненнямзапізненням ……
 Ітеративна/еволюційна модель:Ітеративна/еволюційна модель:
 доробка = «покращення» (increment,доробка = «покращення» (increment,
enhancement)enhancement)
 є маленьким каскадом, абоє маленьким каскадом, або ітерацієюітерацією

01/29/15
Доробка як покращенняДоробка як покращення
продукт
Покращений
продукт
вимоги
проектування
реалізація
тестування
з попередньої
ітерації
На наступну ітерацію
ітерація

01/29/15
Фази в традиційномуФази в традиційному
іітеративному ЖЦтеративному ЖЦ
 Традиційний ЖЦТрадиційний ЖЦ
 вважається, що певна діяльність повинна завершитись,вважається, що певна діяльність повинна завершитись,
перш ніж почнеться інша (Requirements, згодом Design,перш ніж почнеться інша (Requirements, згодом Design,
потім Implementation…)потім Implementation…)
 В кожній фазі рівно один вид діяльності; фазиВ кожній фазі рівно один вид діяльності; фази
іменуються у відповідності з ниміменуються у відповідності з ним
 Ітеративний ЖЦІтеративний ЖЦ
 кожна фаза включає, так би мовити, всі види діяльності (вкожна фаза включає, так би мовити, всі види діяльності (в
різних пропорціях)різних пропорціях)
 Назва фази вказує не на вид діяльності, а на стан, в якоміНазва фази вказує не на вид діяльності, а на стан, в якомі
знаходиться проектзнаходиться проект

01/29/15
Тест-проектування в V-моделіТест-проектування в V-моделі
Requirements
Design
Construction
Test execution
Development
Unit tests
Integration tests
Acceptance test
Architecture System test
Acceptance test design
System test design
Integration test design
Unit test design
Test design

01/29/15
Фази проекту і склад робіт поФази проекту і склад робіт по
тестуваннітестуванні
InceptionInception
 test strategy (optional)test strategy (optional)
 acceptance criteria and proceduresacceptance criteria and procedures
ElaborationElaboration
Requirements:Requirements:
 test strategytest strategy
 study, review Reqsstudy, review Reqs
 outline test planoutline test plan
Architecture (Design 1):Architecture (Design 1):
 study specificationsstudy specifications
 draft test plandraft test plan
 design test datadesign test data
Construction
Design 2, Implementation
- detail/refine test plan
- prepare/revise test data
- develop automatic test suites
(e.g. build acceptance suite)
System Testing
- perform testing rounds
- perform documentation testing
Acceptance Testing

01/29/15
Rational Unified ProcessRational Unified Process
 Інженерна (дослідницька)Інженерна (дослідницька)
 завершується, коли є розуміння, ЯК робити продуктзавершується, коли є розуміння, ЯК робити продукт
(архітектура)(архітектура)
 ВиробничаВиробнича
 Полягає в осоновному в виготовленні продуктуПолягає в осоновному в виготовленні продукту
Рубіж між стадіями – головний рубіж проектуРубіж між стадіями – головний рубіж проекту
 Співвідношення термінів і ресурсів між стадіямиСпіввідношення термінів і ресурсів між стадіями
визначається специфікою проектувизначається специфікою проекту
Дві основні стадії ЖЦДві основні стадії ЖЦ
Чітка межа і оптимальний баланс між двома стадіямиЧітка межа і оптимальний баланс між двома стадіями
характерні для більшості успішних проектівхарактерні для більшості успішних проектів

01/29/15
Rational Unified ProcessRational Unified Process
час
ГоловніГоловні
рубежірубежі
Інженерна
стадія
Виробнича
стадія
Концепт.
проробка
Ескізна
проробка Реалізація Впровадження
Основний результатОсновний результат
кожної фазикожної фази
 Inception: концепція = зрозуміло, ЩО потрібно зробитиInception: концепція = зрозуміло, ЩО потрібно зробити
 Elaboration: архітектура = зрозуміло, ЯК зробитиElaboration: архітектура = зрозуміло, ЯК зробити
 Construction: повноцінний продукт розробки («бета»)Construction: повноцінний продукт розробки («бета»)
 TransitionTransition: відшліфований продукт у Замовника: відшліфований продукт у Замовника
Чотири фазиЧотири фази, ортогональні циклу розробки, ортогональні циклу розробки

01/29/15
Тестування
Реалізація
Пректування
Вимоги
TransitionConstructionInception Elaboration
Основніінже
Фаза
Rational Unified
Process (RUP)
Показує, КОЛИ ми виконуємо якусь роботу

01/29/15
Основніін Rational Unified
Process (RUP)
Показує,ЯКОГ
виконується
Проектування
Вимоги
Фаза

01/29/15
Rational Unified
Process (RUP)
Планування
Встановлення
інструментів
Докладний план-
графік
Стратегія
Драфт тест-
плану
Підготовка
тестового
середовища
Перегляд вимог
Приймально-
здавальні
випробуваня
Аналіз дефектів,
виявлених в ході
приймально-
здавальних
вимог
Уточнення плану
регресивного
тестів
Підготовка
тестових даних
Автоматизація
Проведення
Відстежування
дефектів
Фаза
Основніінж
Вимоги

01/29/15
Iterations achieveIterations achieve
demonstrable resultsdemonstrable results
Proof-of-concept prototypeProof-of-concept prototype
Architectural prototypeArchitectural prototype
Alpha release (all critical use cases)Alpha release (all critical use cases)
Beta releaseBeta release
FinalFinal
productproduct
Inception
Elaboration
Construction
Transition

01/29/15
Ітерація - каскадний «підпроект»Ітерація - каскадний «підпроект»
Запланований «шар»Запланований «шар»
функціональностіфункціональності
Результати з попередньоїРезультати з попередньої
ітераціїітерації
Результати дляРезультати для
наступної ітераціїнаступної ітерації
Основні інженерні процеси
Керування вимогами

01/29/15
Виконання тестів
Анатомія типової ітераціїАнатомія типової ітерації
всередині ЖЦвсередині ЖЦ
Минула
ітерація
Наступна
ітерація
Поточна ітерація
Пректування Реалізація
План
ітерації
План
версія версія
test
results
test
results
Оцінка
проміжного
продукту
Деталізація
Критерії
оцінки
Рішення про завершення
ітерації і її оцінка
Стратегія
разробки і
Функціональна
добавка

01/29/15
Варіації моделей ЖЦВаріації моделей ЖЦ
Спіральна і ітеративна моделі є найбільш загальними в рамках описання процесуСпіральна і ітеративна моделі є найбільш загальними в рамках описання процесу
розробкирозробки
Декілька відомих моделей є їхніми частинними випадкамиДекілька відомих моделей є їхніми частинними випадками
 incremental developmentincremental development
 кожна наступна ітерація нарощує функціонаьністькожна наступна ітерація нарощує функціонаьність
 progressive buildprogressive build (частинний випадок попереднього)(частинний випадок попереднього)
 аналіз вимог виконується один раз; кожна наступна ітерація нарощуєаналіз вимог виконується один раз; кожна наступна ітерація нарощує
функціональністьфункціональність
 прототипуванняпрототипування
 в першій ітерації будується прототип майбутнього продукту, виконується якв першій ітерації будується прототип майбутнього продукту, виконується як
proof-of-conceptproof-of-concept і потім викидається; основна ціль: уточнити у Замовникаі потім викидається; основна ціль: уточнити у Замовника
вимоги шляхом демонстраціївимоги шляхом демонстрації
 наступна ітерація може бути архітектурним прототипом і т.д.наступна ітерація може бути архітектурним прототипом і т.д.

01/29/15
Ціна якостіЦіна якості
Складові затрат на якістьСкладові затрат на якість::
 затрати на попередні заходизатрати на попередні заходи
 наприклад, побудова інженерних процесів по CMMнаприклад, побудова інженерних процесів по CMM
 затрати на виявлення дефектівзатрати на виявлення дефектів
 затрати на коректуючі заходи (включаючи втрати від випускузатрати на коректуючі заходи (включаючи втрати від випуску
неякісного продукту):неякісного продукту):
 внутрішні:внутрішні:
 виправлення дефектів, знайдених при тестуваннівиправлення дефектів, знайдених при тестуванні
 Втрати від цього всередині Компанії (додаткове регресивне тестування, втратиВтрати від цього всередині Компанії (додаткове регресивне тестування, втрати
і втрачена вигода від пізного випусу продукту, моральний клімат і т.д.)і втрачена вигода від пізного випусу продукту, моральний клімат і т.д.)
 зовнішні:зовнішні:
 витрати на додаткове обслуговування, аналіз рекламаційвитрати на додаткове обслуговування, аналіз рекламацій
 втрати від претензій і позовів клієнтів (в тому числі додаткова розробка івтрати від претензій і позовів клієнтів (в тому числі додаткова розробка і
тестування, шкоду іміджу і т. д.)тестування, шкоду іміджу і т. д.)

01/29/15
Ціна якостіЦіна якості
Рівень якості
Затрати
на попередження і
виявлення
на виправлення,
плюс втрати від
залишкових дефектів
мінімум
затрат
Сумарні затрати на
якість
неякісний продукт: високі
втрати від рекламацій
Бездоганний продукт: високі
затрати на тестування

01/29/15
Основне питання тестуванняОсновне питання тестування
Відповідь: трохи менше ніж дуже багато.Відповідь: трохи менше ніж дуже багато.
Із фольклору тестувальниківІз фольклору тестувальників
Який об’єм тестування достатній?
Коли продукт готовий до випуску?
Аналогія для роздумів:
Який об’єм лікування достатній?
Коли пацієнт готовий до виписки?
ПитанняПитання: Скільки потрібно тестувати?: Скільки потрібно тестувати?

01/29/15
Коли закінчувати тестування?Коли закінчувати тестування?
Тестування потрібно продовжувати до того часу,Тестування потрібно продовжувати до того часу,
поки витрати на пошук і виправлення дефектівпоки витрати на пошук і виправлення дефектів
НИЖЧІ, ніж майбутні втрати від збоївНИЖЧІ, ніж майбутні втрати від збоїв
продукту при його експлуатаціїпродукту при його експлуатації
ТТіім Комен, Мартм Комен, Мартіін Пол, 1999н Пол, 1999

01/29/15
Різні класифікації тестуванняРізні класифікації тестування
 Виконується або не виконується програмний кодВиконується або не виконується програмний код
 статичне & динамічнестатичне & динамічне
 підкласифікація статичних методівпідкласифікація статичних методів
 Використовується чи ні знання про спосіб реалізаціїВикористовується чи ні знання про спосіб реалізації
 Чорний ящик & прозорий ящикЧорний ящик & прозорий ящик
 за «рівнем»за «рівнем»
 unit, integration, subsystem, system, beta, acceptanceunit, integration, subsystem, system, beta, acceptance
 за властивостями об’єкта тестуванняза властивостями об’єкта тестування
 функціональність, продуктивність, сумісність, надійність, зручністьфункціональність, продуктивність, сумісність, надійність, зручність
 за природою об’єкта тестуванняза природою об’єкта тестування
 mainframe, client-server, Web , real-time, scientific, E-businessmainframe, client-server, Web , real-time, scientific, E-business

01/29/15
Рівні тестуванняРівні тестування
 АвтономнеАвтономне
 окремі модуліокремі модулі
 ІнтеграційнеІнтеграційне
 стиковка модулейстиковка модулей
 «Підсистемне»«Підсистемне»
 проміжний випускпроміжний випуск
 функціональнийфункціональний
компоненткомпонент
 «інкремент»«інкремент»
 СистемнеСистемне
 ПриймальнеПриймальне
 база тестування -база тестування -
дизайн, внутрішнідизайн, внутрішні
інтерфейсиінтерфейси
 mainly developersmainly developers
 white & black boxwhite & black box
 покриття кодупокриття коду
компонентнекваліфікацій
 база тестування –база тестування –
зовнішні функціїзовнішні функції
 mainly testersmainly testers
 black boxblack box
 покриття вимогпокриття вимог

01/29/15
Рівні тестуванняРівні тестування
модуль
модуль
готовий
модуль
компонент
підсистема
система
Автономне
Прийняття
готових модулів
Інтеграційне
тестування Тестування
підсистем Системне

01/29/15
Проводиться розробниками після того, як завершена розробка коду модулів/блоків.
Тестування виконується вкінці робіт по створенню певного модуля. Програміст проводить
тестування, щоб преесвідчитись, що він закінчив виконання завдання - критерій завершення
задоволений. Комбінація методів прозороо і чорного ящиків..
Тестування проводиться, коли проходить інтеграція декількох модулів в в більші
компоненти. Відбувається обєднання модулів, а для тимчасово відсутніх компонентів
системи створюються заглушки. Для імітації оточення компонентів створюються тест-
драйвери. Сірий ящик.
Системное
Сопро-
вождение
Рівеньтестуван
Система інтегрована повністю. Проведено повне функціональне тестування.
Група розробки зайнята виправленням дефектів, виявлених в ході тестування.
Регресивне тестування.
Чорний ящик
Замовник проводить власне тестування, щоб пересвідчитись, що система задовільняє
вимогам. Заазвичай план приймально-здавальних випробувань відомий тільки групі
системного тестування зарання. «Валідація».
Проводиться ненавязливе тестування системи в ході експлуатації для вимірювання
параметрів якості, в тому числі продуктивність, використання системних ресурсів, а також
для визначення коректуючих дій.
Система розбита на функціональні (або архітектурні) частини або шари, які тестуються
окремо. Кожна із них «кваліфікується» у відповідності з обємом функціональності, яку вона
реалізує. Можливе використання тест-драйверів. Регресивне тестування. Чорний ящик.
Інтеграційне
Автономне
Системне
Приймально-
здавальні
випробування
Супровід
«Підсистемне»
Характеристика рівнів тестуванняХарактеристика рівнів тестування

01/29/15
Заглушки і тест-драйвериЗаглушки і тест-драйвери
 Тест-драйвер замінює ту частину системиТест-драйвер замінює ту частину системи
(або внутрішнього середовища), яка(або внутрішнього середовища), яка
викликає обєкт тестуваннявикликає обєкт тестування
 Забезпечує передачу вхідних даних вЗабезпечує передачу вхідних даних в
обєкт тестуванняобєкт тестування
 відображає результати виклику абовідображає результати виклику або
перевіряє їх правильністьперевіряє їх правильність
 Заглушка замінює частину системи, щоЗаглушка замінює частину системи, що
викликаєтьсявикликається обоб’’єктом тестуванняєктом тестування
 має той же інтерфейс (має той же інтерфейс (API),API), що і частина,що і частина,
що замінюєтьсящо замінюється
 Повертає результат такого ж типуПовертає результат такого ж типу
обєкт
драйвер
обєкт
заглушка

01/29/15
Заглушки і тест-драйвериЗаглушки і тест-драйвери
 Тест-драйвери і заглушки НЕ в повній міріТест-драйвери і заглушки НЕ в повній мірі
імітують поведінку компонентів, яких неімітують поведінку компонентів, яких не
вистачаєвистачає
 На розробку (і тестування!) тих і іншихНа розробку (і тестування!) тих і інших
потрібні додаткові ресурси, що можепотрібні додаткові ресурси, що може
зробити їх невиправданимизробити їх невиправданими

01/29/15
Типи тестування за якостямиТипи тестування за якостями
продуктупродукту
Функціональне тестування
відповідність (під)системи зовнішнім специфікаціям
Тестування зручності користування
Тестування продуктивності (навантажувальне)
Швидкість відповіді системи під навантаженням
Тестування встановлення
правильність і зручність встановлення системи на цільові платформи
Конфігураційне тестування
Сумісність з різними типами обладнання і ПЗ (напр., принтерами,
навігаторами)
Робота в різних операційних середовищах/на різних платформах
 Найбільш розповсюджені типи тестуванняНайбільш розповсюджені типи тестування

01/29/15
Підпроект тестуванняПідпроект тестування
Тестування -- підпроект в рамках проекту розробкиТестування -- підпроект в рамках проекту розробки
 має відносну самостійність (незалежність тестування)має відносну самостійність (незалежність тестування)
 Являє собою окремий проект, якщо виконуєтьсяЯвляє собою окремий проект, якщо виконується
незалежною організацієюнезалежною організацією
 тест-менеджер -- менеджер підпроекту тестуваннятест-менеджер -- менеджер підпроекту тестування
 група тестування під його управлінням виконує всігрупа тестування під його управлінням виконує всі
роботи по тестуванюроботи по тестуваню

01/29/15
Види робіт при тестуванніВиди робіт при тестуванні
 Планування і керуванняПланування і керування
 Специфікація/проектуванняСпецифікація/проектування
 Підготовка середовища і засобів тестуванняПідготовка середовища і засобів тестування
 Виконання тестівВиконання тестів
 Аналіз і звітністьАналіз і звітність
 РецензуванняРецензування

01/29/15
Група тестування: ролі і обов’язкиГрупа тестування: ролі і обов’язки
 Тест-менеджерТест-менеджер
 стратегія тестуваннястратегія тестування
 планування і керуванняпланування і керування
 Тест-проектувальникТест-проектувальник
 розробка тестових сценаріїв і тестіврозробка тестових сценаріїв і тестів
 проектування тестових данихпроектування тестових даних
 проектування тест-драйверівпроектування тест-драйверів
 ТестувальникТестувальник
 підготовка тестових данихпідготовка тестових даних
 виконання тестіввиконання тестів
 автоматизація тестування (скріпти)автоматизація тестування (скріпти)
 bug/trouble reportsbug/trouble reports
 ПрограмістПрограміст
 розробка тест-драйверів, генераторів даних і ін.розробка тест-драйверів, генераторів даних і ін.

01/29/15
Функції тест-менеджераФункції тест-менеджера
 На початковій фазі проектуНа початковій фазі проекту
 розробляє/аналізує/узгоджує з керівникрм проекту критерії ірозробляє/аналізує/узгоджує з керівникрм проекту критерії і
процедури приймання;процедури приймання;
 Бере участь в складанні плану-графіку проекту в частині, щоБере участь в складанні плану-графіку проекту в частині, що
стосуються робіт по тестуванністосуються робіт по тестуванні
 Розробляє стратегію тестуванняРозробляє стратегію тестування
 Визначає інструментарій тестування і управління помилкамиВизначає інструментарій тестування і управління помилками
 Визначає необхідність спеціального ПО для тестування (e.g. testВизначає необхідність спеціального ПО для тестування (e.g. test
drivers)drivers)
 В подальшомуВ подальшому
 організує роботи по тестуванню в відповідності зі стратегієюорганізує роботи по тестуванню в відповідності зі стратегією
тестування і планом-графіком проектутестування і планом-графіком проекту
 Щотижня відчитується перед керівником проекту і директоромЩотижня відчитується перед керівником проекту і директором
відділувідділу

01/29/15
Функції тест-проектувальникаФункції тест-проектувальника
 Розробляє плани тестуванняРозробляє плани тестування
 сценарії тестуваннясценарії тестування
 теститести
 дані для тестуваннядані для тестування
 деталізує плани тестування післядеталізує плани тестування після
 уточнення проектних рішеньуточнення проектних рішень
 отримання ОТотримання ОТ
 коректує плани тестуваннякоректує плани тестування
 в відповідності зі змінами вимог і проектних рішеньв відповідності зі змінами вимог і проектних рішень
 з врахуванням виявлених помилокз врахуванням виявлених помилок

01/29/15
Функції тестувальникаФункції тестувальника
 Виконує роботи по тестуванні, поручені йому тест-Виконує роботи по тестуванні, поручені йому тест-
менеджеромменеджером
 проведення тестуванняпроведення тестування
 автоматизація тестівавтоматизація тестів
 ООформляє результати тестуванняформляє результати тестування
 протоколи тестуванняпротоколи тестування
 описання дефектів (Bug reports)описання дефектів (Bug reports)

01/29/15
Продукція групи тестуванняПродукція групи тестування
 Стратегія тестуванняСтратегія тестування
 План тестуванняПлан тестування
 Тестові сценаріїТестові сценарії
 Тестові дані, драйвери, скріптиТестові дані, драйвери, скріпти
 Протоколи тестування/звіти по дефектахПротоколи тестування/звіти по дефектах
 Звітність про хід тестування: метрики, індикаториЗвітність про хід тестування: метрики, індикатори
 Підсумковий звітПідсумковий звіт

01/29/15
Ролі по рівнях тестуванняРолі по рівнях тестування
 Автономне тестування модулів -- unit testingАвтономне тестування модулів -- unit testing
програміст -- розробник модуляпрограміст -- розробник модуля
 Інтеграційне, «збіркове» тестування -- integrationІнтеграційне, «збіркове» тестування -- integration
testingtesting
розробники і в деяких випадках тестувальникирозробники і в деяких випадках тестувальники
 Тестування підсистем -- subsystem testingТестування підсистем -- subsystem testing
тестувальникитестувальники
 Системне тестування -- system testingСистемне тестування -- system testing
тестувальникитестувальники
 Приймальне тестування -- acceptance testingПриймальне тестування -- acceptance testing
замовник за участю МП і тестувальниківзамовник за участю МП і тестувальників

01/29/15
Об’єкти тестуванняОб’єкти тестування
 ПП в цілому є обПП в цілому є об’’єктом системного тестування =єктом системного тестування =
«кінцевим» ОТ«кінцевим» ОТ
 проект може передбачувати розробку і проміжнихпроект може передбачувати розробку і проміжних
обєктів, що тестуютьсяобєктів, що тестуються
 ОТ при ітеративній розробці:ОТ при ітеративній розробці:
 прототипипрототипи
 функціональні підсистеми, що отримуються внаслідокфункціональні підсистеми, що отримуються внаслідок
нарощуваннянарощування
 Кожна ітерація закінчується створенням проміжногоКожна ітерація закінчується створенням проміжного
продукту, який стає обєктом тестуванняпродукту, який стає обєктом тестування

01/29/15
Тестування в ітеративному процесіТестування в ітеративному процесі
Минула
ітерація
Наступна
ітерація
Поточна ітерація
Критерії
випуску ОТ Проектування Реалізація
План
ітерації
План
Виконання тестів
версія версія
test
results
test
results
Оцінка результатів
Вимоги до
системи,
стратегія
розробки
Критерії оцінки ОТ
тест-
раунд

01/29/15
Проведення тестуванняПроведення тестування
 В другій половині ітераціїВ другій половині ітерації
 За готовністю ОТ (завершена розробка)За готовністю ОТ (завершена розробка)
 Завдання на тестування – «контракт» тест-Завдання на тестування – «контракт» тест-
менеджера з групою розробкименеджера з групою розробки
 рамки, теміни, обєкт тестуваннярамки, теміни, обєкт тестування
 критерії завершення ~ критерії якості ОТкритерії завершення ~ критерії якості ОТ
 ресурси і глибина тестуванняресурси і глибина тестування
 Виконання контракту=цикл тестуванняВиконання контракту=цикл тестування
 Оцінкове тестуванняОцінкове тестування
 Зовні циклу тестування: «недозрілий» ОТЗовні циклу тестування: «недозрілий» ОТ

01/29/15
Тест-раунд – тестування визначеноїТест-раунд – тестування визначеної
версії ОТверсії ОТ
 версія ОТ (=Build)версія ОТ (=Build)
 передається із групипередається із групи
 відміняється, коли невідміняється, коли не
проходить приймальнепроходить приймальне
тестуваннятестування
 Приймальне тестуванняПриймальне тестування
 Реалізується сценаріємРеалізується сценарієм
плану тестуванняплану тестування
 Може автоматизуватисяМоже автоматизуватися
 Включає перевіркуВключає перевірку
номеру версіїномеру версії
 об’єм тестування в кожномуоб’єм тестування в кожному
тест-раундітест-раунді
 Може варіюватися вМоже варіюватися в
залежності від термінів,залежності від термінів,
ресурсів, якості ОТресурсів, якості ОТ
 мінімуммінімум: перевірка щойно: перевірка щойно
виправлених помилоквиправлених помилок
 типовотипово: регресивне: регресивне
тестування (чи нетестування (чи не
випливають ранішевипливають раніше
виправлені помилки?)виправлені помилки?)
 максимуммаксимум: повне: повне
тестування у відповідностітестування у відповідності
з ПТз ПТ

01/29/15
The End
Thanks for your attention!
Questions or comments?

Процес забезпечення якості програмних продуктів

Recommandé

Recommandé

Contenu connexe

En vedette

En vedette (7)

Similaire à Процес забезпечення якості програмних продуктів

Similaire à Процес забезпечення якості програмних продуктів (20)

Dernier

Dernier (14)

Процес забезпечення якості програмних продуктів