ISTQB Certified Tester Foundation Level. Курс для початківців. Секція 5.2.

Цілі і зміст тестового плану (версія 3.1)

У плані тестування описано тестування для проєктів розробки та обслуговування. На планування впливають політика тестування та стратегія тестування організації, життєві цикли розробки та методи, що використовуються, сфера тестування, цілі, ризики, обмеження, критичність, можливість тестування та доступність ресурсів.

У міру просування проєкту та планування тестування стає доступніше більше інформації, і в план тестування можна включити більше деталей. Планування випробувань — це безперервна діяльність, яка виконується протягом життєвого циклу продукту. (Зауважте, що життєвий цикл продукту може виходити за рамки проєкту та включати етап технічного обслуговування.) Зворотній зв’язок від тестової діяльності слід використовувати для визначення мінливих ризиків, щоб можна було скоригувати планування. Планування може бути задокументовано в генеральному плані тестування та в окремих планах тестування для рівнів тестування, таких як тестування системи та приймальне тестування, або для окремих типів тестування, таких як тестування зручності використання та тестування продуктивності.

Заходи з планування тестування можуть включати наступне, і деякі з них можуть бути задокументовані в плані тестування:

• Визначення обсягу, цілей і ризиків тестування
• Визначення загального підходу до тестування
• Інтеграція та координація тестової діяльності в діяльність життєвого циклу програмного забезпечення
• Прийняття рішень щодо того, що тестувати, людей та інших ресурсів, необхідних для виконання різноманітних тестових дій, і способів проведення тестових дій
• Планування аналізу, проєктування, реалізації, виконання та оцінювання тестів на певні дати (наприклад, у послідовній розробці) або в контексті кожної ітерації (наприклад, у ітераційній розробці)
• Вибір метрик для моніторингу та контролю тестів
• Бюджет для тестової діяльності
• Визначення рівня деталізації та структури тестової документації (наприклад, шляхом надання шаблонів або прикладів документів)

Зміст тестових планів може бути різним і може виходити за межі тем, визначених вище. Зразок структури плану тестування та зразок плану тестування можна знайти в стандарті 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 (розгляд технології, критика продукту). Цей квадрант містить димові тести та нефункціональні тести (крім тестів зручності використання). Ці тести часто автоматизовані.

В цьому відео починаємо працювати з секцією 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)