Тестовий моніторинг і контроль (версія 3.1)
Метою моніторингу тестування є збір інформації та забезпечення зворотного зв’язку та видимості тестової діяльності. Інформація, яка підлягає моніторингу, може збиратися вручну або автоматично, і її слід використовувати для оцінки прогресу тестування та вимірювання того, чи задовольняються критерії виходу з тесту або завдання тестування, пов’язані з визначенням виконаного в 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.
В цьому відео починаємо працювати з секціями 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