Організації стикаються з багатьма внутрішніми та зовнішніми факторами, які роблять невизначеним питання, чи досягнуть вони своїх цілей і коли (ISO 31000). Управління ризиками дозволяє організаціям підвищити ймовірність досягнення цілей, покращити якість своєї продукції та підвищити впевненість і довіру зацікавлених сторін.
Основними видами діяльності з управління ризиками є:
Аналіз ризику (що складається з ідентифікації та оцінки ризику)
Контроль ризику (складається з пом’якшення ризику та моніторингу ризику)
Тестовий підхід, у якому тестові дії вибираються, пріоритезуються та керуються на основі аналізу та контролю ризиків, називається тестуванням на основі ризиків.
Визначення ризику(версія 3.1)
Ризик передбачає можливість події в майбутньому, яка матиме негативні наслідки. Рівень ризику визначається ймовірністю події та наслідками (шкодою) від цієї події.
Визначення ризику(версія 4.0)
Ризик – це потенційна подія, небезпека, загроза або ситуація, виникнення якої викликає несприятливий ефект. Ризик можна охарактеризувати двома факторами:
Імовірність ризику – ймовірність виникнення ризику (більша за нуль і менша за одиницю)
Вплив ризику (шкода) – наслідки цієї події
Ці два фактори виражають рівень ризику, який є мірою ризику. Чим вищий рівень ризику, тим важливіше управління цим ризиком.
Ризики продукту і ризики проєкту (версія 3.1)
Ризик продукту передбачає можливість того, що робочий продукт (наприклад, специфікація, компонент, система або тест) може не задовольнити законні потреби своїх користувачів або зацікавлених сторін. Коли ризики продукту пов’язані з конкретними характеристиками якості продукту (наприклад, функціональна придатність, надійність, ефективність продуктивності, зручність використання, безпека, сумісність, зручність супроводу і портативність), ризики продукту також називають ризиками якості.
Приклади ризиків продукту включають:
Програмне забезпечення може не виконувати призначені функції відповідно до специфікації
Програмне забезпечення може не виконувати призначені функції відповідно до потреб користувача, клієнта або зацікавлених сторін
Архітектура системи може недостатньо підтримувати деякі нефункціональні вимоги.
За певних обставин певне обчислення може бути виконано неправильно
Структура керування циклом може бути закодована неправильно
Час відповіді може бути недостатнім для високопродуктивної системи обробки транзакцій
Відгуки про досвід користувача (UX) можуть не відповідати очікуванням продукту
Проєктний ризик включає ситуації, які, якщо вони виникнуть, можуть негативно вплинути на здатність проєкту досягти своїх цілей. Приклади проєктних ризиків включають:
Проблеми проєкту:
Можуть виникати затримки в доставці, виконанні завдання або задоволенні критеріїв виходу чи визначення виконаного
Неточні оцінки, перерозподіл коштів на проєкти з вищим пріоритетом або загальне скорочення витрат в організації можуть призвести до недостатнього фінансування
Пізні зміни можуть призвести до значної переробки
Організаційні питання:
Навички, навчання та персонал можуть бути недостатніми
Проблеми з персоналом можуть спричинити конфлікти та проблеми
Користувачі, бізнес-персонал або експерти з певної тематики можуть бути недоступні через суперечливі бізнес-пріоритети
Політичні питання:
Тестувальники можуть не повідомляти належним чином свої потреби або результати тестування
Розробники або тестувальники можуть не врахувати інформацію, отриману під час тестування та оглядів (наприклад, не вдосконалювати практику розробки та тестування)
Можливе неправильне ставлення до тестування або очікування від нього (наприклад, недооцінка цінності пошуку дефектів під час тестування)
Технічні проблеми:
Вимоги можуть бути визначені недостатньо добре
Вимоги можуть бути не виконані через існуючі обмеження
Тестове середовище може бути не готове вчасно
Перетворення даних, планування міграції та підтримка інструментів можуть виконуватися із запізненням
Недоліки в процесі розробки можуть вплинути на послідовність або якість робочих продуктів проєкту, таких як дизайн, код, конфігурація, тестові дані та тестові випадки
Погане управління дефектами та подібні проблеми можуть призвести до накопичення дефектів та інших технічних боргів
Проблеми з постачальниками:
Третя сторона може не надати необхідний продукт чи послугу або збанкрутувати
Контрактні питання можуть спричинити проблеми для проєкту
Ризики проєкту можуть впливати як на діяльність з розробки, так і на діяльність з тестування. У деяких випадках керівники проєктів несуть відповідальність за обробку всіх ризиків проєкту, але це не є незвичайним, коли менеджери тестування відповідають за ризики проєкту, пов’язані з тестуванням.
Ризики продукту і ризики проєкту (версія 4.0)
Ризики продукту пов’язані з характеристиками якості продукту (наприклад, описані в моделі якості ISO 25010). Приклади ризиків продукту включають: відсутність або неправильну функціональність, неправильні обчислення, помилки під час виконання, погану архітектуру, неефективні алгоритми, неадекватний час відповіді, погану взаємодію з користувачем, вразливі місця в безпеці. Ризики продукту, коли вони виникають, можуть призвести до різних негативних наслідків, зокрема:
Невдоволення користувачів
Втрата прибутку, довіри, репутації
Шкода третім особам
Високі витрати на обслуговування, перевантаження служби підтримки
Кримінальні покарання
У крайніх випадках фізичні пошкодження, травми або навіть смерть
Проєктні ризики пов’язані з управлінням і контролем проєкту. Проєктні ризики включають:
Організаційні проблеми (наприклад, затримки в постачанні робочої продукції, неточні оцінки, скорочення витрат)
Проблеми з людьми (наприклад, недостатні навички, конфлікти, проблеми з комунікацією, нестача персоналу)
Технічні проблеми (наприклад, погана підтримка інструментів)
Проблеми з постачальником (наприклад, збій доставки третьою стороною, банкрутство компанії-контрагента)
Ризики проєкту, коли вони виникають, можуть вплинути на графік, бюджет або обсяг проєкту, що впливає на здатність проєкту досягати своїх цілей.
Тестування засноване на ризику та якість продукту (версія 3.1)
Ризик використовується для зосередження зусиль, необхідних під час тестування. Він використовується, щоб вирішити, де і коли розпочати тестування, а також визначити області, які потребують більшої уваги. Тестування використовується для зменшення ймовірності виникнення несприятливої події або для зменшення впливу несприятливої події. Тестування використовується як діяльність зі зменшення ризиків, щоб надати інформацію про виявлені ризики, а також надати інформацію про залишкові (невирішені) ризики.
Ризик-орієнтований підхід до тестування надає проактивні можливості для зниження рівня ризику продукту. Він передбачає аналіз ризиків продукту, який включає ідентифікацію ризиків продукту та оцінку ймовірності та впливу кожного ризику. Отримана інформація про ризик продукту використовується для планування тестування, специфікації, підготовки та виконання тестових випадків, а також для моніторингу та контролю тестування. Ранній аналіз ризиків продукту сприяє успіху проєкту.
У підході, що ґрунтується на оцінці ризику, результати аналізу ризику продукту використовуються для:
Визначення методів тестування, які будуть використані
Визначення конкретних рівнів та типів тестування, які необхідно виконати (наприклад, тестування безпеки, тестування доступності)
Визначення обсягів тестування, яке необхідно провести
Надайте пріоритет тестуванню, намагаючись якомога раніше виявити критичні дефекти
Визначте, чи можна застосувати будь-які дії на додаток до тестування для зменшення ризику (наприклад, навчання недосвідчених дизайнерів)
Тестування на основі ризиків спирається на колективні знання та розуміння зацікавлених сторін проєкту для проведення аналізу ризиків продукту.
Щоб забезпечити мінімізацію ймовірності відмови продукту, заходи з управління ризиками забезпечують дисциплінований підхід до:
Аналізу (і регулярної переоцінки) того, що може піти не так (ризики)
Визначення, з якими ризиками важливо боротися
Впровадження заходів для пом’якшення цих ризиків
Складання планів на випадок непередбачених обставин, щоб подолати ризики, якщо вони стануть реальними подіями
Крім того, тестування може виявити нові ризики, допомогти визначити, які ризики слід пом’якшити, і знизити невизначеність щодо ризиків.
Тестування засноване на ризику та якість продукту (версія 4.0)
З точки зору тестування, метою аналізу ризику продукту є усвідомлення ризику продукту, щоб зосередити зусилля на тестуванні таким чином, щоб мінімізувати залишковий рівень ризику продукту. В ідеалі аналіз ризиків продукту починається на ранній стадії SDLC.
Аналіз ризику продукту складається з ідентифікації та оцінки ризику. Ідентифікація ризиків полягає у створенні повного списку ризиків. Зацікавлені сторони можуть ідентифікувати ризики за допомогою різних методів та інструментів, наприклад, мозкового штурму, семінарів, інтерв’ю або причинно-наслідкових діаграм. Оцінка ризику включає: класифікацію ідентифікованих ризиків, визначення їхньої ймовірності, впливу та рівня ризику, встановлення пріоритетів та пропонування шляхів їх усунення. Категоризація допомагає призначати заходи пом’якшення, оскільки зазвичай ризики, які потрапляють до однієї категорії, можна зменшити за допомогою подібного підходу.
Оцінка ризику може використовувати кількісний або якісний підхід або їх поєднання. У кількісному підході рівень ризику розраховується як множення ймовірності ризику та впливу ризику. У якісному підході рівень ризику можна визначити за допомогою матриці ризику.
Аналіз ризику продукту може вплинути на ретельність і обсяг тестування. Його результати використовуються для:
Визначення обсягів тестування, яке необхідно провести
Визначення конкретних рівнів тестування та запропонування типів тестів для виконання
Визначення методів тестування, які будуть використані, і охоплення, якого потрібно досягти
Оцінка зусиль, необхідних для виконання кожного завдання
Надання пріоритетів тестування, щоб якомога раніше виявити критичні дефекти
Визначення, чи можна застосувати будь-які дії на додаток до тестування для зменшення ризику
Контроль ризику продукту (версія 4.0)
Контроль ризиків продукту включає всі заходи, які вживаються у відповідь на ідентифіковані та оцінені ризики продукту. Контроль ризику продукту складається з пом’якшення ризику та моніторингу ризику. Пом’якшення ризику передбачає впровадження заходів, запропонованих в оцінці ризику, щоб зменшити рівень ризику. Мета моніторингу ризиків полягає в тому, щоб переконатися в тому, що дії щодо пом’якшення є ефективними, отримати додаткову інформацію для покращення оцінки ризику та визначення ризиків, що виникають.
Що стосується контролю ризику продукту, після аналізу ризику можливі кілька варіантів реагування на ризик, наприклад, пом’якшення ризику шляхом тестування, прийняття ризику, передача ризику або план дій у непередбачених ситуаціях (Veenendaal 2012). Заходи, які можна вжити для зменшення ризиків продукту шляхом тестування, такі:
Виберіть тестувальників із належним рівнем досвіду та навичок, які підходять для певного типу ризику
Застосовуйте належний рівень незалежності тестування
Проведіть огляди та статичний аналіз
Застосовуйте відповідні методи тестування та рівні покриття
Застосуйте відповідні типи тестів, спрямовані на пов’язані характеристики якості
Виконайте динамічне тестування, включаючи регресійне тестування
ISTQB Certified Tester Foundation Level. Курс для початківців. Секція 5.5.
В цьому відео починаємо працювати з секцію 5.5. 00:01:12 Risk Management (v 4.0) 00:04:15 Definition of Risk 00:07:41 Product and Project Risks 00:26:10 Risk-based Testing and Product Quality 00:39:42 Product Risk Control (v 4.0)
Метою моніторингу тестування є збір інформації та забезпечення зворотного зв’язку та видимості тестової діяльності. Інформація, яка підлягає моніторингу, може збиратися вручну або автоматично, і її слід використовувати для оцінки прогресу тестування та вимірювання того, чи задовольняються критерії виходу з тесту або завдання тестування, пов’язані з визначенням виконаного в Agile-проєкті, наприклад досягнення цілей для покриття ризиків продукту, вимог або критеріїв прийнятності.
Тестовий контроль описує будь-які керівні або коригувальні дії, вжиті в результаті інформації та показників, зібраних і повідомлених. Дії можуть охоплювати будь-яку тестову діяльність і можуть впливати на будь-яку іншу діяльність життєвого циклу програмного забезпечення.
Приклади тестових контрольних дій включають:
Переналаштування пріоритетів тестів у разі виявлення виявленого ризику (наприклад, програмне забезпечення доставлено із запізненням)
Зміна розкладу тестування через доступність або відсутність тестового середовища чи інших ресурсів
Повторна оцінка того, чи відповідає тестовий елемент критерію входу або виходу через переробку
Тестовий моніторинг і контроль (версія 4.0)
Моніторинг тестування стосується збору інформації про тестування. Ця інформація використовується для оцінки прогресу тестування та вимірювання того, чи задовольняються критерії виходу з тесту або тестові завдання, пов’язані з критеріями виходу, наприклад досягнення цілей щодо покриття ризиків продукту, вимог або критеріїв прийнятності.
Контроль тестування використовує інформацію від моніторингу тестування, щоб забезпечити, у формі контрольних директив, керівництво та необхідні коригувальні дії для досягнення найбільш ефективного тестування. Приклади контрольних директив включають:
Зміна пріоритетів тестів, коли виявлений ризик стає проблемою
Повторна оцінка того, чи відповідає тестовий елемент критеріям входу або критеріям виходу через переробку
Налаштування розкладу тестування для усунення затримки в доставці тестового середовища
Додавання нових ресурсів, коли і де це необхідно
Завершення тестування збирає дані про завершені тестові дії для консолідації досвіду, програмного забезпечення для тестування та будь-якої іншої відповідної інформації. Діяльність із завершення тестування відбувається на етапах проєкту, наприклад, коли завершується рівень тестування, завершується адаптивна ітерація, завершується або скасовується тестовий проєкт, випускається програмна система або завершується реліз обслуговування.
Метрики, які використовуються у тестуванні (версія 3.1)
Показники можна збирати під час і в кінці тестової діяльності, щоб оцінити:
Прогрес у порівнянні з запланованим графіком і бюджетом
Поточна якість об’єкта тестування
Адекватність тестового підходу
Ефективність тестової діяльності щодо цілей
Загальні тестові показники включають:
Відсоток запланованої роботи, виконаної під час підготовки тестів (або відсоток запланованих тестів, виконаних)
Відсоток виконаної запланованої роботи з підготовки тестового середовища
Виконання тестового кейсів (наприклад, кількість запущених/незапущених тестових кейсів, пройдених/не виконаних тестових кейсів або умов тестування пройдених/не виконаних)
Інформація про дефекти (наприклад, щільність дефектів, виявлені та виправлені дефекти, частота відмов і результати підтверджувальних тестів)
Переврка покриття вимог, історій користувачів, критеріїв прийнятності, ризиків або коду
Виконання завдань, розподіл і використання ресурсів, а також зусилля
Вартість тестування, включаючи вартість порівняно з вигодою від виявлення наступного дефекту або вартість порівняно з вигодою від виконання наступного тесту
Метрики, які використовуються у тестуванні (версія 4.0)
Тестові показники збираються, щоб показати прогрес у порівнянні із запланованим графіком і бюджетом, поточну якість тестового об’єкта та ефективність тестової діяльності щодо цілей або цілі ітерації. Моніторинг тестування збирає різноманітні показники для підтримки контролю тестування та завершення тестування.
Загальні тестові показники включають:
Показники прогресу проєкту (наприклад, виконання завдання, використання ресурсів, тестування)
Показники прогресу тестування (наприклад, прогрес впровадження тестового кейсу, прогрес підготовки тестового середовища, кількість запущених/незапущених тестових кейсів, пройдено/не пройдено, час виконання тесту)
Показники якості продукції (наприклад, доступність, час відгуку, середній час до відмови)
Показники дефектів (наприклад, кількість і пріоритети знайдених/виправлених дефектів, щільність дефектів, відсоток виявлення дефектів)
Показники ризику (наприклад, рівень залишкового ризику)
Показники покриття (наприклад, покриття вимог, покриття коду)
Показники вартості (наприклад, вартість тестування, організаційна вартість якості)
Мета, зміст і аудиторія тестових звітів (версія 3.1)
Метою тестового звіту є узагальнення та передача інформації про тестову діяльність як під час, так і в кінці тестової діяльності (наприклад, рівень тестування). Звіт про тестування, підготовлений під час тестування, можна назвати звітом про хід тестування, а звіт про тестування, підготовлений наприкінці тестування, можна назвати підсумковим звітом про тестування.
Під час моніторингу та контролю тестування керівник тестування регулярно видає звіти про хід тестування для зацікавлених сторін. Окрім вмісту, загального для звітів про хід тестування та підсумкових звітів про тестування, типові звіти про хід тестування також можуть містити:
Статус тестової діяльності та прогрес щодо плану тестування
Фактори, що перешкоджають прогресу
Заплановані тестування на наступний звітний період
Якість об’єкта тестування
Коли критерії виходу досягнуті, менеджер тестування видає підсумковий звіт тестування. У цьому звіті міститься підсумок проведеного тестування на основі останнього звіту про хід тестування та будь-якої іншої відповідної інформації.
Типові підсумкові звіти про тестування можуть містити:
Підсумок проведеного тестування
Інформація про те, що сталося під час тестового періоду
Відхилення від плану, включаючи відхилення в графіку, тривалості або зусиллях тестової діяльності
Статус тестування та якості продукту щодо критеріїв виходу або визначення виконаного
Фактори, які блокували або продовжують блокувати прогрес
Показники дефектів, тестові випадки, тестове покриття, прогрес діяльності та споживання ресурсів.
Залишкові ризики
Виготовлені багаторазові тестові робочі продукти
Зміст звіту про тестування буде різним залежно від проєкту, організаційних вимог і життєвого циклу розробки програмного забезпечення. Наприклад, складний проєкт із багатьма зацікавленими сторонами або регульований проєкт може вимагати більш детальної та ретельної звітності, ніж швидке оновлення програмного забезпечення. Як інший приклад, у гнучкій розробці звіти про хід тестування можуть бути включені в панелі завдань, підсумки дефектів і діаграми вигоряння, які можуть обговорюватися під час щоденної зустрічі.
На додаток до адаптації звітів про тестування на основі контексту проєкту, звіти про тестування слід адаптувати відповідно до аудиторії звіту. Тип і обсяг інформації, яку слід включити для технічної аудиторії або команди тестування, може відрізнятися від того, що буде включено в підсумковий звіт. У першому випадку може бути важливою детальна інформація про типи дефектів і тенденції. В останньому випадку більш доцільним може бути звіт високого рівня (наприклад, зведення про стан дефектів за пріоритетом, бюджетом, графіком і умовами тестування: пройдено/не пройдено/не перевірено).
Стандарт ISO (ISO/IEC/IEEE 29119-3) стосується двох типів звітів про тестування, звітів про хід тестування та звітів про завершення тестування (у цьому сілабусі називають підсумковими звітами про тестування), і містить структури та приклади для кожного типу.
Мета, зміст і аудиторія тестових звітів (версія 4.0)
Звіт про тестування підсумовує та передає інформацію про тест під час і після тестування. Звіти про хід тестування підтримують постійний контроль тестування та повинні надавати достатньо інформації для внесення змін до розкладу тестування, ресурсів або плану тестування, якщо такі зміни необхідні через відхилення від плану або змінені обставини. Звіти про завершення тестування підсумовують певний етап тестування (наприклад, рівень тестування, цикл тестування, ітерація) і можуть надавати інформацію для наступного тестування.
Під час моніторингу та контролю тестування група тестування створює звіти про хід тестування для зацікавлених сторін, щоб тримати їх у курсі. Звіти про хід тестування зазвичай створюються на регулярній основі (наприклад, щодня, щотижня тощо) і містять:
Тестовий період
Перебіг тестування (наприклад, випередження або відставання від графіка), включаючи будь-які помітні відхилення
Перешкоди для тестування та їх вирішення
Тестові показники
Нові та змінені ризики протягом періоду тестування
Тестування заплановане на наступний період
Звіт про завершення тестування готується під час завершення тестування, коли проєкт, рівень тестування або тип тестування завершено та коли, в ідеалі, критерії виходу виконано. Цей звіт використовує звіти про хід тестування та інші дані. Типові звіти про завершення тестування включають:
Підсумок тестування
Тестування та оцінка якості продукту на основі оригінального плану тестування (тобто цілей тестування та критеріїв виходу)
Відхилення від плану тестування (наприклад, відмінності від запланованого розкладу, тривалості та зусиль).
Тестування перешкод і обхідних шляхів
Тестові показники на основі звітів про хід тестування
Незменшені ризики, не виправлені дефекти
Отримані уроки, які стосуються тестування
Різні аудиторії вимагають різної інформації у звітах і впливають на ступінь формальності та частоту звітування. Звітування про хід тестування для інших у тій самій команді часто є частим і неофіційним, тоді як звітування про тестування для завершеного проєкту відповідає встановленому шаблону та відбувається лише один раз.
Стандарт ISO/IEC/IEEE 29119-3 містить шаблони та приклади звітів про хід тестування (так звані звіти про статус тестування) і звітів про завершення тестування.
Комунікація статуса тестування (версія 4.0)
Найкращі засоби передачі інформації про статус тестування залежать від проблем управління тестуванням, організаційних стратегій тестування, нормативних стандартів або, у випадку самоорганізованих команд, від самої команди. Варіанти включають:
Вербальне спілкування з членами команди та іншими зацікавленими сторонами
Інформаційні панелі (наприклад, панелі інструментів CI/CD, панелі завдань і діаграми)
Електронні канали зв’язку (наприклад, електронна пошта, чат)
Онлайн-документація
Офіційні протоколи тестування
Можна використовувати один або декілька з цих варіантів. Більш формальне спілкування може бути більш доцільним для розподілених команд, де пряме спілкування віч-на-віч не завжди можливе через географічну відстань або різницю в часі. Як правило, різні стейкхолдери зацікавлені в різних типах інформації, тому комунікацію слід адаптувати відповідно до них.
Управління конфігурацією (версія 3.1)
Метою управління конфігурацією є встановлення та підтримка цілісності компонента або системи, тестового програмного забезпечення та їх зв’язків один з одним протягом життєвого циклу проєкту та продукту.
Для належної підтримки тестування керування конфігурацією може передбачати забезпечення наступного:
Усі тестові елементи унікально ідентифіковані, контролюються версіями, відстежуються зміни та пов’язані один з одним
Усі елементи тестового програмного забезпечення однозначно ідентифікуються, контролюються версіями, відстежуються зміни, пов’язані один з одним і пов’язані з версіями тестового елемента(ів), щоб відстежуваність могла підтримуватися протягом усього процесу тестування
Усі ідентифіковані документи та елементи програмного забезпечення містять однозначні посилання в тестовій документації
Під час планування тестування слід визначити та впровадити процедури керування конфігурацією та інфраструктурою (інструменти).
Управління конфігурацією (версія 4.0)
У тестуванні керування конфігурацією (CM) забезпечує дисципліну для ідентифікації, контролю та відстеження робочих продуктів, таких як плани тестування, стратегії тестування, умови тестування, тестові сценарії, результати тестування, журнали тестування та звіти про тестування як елементів конфігурації.
Для елемента складної конфігурації (наприклад, тестового середовища) CM записує елементи, з яких він складається, їхні зв’язки та версії. Якщо елемент конфігурації схвалено для тестування, він стає базовим і може бути змінений лише через формальний процес контролю змін.
Керування конфігурацією зберігає записи змінених елементів конфігурації, коли створюється нова базова лінія. Можна повернутися до попереднього базового рівня, щоб відтворити попередні результати тестування.
Для належної підтримки тестування CM забезпечує наступне:
Усі елементи конфігурації, включно з елементами тестування (окремими частинами об’єкта тестування), унікально ідентифіковані, контролюються версіями, відстежуються зміни та зв’язки з іншими елементами конфігурації, щоб можна було підтримувати відстеження протягом усього процесу тестування
Усі ідентифіковані елементи документації та програмного забезпечення містять однозначні посилання в тестовій документації
Безперервна інтеграція, безперервна доставка, безперервне розгортання та відповідне тестування зазвичай реалізуються як частина автоматизованого конвеєра DevOps, до якого зазвичай входить автоматизований CM.
ISTQB Certified Tester Foundation Level. Курс для початківців. Секції 5.3-5.4.
В цьому відео починаємо працювати з секціями 5.3-5.4. 00:00:49 Test Monitoring and Control 00:12:20 Metrics Used in Testing 00:23:41 Purposes, Contents, and Audiences for Test Reports 00:45:56 Communicating the Status of Testing (V 4.0) 00:49:52 Configuration Management
У плані тестування описано тестування для проєктів розробки та обслуговування. На планування впливають політика тестування та стратегія тестування організації, життєві цикли розробки та методи, що використовуються, сфера тестування, цілі, ризики, обмеження, критичність, можливість тестування та доступність ресурсів.
У міру просування проєкту та планування тестування стає доступніше більше інформації, і в план тестування можна включити більше деталей. Планування випробувань — це безперервна діяльність, яка виконується протягом життєвого циклу продукту. (Зауважте, що життєвий цикл продукту може виходити за рамки проєкту та включати етап технічного обслуговування.) Зворотній зв’язок від тестової діяльності слід використовувати для визначення мінливих ризиків, щоб можна було скоригувати планування. Планування може бути задокументовано в генеральному плані тестування та в окремих планах тестування для рівнів тестування, таких як тестування системи та приймальне тестування, або для окремих типів тестування, таких як тестування зручності використання та тестування продуктивності.
Заходи з планування тестування можуть включати наступне, і деякі з них можуть бути задокументовані в плані тестування:
Визначення обсягу, цілей і ризиків тестування
Визначення загального підходу до тестування
Інтеграція та координація тестової діяльності в діяльність життєвого циклу програмного забезпечення
Прийняття рішень щодо того, що тестувати, людей та інших ресурсів, необхідних для виконання різноманітних тестових дій, і способів проведення тестових дій
Планування аналізу, проєктування, реалізації, виконання та оцінювання тестів на певні дати (наприклад, у послідовній розробці) або в контексті кожної ітерації (наприклад, у ітераційній розробці)
Вибір метрик для моніторингу та контролю тестів
Бюджет для тестової діяльності
Визначення рівня деталізації та структури тестової документації (наприклад, шляхом надання шаблонів або прикладів документів)
Зміст тестових планів може бути різним і може виходити за межі тем, визначених вище. Зразок структури плану тестування та зразок плану тестування можна знайти в стандарті ISO (ISO/IEC/IEEE 29119-3).
Тестова стратегія та тестовий підхід (версія 3.1)
Стратегія тестування забезпечує узагальнений опис процесу тестування, зазвичай на рівні продукту або організації. Поширені типи тестових стратегій включають:
Аналітичний: цей тип стратегії тестування базується на аналізі певного фактора (наприклад, вимоги чи ризику). Тестування на основі ризику є прикладом аналітичного підходу, коли тести розробляються та пріоритезуються на основі рівня ризику.
На основі моделі: у цьому типі стратегії тестування тести розробляються на основі певної моделі певного необхідного аспекту продукту, такого як функція, бізнес-процес, внутрішня структура або нефункціональна характеристика (наприклад, надійність). Приклади таких моделей включають моделі бізнес-процесів, моделі стану та моделі зростання надійності.
Методичний: Цей тип стратегії тестування базується на систематичному використанні деякого попередньо визначеного набору тестів або умов тестування, таких як класифікація поширених або ймовірних типів збоїв, перелік важливих характеристик якості або загальний погляд на рівні компанії стосовно стандартів для мобільних додатків або веб-сторінок.
Стратегія тестування забезпечує узагальнений опис процесу тестування, зазвичай на рівні продукту або організації. Поширені типи тестових стратегій включають:
Сумісність із процесом (або стандартом): цей тип стратегії тестування передбачає аналіз, розробку та впровадження тестів на основі зовнішніх правил і стандартів, таких як ті, що визначені галузевими стандартами, документацією процесу, суворою ідентифікацією та використання тестової бази або будь-якого процесу чи стандарту, нав’язаного організацією.
Спрямований (або консультативний): цей тип тестової стратегії керується головним чином порадами, вказівками чи інструкціями зацікавлених сторін, експертів у бізнес-сфері чи експертів із технологій, які можуть перебувати поза командою тестування або поза самою організацією.
Неприхильний до регресії: цей тип тестової стратегії мотивується бажанням уникнути регресії наявних можливостей. Ця стратегія тестування включає повторне використання існуючого тестового програмного забезпечення (особливо тестових кейсів і тестових даних), широку автоматизацію регресійних тестів і стандартні набори тестів.
Реактивний: у цьому типі стратегії тестування реагує на компонент або систему, що тестується, і на події, що відбуваються під час виконання тесту, а не наперед сплановане (як у попередніх стратегіях). Тести розроблені та впроваджені та можуть бути негайно виконані у відповідь на знання, отримані за результатами попередніх тестів. Дослідницьке тестування є поширеною технікою, яка використовується в реактивних стратегіях.
Відповідна стратегія тестування часто створюється шляхом поєднання кількох із цих типів стратегій тестування. Наприклад, тестування на основі оцінки ризику (аналітична стратегія) можна поєднати з дослідницьким тестуванням (реактивна стратегія); вони доповнюють один одного і можуть досягти більш ефективного тестування, якщо використовувати разом.
Тоді як стратегія тестування надає узагальнений опис процесу тестування, підхід до тестування адаптує стратегію тестування для конкретного проєкту чи випуску. Тестовий підхід є відправною точкою для вибору методів тестування, рівнів тестування та типів тестування, а також для визначення критеріїв входу та критеріїв виходу. Розробка стратегії базується на рішеннях, прийнятих щодо складності та цілей проєкту, типу продукту, що розробляється, та аналізу ризиків продукту. Вибраний підхід залежить від контексту та може враховувати такі фактори, як ризики, безпека, доступні ресурси та навички, технологія, характер системи (наприклад, створена на замовлення чи COTS), цілі тестування та правила.
Критерії входу та виходу (версія 3.1)
Щоб здійснювати ефективний контроль за якістю програмного забезпечення та тестування, доцільно мати критерії, які визначають, коли певна тестова діяльність повинна початися та коли ця діяльність буде завершена. Вхідні критерії (більш типово називаються визначенням готовності в гнучкій розробці) визначають передумови для виконання певної тестової діяльності. Якщо критерії вступу не виконані, ймовірно, що діяльність виявиться складнішою, тривалішою, дорожчою та ризикованішою. Критерії виходу (більш типово називаються визначенням виконаного в Agile-розробці) визначають, яких умов необхідно досягти, щоб оголосити рівень тестування або набір тестів завершеними. Критерії входу та виходу повинні бути визначені для кожного рівня тесту та типу тесту та відрізнятимуться залежно від цілей тестування.
Типові критерії входу включають:
Наявність тестованих вимог, історій користувачів або моделей (наприклад, при дотриманні стратегії тестування на основі моделі)
Наявність тестових завдань, які відповідають критеріям виходу для будь-яких попередніх рівнів тестування
Наявність тестового середовища
Наявність необхідних засобів тестування
Наявність тестових даних та інших необхідних ресурсів
Типові критерії виходу включають:
Заплановані тести виконано
Було досягнуто визначений рівень покриття (наприклад, вимог, історій користувачів, критеріїв прийнятності, ризиків, коду)
Кількість невирішених дефектів знаходиться в узгодженому ліміті
Кількість оцінених дефектів, що залишилися, досить низька
Оцінені рівні надійності, ефективності продуктивності, зручності використання, безпеки та інших відповідних характеристик якості є достатніми
Навіть якщо критерії виходу не задовольняються, тестова діяльність також часто згортається через витрачений бюджет, завершення запланованого часу або тиск для виведення продукту на ринок. Припинення тестування за таких обставин може бути прийнятним, якщо зацікавлені сторони проєкту та власники бізнесу переглянули та прийняли ризик запуску без подальшого тестування.
Графік виконання тестування (версія 3.1)
Після того, як різні тестові кейси та тестові процедури створені (з деякими тестовими процедурами, потенційно автоматизованими) і зібрані в тестові набори, тестові набори можна впорядкувати в розклад виконання тестів, який визначає порядок їх виконання. У розкладі виконання тесту слід враховувати такі фактори, як пріоритезація, залежності, підтверджувальні тести, регресійні тести та найефективнішу послідовність виконання тестів.
В ідеалі тестові приклади мають бути впорядковані для виконання на основі їх рівня пріоритету, зазвичай спочатку виконуються тестові випадки з найвищим пріоритетом. Однак ця практика може не спрацювати, якщо тестові приклади мають залежності або функції, що перевіряються, мають залежності. Якщо тест із вищим пріоритетом залежить від тесту з нижчим пріоритетом, тест із нижчим пріоритетом має бути виконаний першим.
Подібним чином, якщо існують залежності між тестовими кейсами, вони повинні бути впорядковані відповідним чином незалежно від їх відносних пріоритетів. Тести підтвердження та регресії також мають бути пріоритетними, виходячи з важливості швидкого зворотного зв’язку про зміни, але тут знову можуть застосовуватися залежності.
У деяких випадках можливі різні послідовності тестів із різними рівнями ефективності, пов’язаними з цими послідовностями. У таких випадках необхідно знайти компроміс між ефективністю виконання тесту та дотриманням пріоритетів.
Фактори, що впливають на тестові зусилля (версія 3.1)
Оцінка зусиль тестування передбачає прогнозування обсягу роботи, пов’язаної з тестуванням, яка буде потрібна для досягнення цілей тестування для конкретного проєкту, випуску або ітерації. Фактори, що впливають на результати тестування, можуть включати характеристики продукту, характеристики процесу розробки, характеристики людей і результати тестування, як показано нижче.
Характеристики продукту
Ризики, пов’язані з продуктом
Якість тестової бази
Розмір виробу
Складність предметної області
Вимоги до характеристик якості (наприклад, безпека, надійність)
Необхідний рівень деталізації тестової документації
Вимоги до законодавчої та нормативної відповідності
Характеристика процесу розробки
Стабільність і зрілість організації
Модель розробки, що використовується
Тестовий підхід
Використані інструменти
Процес тестування
Тиск часу
Характеристики людей
Навички та досвід залучених людей, особливо з подібними проєктами та продуктами (наприклад, знання предметної області)
Згуртованість і лідерство в команді
Результати тестування
Кількість і серйозність виявлених дефектів
Обсяг необхідної переробки
Техніки оцінювання тестування (версія 3.1)
Існує ряд методів оцінки, які використовуються для визначення зусиль, необхідних для адекватного тестування. Дві найбільш часто використовувані техніки:
Техніка, заснована на показниках: оцінка зусиль тестування на основі показників попередніх подібних проєктів або на основі типових значень
Експертна методика: оцінка тестових зусиль на основі досвіду власників тестових завдань або експертів
Наприклад, у Agile-розробці діаграми згоряння є прикладами підходу на основі показників, оскільки залишкові зусилля фіксуються та звітуються, а потім використовуються для прискорення команди для визначення обсягу роботи, яку команда може виконати в наступній ітерації.
Покер-Планування є прикладом експертного підходу, оскільки члени команди оцінюють зусилля для розробки функції на основі свого досвіду.
У послідовних проєктах моделі усунення дефектів є прикладами підходу, заснованого на показниках, коли обсяги дефектів і час на їх усунення фіксуються та повідомляються, що потім забезпечує основу для оцінки майбутніх проєктів подібного характеру; тоді як метод оцінки Delphi є прикладом експертного підходу, за якого група експертів надає оцінки на основі свого досвіду.
Цілі і зміст тестового плану (версія 4.0)
План тестування описує цілі, ресурси та процеси тестового проєкту. План тестування:
Документує засоби та графік досягнення цілей тесту
Допомагає переконатися, що виконана тестова діяльність відповідає встановленим критеріям
Служить засобом спілкування з членами команди та іншими зацікавленими сторонами
Демонструє, що тестування буде відповідати існуючій тестовій політиці та стратегії тестування (або пояснює, чому тестування буде відхилятися від них)
Планування тестування спрямовує мислення тестувальників і змушує тестувальників протистояти майбутнім викликам, пов’язаним із ризиками, графіками, людьми, інструментами, витратами, зусиллями тощо. Процес підготовки плану тестування є корисним способом продумати зусилля, необхідні для досягнення цілей тестового проєкту.
Типовий зміст плану тестування включає:
Контекст тестування (наприклад, обсяг, цілі тестування, обмеження, база тестування)
Припущення та обмеження тестового проєкту
Зацікавлені сторони (наприклад, ролі, обов’язки, відповідність тестування, потребам у наймі та навчанні)
Комунікація (наприклад, форми та частота комунікації, шаблони документації)
Реєстр ризиків (наприклад, ризики продукту, ризики проєкту)
Підхід до тестування (наприклад, рівні тестування, типи тестування, методи тестування, результати тестування, критерії входу та критерії виходу, незалежність тестування, метрики, які потрібно зібрати, вимоги до тестових даних, вимоги до тестового середовища, відхилення від організаційної політики тестування та стратегії тестування )
Бюджет і графік
Детальніше про план тестування та його зміст можна знайти в стандарті ISO/IEC/IEEE 29119-3.
Внесок тестувальника у планування ітерації та випуску (версія 4.0)
У ітераційних SDLC зазвичай відбувається два види планування: планування випуску та планування ітерації.
Планування випуску завчасно передбачає випуск продукту, визначає та повторно визначає резерв продукту та може включати уточнення більших історій користувачів у набір менших історій користувачів. Він також служить основою для тестового підходу та плану тестування для всіх ітерацій. Тестувальники, які беруть участь у плануванні випуску, беруть участь у написанні перевірених історій користувачів і критеріїв прийнятності, беруть участь в аналізі ризиків проєкту та якості, оцінюють зусилля тестування, пов’язані з історіями користувачів, визначають підхід до тестування та планують тестування для випуску.
Планування ітерації дивиться наперед до кінця однієї ітерації та стосується відставання ітерацій. Тестувальники, залучені до планування ітерації, беруть участь у детальному аналізі ризиків історій користувачів, визначають можливість тестування історій користувачів, розбивають історії користувачів на завдання (зокрема, завдання тестування), оцінюють зусилля тестування для всіх завдань тестування, а також визначають і вдосконалюють функціональні та нефункціональні аспекти об’єкта випробувань.
Критерії входу та виходу (версія 4.0)
Критерії входу визначають передумови для здійснення певної діяльності. Якщо критерії входу не дотримані, ймовірно, що діяльність виявиться складнішою, трудомісткішою, дорожчою та ризикованішою. Критерії виходу визначають, що має бути досягнуто, щоб оголосити діяльність завершеною. Критерії входу та критерії виходу мають бути визначені для кожного рівня тестування та відрізнятимуться залежно від цілей тесту.
Типові критерії входу включають: наявність ресурсів (наприклад, людей, інструментів, середовища, тестових даних, бюджету, часу), наявність тестового програмного забезпечення (наприклад, тестової бази, тестових вимог, історій користувачів, тестових прикладів) і початковий рівень якості тестовий об’єкт (наприклад, усі димові тести пройшли успішно).
Типові критерії виходу включають: показники ретельності (наприклад, досягнутий рівень охоплення, кількість невирішених дефектів, щільність дефектів, кількість невдалих випадків тестування) і критерії завершення (наприклад, заплановані тести виконано, статичне тестування виконано, усі повідомляються про знайдені дефекти, усі регресійні тести автоматизовані).
Закінчення часу або бюджету також можна розглядати як дійсний критерій виходу. Навіть без виконання інших критеріїв виходу, за таких обставин може бути прийнятним припинити тестування, якщо зацікавлені сторони розглянули та прийняли ризик запуску без подальшого тестування.
У гнучкій розробці програмного забезпечення критерії виходу часто називають визначенням готового, визначаючи цільові показники команди для випускного елемента. Критерії входу, яким має відповідати історія користувача, щоб почати розробку або тестування, називаються визначенням готовності.
Техніки оцінювання (версія 4.0)
Оцінка тестових зусиль передбачає прогнозування обсягу пов’язаної з тестуванням роботи, необхідної для досягнення цілей тестового проєкту. Важливо пояснити зацікавленим сторонам, що оцінка ґрунтується на низці припущень і завжди піддається помилці оцінки. Оцінка для малих завдань зазвичай більш точна, ніж для великих. Тому, оцінюючи велике завдання, його можна розкласти на набір менших завдань, які потім, у свою чергу, можна оцінити.
Виділяють наступні чотири методи оцінювання:
Оцінка на основі коефіцієнтів. У цій техніці, заснованій на показниках, цифри збираються з попередніх проєктів в організації, що дає змогу отримати «стандартні» коефіцієнти для подібних проєктів. Коефіцієнти власних проєктів організації (наприклад, взяті з історичних даних) зазвичай є найкращим джерелом для використання в процесі оцінки. Потім ці стандартні співвідношення можна використовувати для оцінки зусиль тестування для нового проєкту. Наприклад, якщо в попередньому проєкті співвідношення зусиль на розробку та тестування було 3:2, а в поточному проєкті зусилля на розробку очікується в 600 людино-днів, зусилля на тестування можна оцінити як 400 людино-днів.
Екстраполяція. У цьому методі, заснованому на показниках, вимірювання проводяться якомога раніше в поточному проєкті для збору даних. Маючи достатньо спостережень, зусилля, необхідні для роботи, що залишилася, можна приблизно оцінити шляхом екстраполяції цих даних (зазвичай шляхом застосування математичної моделі). Цей метод дуже підходить для ітераційних SDLC. Наприклад, команда може екстраполювати тестове зусилля в майбутній ітерації як усереднене зусилля з останніх трьох ітерацій.
Методика Delphi. У цій ітераційній експертній техніці експерти роблять оцінки на основі досвіду. Кожен експерт окремо оцінює зусилля. Результати збираються, і якщо є відхилення, що виходять за межі узгоджених меж, експерти обговорюють свої поточні оцінки. Потім кожного експерта просять зробити нову оцінку на основі цього відгуку, знову окремо. Цей процес повторюється, поки не буде досягнуто консенсусу. Planning Poker — це варіант Wideband Delphi, який зазвичай використовується в розробці програмного забезпечення Agile. У Planning Poker оцінки зазвичай робляться за допомогою карток із числами, які представляють розмір зусиль.
Трибальна оцінка. У цій експертній методиці експерти роблять три оцінки: найбільш оптимістичну оцінку (a), найбільш ймовірну оцінку (m) і найбільш песимістичну оцінку (b). Остаточна оцінка (E) є їх середнім зваженим арифметичним. У найпопулярнішому варіанті цієї методики оцінка обчислюється як E = (a + 4*m + b) / 6. Перевагою цієї методики є те, що вона дозволяє експертам розрахувати похибку вимірювання: SD = (b – a) / 6. Наприклад, якщо оцінки (в людино-годинах) такі: a=6, m=9 і b=18, тоді остаточна оцінка становить 10±2 людино-години (тобто від 8 до 12 людино-годин), оскільки E = (6 + 4*9 + 18) / 6 = 10 і SD = (18 – 6) / 6 = 2.
Пріоритезація тестових кейсів (версія 4.0)
Після того, як тестові кейси та процедури тестування визначені та зібрані в набори тестів, ці набори тестів можна впорядкувати в розклад виконання тестів, який визначає порядок їх виконання. При визначенні пріоритетів тестових кейсів можна враховувати різні фактори. Найпоширенішими стратегіями пріоритетності тестових випадків є такі:
Пріоритезація на основі ризиків, де порядок виконання тестів базується на результатах аналізу ризиків. Спочатку виконуються тестові випадки, що охоплюють найважливіші ризики.
Пріоритезація на основі покриття, де порядок виконання тесту базується на покритті (наприклад, покриття оператора). Тестові кейси, які досягають найвищого рівня покриття, виконуються першими. В іншому варіанті, що називається додатковим пріоритетом покриття, спочатку виконується тестовий кейс, який досягає найвищого покриття; кожен наступний тестовий кейс є тим, який досягає найвищого додаткового покриття.
Пріоритезація на основі вимог, де порядок виконання тестів базується на пріоритетах вимог, що відстежуються до відповідних тестів. Пріоритети вимог визначаються зацікавленими сторонами. Спочатку виконуються тестові кейси, пов’язані з найважливішими вимогами.
В ідеалі тестові кейси повинні бути впорядковані для виконання на основі їх рівнів пріоритету, використовуючи, наприклад, одну із згаданих вище стратегій визначення пріоритетів. Однак ця практика може не спрацювати, якщо тестові кейси або функції, що перевіряються, мають залежності. Якщо тест із вищим пріоритетом залежить від тесту з нижчим пріоритетом, тест із нижчим пріоритетом має бути виконаний першим.
Порядок виконання тесту також повинен враховувати наявність ресурсів. Наприклад, потрібні інструменти тестування, тестове середовище або люди, які можуть бути доступні лише протягом певного періоду часу.
Тестова піраміда (версія 4.0)
Піраміда тестів — це модель, яка показує, що різні тести можуть мати різну деталізацію. Модель тестової піраміди підтримує команду в автоматизації тестування та в розподілі тестових зусиль, показуючи, що різні цілі підтримуються різними рівнями автоматизації тестування. Шари піраміди представляють групи тестів. Чим вищий рівень, тим менша деталізація тесту, ізоляція тесту та час виконання тесту. Тести на нижньому рівні невеликі, ізольовані, швидкі та перевіряють невелику частину функціональності, тому зазвичай їх потрібно багато, щоб досягти прийнятного покриття. Верхній рівень представляє складні наскрізні тести високого рівня. Ці високорівневі тести, як правило, повільніші, ніж тести нижчих рівнів, і зазвичай вони перевіряють велику частину функціональних можливостей, тому зазвичай потрібно лише кілька з них, щоб досягти прийнятного покриття. Кількість і назва шарів може відрізнятися. Наприклад, оригінальна модель тестової піраміди (Кон 2009) визначає три рівні: «модульні тести», «сервісні тести» та «тести інтерфейсу користувача». Інша популярна модель визначає тести одиничних компонентів, тести інтеграції (інтеграції компонентів) і наскрізні тести. Також можна використовувати інші рівні тестування.
Тестові квадранти (версія 4.0)
Квадранти тестування, визначені Брайаном Маріком (Marick 2003, Crispin 2008), групують рівні тестування з відповідними типами тестування, діяльністю, технікою тестування та робочими продуктами в розробці програмного забезпечення Agile.
Модель підтримує керування тестуванням у їх візуалізації, щоб гарантувати, що всі відповідні типи тестів і рівні тестів включені в SDLC, і в розумінні того, що деякі типи тестів більш релевантні для певних рівнів тестування, ніж інші. Ця модель також надає спосіб диференціації та опису типів тестів для всіх зацікавлених сторін, включаючи розробників, тестувальників і представників бізнесу.
У цій моделі тести можуть стосуватися бізнесу або технологій. Тести також можуть підтримувати команду (тобто керувати розробкою) або критикувати продукт (тобто вимірювати його поведінку проти очікувань). Поєднання цих двох точок зору визначає чотири квадранти:
Квадрант Q1 (звернення до технологій, підтримка команди). Цей квадрант містить компоненти та тести інтеграції компонентів. Ці тести мають бути автоматизовані та включені в процес CI.
Квадрант Q2 (бізнес, підтримка команди). Цей квадрант містить функціональні тести, приклади, тести історій користувача, прототипи користувацького досвіду, тестування API та моделювання. Ці тести перевіряють критерії прийнятності та можуть бути ручними або автоматизованими.
Квадрант Q3 (бізнес, критика продукту). Цей квадрант містить дослідницьке тестування, тестування зручності використання, тестування прийнятності користувача. Ці тести орієнтовані на користувача і часто ручні.
Квадрант Q4 (розгляд технології, критика продукту). Цей квадрант містить димові тести та нефункціональні тести (крім тестів зручності використання). Ці тести часто автоматизовані.
ISTQB Certified Tester Foundation Level. Курс для початківців. Секція 5.2.
В цьому відео починаємо працювати з секцією 5.2. 00:00:59 Purpose and Content of a Test Plan (v 3.1) 00:07:42 Test Strategy and Test Approach (v 3.1) 00:19:23 Entry Criteria and Exit Criteria (v 3.1) 00:26:34 Test Execution Schedule (v 3.1) 00:30:50 Factors Influencing the Test Effort (v 3.1) 00:34:49 Test Estimation Techniques (v 3.1) 00:41:31 Purpose and Content of a Test Plan (v 4.0) 00:46:40 Tester’s Contribution to Iteration and Release Planning (v 4.0) 00:50:46 Entry Criteria and Exit Criteria (v 4.0) 01:00:24 Estimation Techniques (v 4.0) 01:13:58 Test Case Prioritization (v 4.0) 01:20:49 Test Pyramid (v 4.0) 01:29:35 Testing Quadrants (v 4.0)