Організації стикаються з багатьма внутрішніми та зовнішніми факторами, які роблять невизначеним питання, чи досягнуть вони своїх цілей і коли (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)
Завдання тестування можуть виконувати люди, які виконують певну роль тестування, або люди, які виконують інші ролі (наприклад, клієнти). Певний ступінь незалежності часто робить тестувальника більш ефективним у пошуку недоліків через відмінності між когнітивними упередженнями автора та тестувальника.
Однак незалежність не є заміною обізнаності, і розробники можуть ефективно знаходити багато дефектів у власному коді.
Ступені незалежності в тестуванні включають наступне (від низького рівня незалежності до високого рівня):
Немає незалежних тестувальників; єдиною доступною формою тестування є тестування розробниками власного коду
Незалежні розробники або тестувальники в рамках груп розробників або команди проєкту; це можуть бути розробники, які тестують продукти своїх колег
Незалежна тестова група або група всередині організації, яка звітує перед керівництвом проєкту
Незалежні тестувальники з бізнес-організації чи спільноти користувачів або зі спеціалізацією на певних типах тестів, таких як зручність використання, безпека, продуктивність, нормативна відповідність або портативність
Незалежні тестувальники поза організацією, які працюють на місці (внутрішні) або за межами підприємства (аутсорсинг)
Для більшості типів проєктів зазвичай найкраще мати кілька рівнів тестування, причому деякі з цих рівнів оброблятимуть незалежні тестувальники. Розробники повинні брати участь у тестуванні, особливо на нижчих рівнях, щоб здійснювати контроль за якістю власної роботи.
Спосіб реалізації незалежності тестування залежить від моделі життєвого циклу розробки програмного забезпечення. Наприклад, у розробці Agile тестувальники можуть бути частиною команди розробників. У деяких організаціях, які використовують гнучкі методи, ці тестувальники також можуть вважатися частиною більшої незалежної тестової групи. Крім того, у таких організаціях власники продукту можуть проводити приймальне тестування для перевірки історій користувачів наприкінці кожної ітерації.
Потенційні переваги незалежності тестування включають:
Незалежні тестувальники, ймовірно, знайдутть різні типи збоїв порівняно з розробниками через їх різний досвід, технічні перспективи та упередження
Незалежний тестувальник може перевірити, оскаржити або спростувати припущення, зроблені зацікавленими сторонами під час специфікації та впровадження системи
Незалежні тестувальники постачальника можуть чесно та об’єктивно звітувати про тестовану систему без (політичного) тиску з боку компанії, яка їх найняла
Потенційні недоліки незалежності тестування включають:
Ізоляція від команди розробників може призвести до відсутності співпраці, затримок у наданні зворотного зв’язку команді розробників або ворожнечі з командою розробників
Розробники можуть втратити почуття відповідальності за якість
Незалежні тестувальники можуть розглядатися як вузьке місце
Незалежним тестувальникам може бракувати важливої інформації (наприклад, про об’єкт тестування)
Завдання тестового менеджера і тестувальника (версія 3.1)
У цьому навчальному плані розглядаються дві ролі тестувальників: менеджери тестування та тестувальники. Діяльність і завдання, які виконуються цими двома ролями, залежать від контексту проєкту та продукту, навичок людей, які виконують ролі, і організації.
Керівник тестування несе загальну відповідальність за процес тестування та успішне керівництво тестовою діяльністю. Роль управління тестуванням може виконувати професійний менеджер з тестування, або менеджер проєкту, менеджер з розвитку або менеджер із забезпечення якості. У великих проєктах або організаціях кілька тестових команд можуть звітувати перед керівником тестування, інструктором з тестування або координатором тестування, причому кожну команду очолює керівник тестування або провідний тестувальник.
Типові завдання менеджера тестування можуть включати:
Розробити або переглянути політику тестування та стратегію тестування для організації
Планувати тестову діяльність, враховуючи контекст і розуміючи цілі тестування та ризики. Це може включати вибір підходів до тестування, оцінку часу тестування, зусиль і вартості, придбання ресурсів, визначення рівнів тестування та циклів тестування, а також планування управління дефектами
Написати та оновити план тестування
Узгодити план тестування з керівниками проєктів, власниками продуктів та іншими сторонами
Поділитися перспективами тестування з іншими видами діяльності проєкту, такими як планування інтеграції
Ініціювати аналіз, розробку, реалізацію та виконання тестів, контролювати хід і результати тестування, а також перевіряти статус критеріїв виходу і сприяти завершенню тестування
Підготувати та надати звіти про хід тестування та підсумкові звіти про тестування на основі зібраної інформації
Адаптувати планування на основі результатів і прогресу тестування (іноді задокументовано у звітах про хід тестування або в підсумкових звітах щодо іншого тестування, яке вже завершено на проєкті), і вжити дії, необхідні для контролю тестування
Підтримка налаштування системи управління дефектами та адекватного керування конфігурацією тестового програмного забезпечення
Запровадити відповідні показники для вимірювання прогресу тестування та оцінки якості тестування та продукту
Підтримка вибору та впровадження інструментів для підтримки процесу тестування, включаючи рекомендацію бюджету для вибору інструменту (і, можливо, придбання та/або підтримки), розподіл часу та зусиль для пілотних проєктів і надання постійної підтримки у використанні інструменту
Прийняти рішення про реалізацію тестового середовища
Заохочувати та захищати тестувальників, команду тестування та професію тестувальника в організації
Розвивати навички та кар’єру тестувальників (наприклад, за допомогою планів навчання, оцінки ефективності, інструктажу тощо)
Типові завдання тестувальника можуть включати:
Перегляньте плани тестування та зробіть свій внесок у них
Аналізувати, переглядати та оцінювати вимоги, історії користувачів і критерії прийнятності, специфікації та моделі для тестування (тобто тестової бази)
Ідентифікувати та документувати умови тестування та фіксувати відстежуваність між тестовими випадками, умовами тестування та основою тестування
Проєктувати, налаштовувати та перевіряти тестове середовище (середовища), часто координуючи це з адміністрацією системи та керівництвом мережі
Розробити та реалізувати тестові кейси та процедури тестування
Підготувати та отримати тестові дані
Створити детальний графік виконання тесту
Виконати тести, оцінювати результати та документувати відхилення від очікуваних результатів
Використовувати відповідні інструменти для полегшення процесу тестування
Автоматизувати тестування за потреби (може підтримуватися розробником або експертом з автоматизації тестування)
Оцінити нефункціональні характеристики, такі як продуктивність, надійність, зручність використання, безпека, сумісність і портативність
Переглянути тести, розроблені іншими
Спосіб, у який виконується роль менеджера тестування, залежить від життєвого циклу розробки програмного забезпечення. Наприклад, у Agile-розробці деякі завдання, згадані вище, виконує команда Agile, особливо ті завдання, які стосуються повсякденного тестування, яке виконується в команді, часто тестувальником, який працює в команді. Деякі завдання, які охоплюють кілька команд або всю організацію, або пов’язані з управлінням персоналом, можуть виконуватися менеджерами з тестування поза командою розробників, яких іноді називають інструкторами з тестування.
Люди, які працюють над аналізом тестів, дизайном тестів, конкретними типами тестів або автоматизацією тестів, можуть бути фахівцями в цих ролях. Залежно від ризиків, пов’язаних із продуктом і проєктом, а також обраної моделі життєвого циклу розробки програмного забезпечення, різні люди можуть взяти на себе роль тестувальника на різних рівнях тестування. Наприклад, на рівні тестування компонентів і на рівні тестування інтеграції компонентів роль тестувальника часто виконують розробники. На рівні приймального випробування роль тестувальника часто виконують бізнес-аналітики, експерти з певної тематики та користувачі. На рівні системного тестування та тестування системної інтеграції роль тестувальника часто виконує незалежна команда тестувальників. На рівні операційної приймальної перевірки роль тестувальника часто виконує персонал з експлуатації або адміністрування системи.
Ролі у тестуванні (версія 4.0)
У цьому сілабусі розглядаються дві основні ролі в тестуванні: роль управління тестуванням і роль тестування. Діяльність і завдання, призначені цим двом ролям, залежать від таких факторів, як контекст проєкту та продукту, навички людей, які виконують ролі, і організація.
Керівник тестування бере на себе загальну відповідальність за процес тестування, команду тестування та керівництво тестовою діяльністю. Роль управління тестуванням головним чином зосереджена на діяльності з планування тестування, моніторингу та контролю тестування та завершення тестування. Спосіб виконання ролі керування тестуванням залежить від контексту. Наприклад, у розробці програмного забезпечення Agile деякі завдання з керування тестуванням можуть виконуватися командою Agile. Завдання, які охоплюють кілька команд або всю організацію, можуть виконувати менеджери тестування поза командою розробників.
Роль тестування бере на себе загальну відповідальність за інженерний (технічний) аспект тестування. Роль тестування в основному зосереджена на аналізі тестів, дизайні тестів, реалізації та виконанні тестів.
Різні люди можуть виконувати ці ролі в різний час. Наприклад, роль управління тестуванням може виконувати керівник групи, менеджер з тестування, менеджер з розробки тощо.
Незалежність тестування (версія 4.0)
Певний ступінь незалежності робить тестувальника більш ефективним у пошуку дефектів через відмінності між когнітивними упередженнями автора та тестувальника (пор. Salman 1995). Проте незалежність не є заміною обізнаності, наприклад, розробники можуть ефективно знаходити багато дефектів у власному коді.
Робочі продукти можуть тестуватися їх автором (немає незалежності), колегами автора з тієї ж команди (певна незалежність), тестувальниками з-за меж команди автора, але всередині організації (висока незалежність), або тестувальниками з-поза організації ( дуже висока незалежність). Для більшості проєктів зазвичай найкраще проводити тестування з кількома рівнями незалежності (наприклад, розробники виконують тестування компонентів та інтеграції компонентів, команда тестувальників виконує тестування системи та системної інтеграції, а представники бізнесу виконують приймальне тестування).
Основна перевага незалежності тестування полягає в тому, що незалежні тестувальники, ймовірно, знайдуть різні види збоїв і дефектів порівняно з розробниками через їхню різну історію, технічні перспективи та упередження. Крім того, незалежний тестувальник може перевірити, оскаржити або спростувати припущення, зроблені зацікавленими сторонами під час специфікації та впровадження системи.
Однак є й деякі недоліки. Незалежні тестувальники можуть бути ізольовані від команди розробників, що може призвести до відсутності співпраці, проблем із спілкуванням або ворогуванню із командою розробників. Розробники можуть втратити почуття відповідальності за якість. Незалежних тестувальників можуть вважати «вузьким місцем» (гальмом чи перепоною) або звинуватити у затримках випуску.
ISTQB Certified Tester Foundation Level. Курс для початківців. Секція 5.1.
В цьому відео починаємо працювати з секцією 5.1. 00:01:46 Independent Testing (v 3.1) 00:14:14 Tasks of a Test Manager and Tester (v 3.1) 00:30:41 Roles in Testing (v 4.0) 00:36:08 Independence of Testing (v 4.0)
ISTQB Certified Tester Foundation Level. Курс для початківців. Розділ 4. Практика.
В цьому відео працюємо з тестами до 4 розділу. 00:00:23 Static test design techniques 00:01:08 Dynamic test design techniques 00:02:38 Працюємо з тестами
Всі питання з відео з правильними відповідями наводяться нижче.
Question 1
One of the fields on a form contains a text box which accepts alphabets in lower or upper case. Identify the invalid Equivalence class value.
CLa01ss.
cLASS.
CLASS.
Class.
Question 2
“Experience based” test design techniques, typically
Use decision tables to generate the Boolean test conditions to be executed.
Identify the structure of the system or software at the component, integration or system level.
Use the skill, intuition and experience of the tester to derive the test cases, using error guessing and exploratory testing.
Establish traceability from test conditions back to the specifications and requirements.
Question 3
A piece of software has been given for testing. What tests from the following will you perform? 1) Test the areas most critical to business processes 2) Test the areas where faults will be maximum 3) Test the easiest functionalities
1 is true, 2&3 are false.
1&2 are false, 3 is true
1,2 &3 are true.
1&2 are true and 3 is false.
Question 4
Which of the following is a white box testing design characteristic?
To be based on specifications.
To be based on an analysis of the test basis documentation.
To be based on an analysis of the structure of the component or system.
To include both functional and non-functional testing.
Question 5
Which of the following test design techniques is not a black box technique?
Equivalence partitioning
State transition testing
Boundary value analysis
Statement coverage
Question 6
A program validates a numeric field as follows: Values less than 10 are rejected, values between 10 and 21 are accepted, values greater than or equal to 22 are rejected. Which of the following input values cover all of the equivalence partitions?
Consider the following: Pick up and read the newspaper. Look at what is on television. If there is a program that you are interested in watching then switch the television on and watch the program. Otherwise. Continue reading the newspaper. If there is a crossword in the newspaper then try and complete the crossword. Define SC and DC.
SC = 2 and DC = 2.
SC = 2 and DC = 3.
SC = 1 and DC = 3.
SC = 1 and DC = 1.
Question 9
Considering the following pseudo-code, calculate the MINIMUM number of test cases for statement coverage, and the MINIMUM number of test cases for decision coverage respectively. READ A READ B READ C IF C>A THEN IF C>B THEN PRINT ‘C must be smaller than at least one number’ ELSE PRINT ‘Proceed to next stage’ ENDIF ELSE PRINT ‘B can be smaller than C’ ENDIF
2, 4.
3, 2.
3, 3.
2, 3.
Question 10
Equivalence partitioning is:
A black box testing technique appropriate to all levels of testing
A black box testing technique used only by developers
A white box testing technique appropriate for component testing
A black box testing technique than can only be used during system testing
Question 11
What is static analysis?
The decision between using white and black box test techniques.
Executing software to validate the most common path through the code.
A technique to find defects in software source code and software models, performed without executing code.
It is a testing technique used during system testing.
Question 12
Features of White Box Testing Technique: (i.) We use explicit knowledge of the internal workings of the item being tested to select the test data. (ii.) Uses specific knowledge of programming code to examine outputs and assumes that the tester knows the path of logic in a unit or a program. (iii.) Checking for the performance of the application (iv.) Also checks for functionality.
i, ii are true and iii and iv are false.
ii ,iii is true and i,iv is false.
iii is true and i,ii, iv are false.
iii and iv are true and i,ii are false.
Question 13
Consider the following pseudo code: Begin Input X, Y If X > Y __Print (X, ‘is greater than’, Y) Else __Print (Y, is greater than or equal to’, X) Endlf End
What is the minimum number of test cases required to guarantee both 100% statement coverage and 100% decision coverage?
Statement coverage = 3, Decision coverage = 3
Statement coverage = 2, Decision coverage = 2
Statement coverage = 1, Decision coverage = 2
Statement coverage = 2, Decision coverage = 1
Question 14
For the code fragment given below, which answer correctly represents minimum tests required for statement and branch coverage respectively? Discount rate=1; Fare = 1000; If ((person == “senior citizen”) and (“travel month = January”)) Bonuspoints = 100+Bonuspoints If (class==”first”) discountRate = .5; Fare = fare * discountRate;
Statement Coverage = 2, Branch Coverage = 4
Statement Coverage = 2, Branch Coverage = 2
Statement Coverage = 1, Branch Coverage = 3
Statement Coverage = 1, Branch Coverage = 2
Question 15
What is decision table testing?
It’s a testing design technique based in the internal software structure.
It’s a static test design technique.
It’s a testing design technique to verify decisions.
It’s a testing design technique based in the system requirements.
Question 16
Given the following code, which is true: IF A > B THEN C = A – B ELSE C = A + B ENDIF Read D IF C = D Then Print “Error” ENDIF
3 tests for statement coverage, 3 for branch coverage.
2 tests for statement coverage. 3 for branch coverage.
1 test for statement coverage, 3 for branch coverage.
2 tests for statement coverage, 2 for branch coverage.
Question 17
Given the following specification, which of the following values for age are in the SAME equivalence partition? If you are less than 18, you are too young to be insured. Between 18 and 30 inclusive, you will receive a 20% discount. Anyone over 30 is not eligible for a discount.
17, 18, 19.
17, 29, 31.
29, 30, 31.
18, 29, 30.
Question 18
Given the following: Switch PC on Start “outlook” IF outlook appears THEN Send an email Close outlook
1 test for statement coverage, 2 for branch coverage.
1 test for statement coverage, 1 for branch coverage.
2 tests for statement coverage, 3 for branch coverage.
1 test for statement coverage. 3 for branch coverage.
Question 19
Equivalence Partitioning is best defined as:
An technique that divides inputs into groups that are expected to exhibit similar behaviors.
Applying to time-related data classes only.
A form of white-box testing.
A method to reduce test coverage.
Question 20
Which of the following best describes the Black-box technique?
It uses decision coverage for completeness.
It ensures all possible branches in the code are tested.
It is based on the internal structure of the system.
It can be done without reference to the internal structure of the component or system.
Question 21
What is a test condition?
A statement of test objectives and test ideas on how to test.
An item or event that could be verified by one or more test cases.
The process of identifying differences between the actual results and the expected results for a test.
All documents from which the requirements of a component or system can be inferred.
Question 22
In a flight reservation system, the number of available seats in each plane model is an input. A plane may have any positive number of available seats, up to the given capacity of the plane. Using Boundary Value analysis, a list of available – seat values were generated. Which of the following lists is correct?
0, 1, 2, capacity plus 1, a very large number.
0, 1, 10, 100, capacity, capacity plus one.
0, 1, capacity, capacity plus 1.
1, 2, capacity -1, capacity, capacity plus 1.
Question 23
Why are error guessing and exploratory testing good to do?
They will ensure that all of the code or system is tested.
They can be used most effectively when there are good specifications.
They can find defects missed by specification based and structure-based techniques.
They don’t require any training to be as effective as formal techniques.