Після розгортання у виробничих середовищах програмне забезпечення та системи потребують обслуговування. Зміни різного роду майже неминучі в наданому програмному забезпеченні та системах, або для виправлення дефектів, виявлених під час оперативного використання, для додавання нових функціональних можливостей, або для видалення чи зміни вже наданих функціональних можливостей. Технічне обслуговування також необхідне для збереження або покращення нефункціональних якісних характеристик компонента або системи протягом терміну служби, особливо продуктивності, сумісності, надійності, безпеки та портативності.
Коли вносяться будь-які зміни в рамках технічного обслуговування, необхідно провести тестування технічного обслуговування, щоб оцінити успішність внесених змін і перевірити можливі побічні ефекти (наприклад, регресії) у частинах системи, які залишаються незмінними (що зазвичай є більшою частиною системи).
Технічне обслуговування може включати заплановані та незаплановані випуски (гарячі виправлення).
Реліз обслуговування може вимагати тестування обслуговування на кількох рівнях тестування з використанням різних типів тестування залежно від його обсягу. Обсяг технічного обслуговування залежить від:
Ступіню ризику зміни, наприклад, ступінь зв’язку зміненої області програмного забезпечення з іншими компонентами чи системами
Розмір існуючої системи
Розмір зміни
Тригери для супроводу
Існує кілька причин, чому технічне обслуговування програмного забезпечення, а отже, тестування супроводу, має місце як для запланованих, так і для незапланованих змін.
Модифікації, такі як заплановані вдосконалення (наприклад, на основі випуску), коригування та екстрені зміни, зміни робочого середовища (наприклад, заплановані оновлення операційної системи або бази даних), оновлення програмного забезпечення COTS та виправлення дефектів і вразливостей
Міграція, наприклад, з однієї платформи на іншу, яка може вимагати операційних тестів нового середовища, а також зміненого програмного забезпечення, або тестів перетворення даних, коли дані з іншої програми будуть перенесені в систему, що обслуговується.
Вихід з експлуатації, наприклад, коли програма досягає кінця свого життя. Якщо програму або систему виведено з експлуатації, це може вимагати тестування міграції даних або архівування, якщо потрібні тривалі періоди зберігання даних.
Також може знадобитися перевірка процедур відновлення після архівування протягом тривалого періоду зберігання.
може знадобитися регресійне тестування, щоб переконатися, що будь-які функції, які залишаються в системі, все ще працюють.
Для систем Інтернету речей тестування технічного обслуговування може бути викликано впровадженням абсолютно нових або модифікованих речей, таких як апаратні пристрої та програмні служби, у загальну систему. Тестування технічного обслуговування для таких систем приділяє особливу увагу тестуванню інтеграції на різних рівнях (наприклад, рівень мережі, рівень програми) та аспектам безпеки, зокрема тим, що стосуються персональних даних.
Аналізу впливу для супроводу
Аналіз впливу оцінює зміни, внесені в релізі для обслуговування, щоб визначити передбачувані наслідки, а також очікувані й можливі побічні ефекти змін, а також визначити області системи, на які вплинуть зміни. Аналіз впливу також може допомогти визначити вплив зміни на існуючі тести. Побічні ефекти та уражені області в системі потрібно перевірити на регресії, можливо, після оновлення будь-яких існуючих тестів, на які вплинула зміна.
Аналіз впливу може бути проведений до внесення змін, щоб допомогти вирішити, чи слід вносити зміни, виходячи з потенційних наслідків в інших областях системи.
Аналіз впливу може бути складним, якщо:
Специфікації (наприклад, бізнес-вимоги, історії користувачів, архітектура) застаріли або відсутні
Тестові випадки не задокументовані або застаріли
Двонаправлена відстежуваність між тестами та тестовою основою не підтримується
Підтримка інструментів слабка або відсутня
Залучені люди не володіють предметними знаннями або знанням системи
Під час розробки недостатньо уваги приділено зручності супроводу програмного забезпечення
Тестування супроводу (версія 4.0)
Існують різні категорії технічного обслуговування, воно може бути коригуючим, адаптованим до змін у середовищі або покращувати продуктивність або зручність обслуговування (ISO/IEC 14764), тому технічне обслуговування може включати заплановані випуски/розгортання та незаплановані випуски/розгортання (гарячі виправлення) . Аналіз впливу може бути проведений до внесення змін, щоб допомогти вирішити, чи слід вносити зміни, виходячи з потенційних наслідків в інших областях системи. Тестування змін у системі в робочому стані включає як оцінку успішності впровадження змін, так і перевірку можливих регресій у частинах системи, які залишаються незмінними (як правило, більша частина системи).
Обсяг технічного обслуговування зазвичай залежить від:
Ступінь ризику зміни
Розмір існуючої системи
Розмір зміни
Тригери для технічного обслуговування та тестування технічного обслуговування можна класифікувати таким чином:
Зміни, такі як заплановані вдосконалення (тобто на основі випуску), коригувальні зміни або гарячі виправлення.
Оновлення або міграція робочого середовища, наприклад, з однієї платформи на іншу, що може вимагати тестування, пов’язаного з новим середовищем, а також зміненого програмного забезпечення, або тестування перетворення даних, коли дані з іншої програми переносяться в систему.
Вихід з експлуатації, наприклад, коли програма досягає кінця свого життя. Коли система виводиться з експлуатації, це може вимагати тестування архівування даних, якщо потрібні тривалі періоди зберігання даних. Тестування процедур відновлення та пошуку після архівування також може знадобитися, якщо під час архівування потрібні певні дані.
ISTQB Certified Tester Foundation Level. Курс для початківців. Секція 2.4.
В цьому відео починаємо працювати з секцією 2.4. 00:01:26 Тестування підтримки (Maintenance testing) 00:05:46 Тригери для підтримки(обслуговування) Triggers for Maintenance 00:14:14 Аналіз впливу для підтримки (осблуговування) 00:20:09 Maintenance Testing (v 4.0)
Тип тестування — це група тестових дій, спрямованих на перевірку конкретних характеристик програмної системи або частини системи на основі конкретних цілей тестування. Такі цілі можуть включати:
Оцінка характеристик функціональної якості, таких як повнота, правильність і відповідність
Оцінка нефункціональних характеристик якості, таких як надійність, продуктивність, безпека, сумісність і зручність використання
Оцінка того, чи структура або архітектура компонента чи системи є правильною, повною та відповідає вимогам
Оцінка наслідків змін, як-от підтвердження того, що дефекти виправлено (підтверджувальне тестування) та пошук ненавмисних змін у поведінці внаслідок змін програмного забезпечення чи середовища (регресійне тестування)
Функціональне тестування
Функціональне тестування системи включає тести, які оцінюють функції, які система повинна виконувати. Функціональні вимоги можуть бути описані в робочих продуктах, таких як специфікації бізнес-вимог, епіки, історії користувачів, варіанти використання або функціональні специфікації, або вони можуть бути незадокументованими. Функції – це «те, що» повинна робити система.
Функціональні тести слід виконувати на всіх рівнях тестування (наприклад, тести для компонентів можуть базуватися на специфікації компонентів), хоча фокус на кожному рівні різний.
Функціональне тестування розглядає поведінку програмного забезпечення, тому методи чорної скриньки можуть бути використані для отримання умов тестування та тестових випадків для функціональності компонента чи системи.
Ретельність функціонального тестування можна виміряти за допомогою функціонального покриття. Функціональне покриття – це ступінь, до якого певна функціональність була використана тестами, і виражається у відсотках від типу покритого елемента. Наприклад, використовуючи відстежуваність між тестами та функціональними вимогами, можна розрахувати відсоток цих вимог, які охоплюються тестуванням, потенційно виявивши прогалини в покритті.
Розробка та виконання функціональних тестів може вимагати спеціальних навичок або знань, таких як знання конкретної бізнес-проблеми, яку вирішує програмне забезпечення (наприклад, програмне забезпечення для геологічного моделювання для нафтової та газової промисловості).
Нефункціональне тестування
Нефункціональне тестування системи оцінює характеристики систем і програмного забезпечення, такі як зручність використання, ефективність продуктивності або безпека. Нефункціональне тестування — це перевірка того, «наскільки добре» поводиться система.
Всупереч поширеній помилковій думці, нефункціональне тестування можна і часто потрібно проводити на всіх рівнях тестування, і робити це якомога раніше. Пізнє виявлення нефункціональних дефектів може бути надзвичайно небезпечним для успіху проекту.
Методи чорної скриньки можуть бути використані для отримання умов тестування та тестових кейсів для нефункціонального тестування. Наприклад, аналіз граничних значень можна використовувати для визначення умов напруги для тестування продуктивності.
Ретельність нефункціонального тестування можна виміряти за допомогою нефункціонального покриття. Нефункціональне покриття – це ступінь, до якого певний тип нефункціонального елемента перевіряється тестами, і виражається у відсотках від типу покритого елемента. Наприклад, використовуючи відстеження між тестами та підтримуваними пристроями для мобільної програми, можна обчислити відсоток пристроїв, які розглядаються тестуванням на сумісність, потенційно виявивши прогалини в охопленні.
Розробка та виконання нефункціонального тесту може включати спеціальні навички чи знання, такі як знання притаманних недоліків дизайну чи технології (наприклад, уразливості безпеки, пов’язані з певними мовами програмування) або конкретної бази користувачів (наприклад, персоналії користувачів системи управління закладом охорони здоров’я).
Тестування білої скриньки
Тестування білої скриньки виводить тести на основі внутрішньої структури або реалізації системи. Внутрішня структура може включати код, архітектуру, робочі процеси або потоки даних у системі.
Ретельність тестування білої скриньки можна виміряти через структурне покриття. Структурне покриття — це ступінь, до якого певний тип структурного елемента перевірено тестами, і виражається у відсотках від типу охопленого елемента.
На рівні тестування компонентів охоплення коду базується на відсотку перевіреного коду компонента та може вимірюватися з точки зору різних аспектів коду (елементів охоплення), таких як відсоток виконуваних операторів, протестованих у компоненті, або відсоток перевірених результатів рішення. Ці типи покриття разом називають покриттям коду. На рівні тестування інтеграції компонентів тестування білої скриньки може ґрунтуватися на архітектурі системи, наприклад на інтерфейсах між компонентами, а структурне покриття може вимірюватися у відсотках інтерфейсів, які перевіряються тестами.
Розробка та виконання тесту «білої скриньки» може включати спеціальні навички чи знання, наприклад спосіб створення коду, спосіб зберігання даних (наприклад, для оцінки можливих запитів до бази даних), а також те, як використовувати інструменти покриття та правильно інтерпретувати їхні результати.
Тестування пов’язане зі змінами
Коли в систему вносяться зміни або для виправлення дефекту, або через нову чи змінену функціональність, слід провести тестування, щоб підтвердити, що зміни виправили дефект або реалізували функціональні можливості належним чином і не спричинили жодних непередбачуваних несприятливих наслідків.
Підтверджуюче тестування: після усунення дефекту програмне забезпечення можна перевірити за допомогою всіх тестових кейсів, які не пройшли через дефект, які слід повторно виконати на новій версії програмного забезпечення. Програмне забезпечення також може бути перевірено за допомогою нових тестів, щоб охопити зміни, необхідні для усунення дефекту. Щонайменше кроки для відтворення помилок, викликаних дефектом, необхідно виконати повторно в новій версії програмного забезпечення. Метою підтверджувального тесту є підтвердження того, чи було успішно виправлено початковий дефект.
Регресійне тестування: можливо, що зміна, внесена в одну частину коду, будь то виправлення чи зміна іншого типу, може випадково вплинути на поведінку інших частин коду, незалежно від того, в межах того самого компонента, в інших компонентах тій же системі або навіть в інших системах. Зміни можуть включати зміни в середовищі, такі як нова версія операційної системи або системи керування базами даних. Такі ненавмисні побічні ефекти називаються регресією. Регресійне тестування передбачає виконання тестів для виявлення таких небажаних побічних ефектів.
Особливо в ітераційних і поетапних життєвих циклах розробки (наприклад, Agile), нові функції, зміни існуючих функцій і рефакторинг коду призводять до частих змін коду, що також вимагає тестування, пов’язаного зі змінами. Через те, що система розвивається, підтверджуюче та регресійне тестування є дуже важливими. Це особливо важливо для систем Інтернету речей, де окремі об’єкти (наприклад, пристрої) часто оновлюються або замінюються.
Набори регресійних тестів виконуються багато разів і, як правило, розвиваються повільно, тому регресійне тестування є сильним кандидатом на автоматизацію. Автоматизацію цих тестів слід починати на ранніх стадіях проекту.
Тестові типи та тестові рівні
Можна виконати будь-який із зазначених вище типів тестів на будь-якому рівні тестування. Для ілюстрації приклади функціональних, нефункціональних, і тестів білої скриньки, пов’язаних зі змінами, будуть наведені на всіх рівнях тестування для банківської програми, починаючи з функціональних тестів:
Для тестування компонентів тести розроблені на основі того, як компонент має обчислювати складні відсотки.
Для тестування інтеграції компонентів тести розроблені на основі того, як інформація облікового запису, отримана в інтерфейсі користувача, передається до бізнес-логіки.
Для тестування системи тести розроблені на основі того, як власники рахунків можуть подати заявку на отримання кредитної лінії на своїх поточних рахунках.
Для тестування інтеграції системи тести розроблено на основі того, як система використовує зовнішній мікросервіс для перевірки кредитної оцінки власника облікового запису.
Для перевірки приймання тести розроблені на основі того, як банкір розглядає схвалення або відхилення кредитної заявки.
Нижче наведено приклади нефункціональних тестів:
Для тестування компонентів тести продуктивності призначені для оцінки кількості циклів процесора, необхідних для виконання складного розрахунку сумарних відсотків.
Для тестування інтеграції компонентів тести безпеки призначені для вразливості переповнення буфера через дані, що передаються від інтерфейсу користувача до бізнес-логіки.
Для тестування системи тести переносимості призначені для перевірки того, чи рівень презентації працює на всіх підтримуваних браузерах і мобільних пристроях.
Для тестування системної інтеграції тести надійності призначені для оцінки надійності системи, якщо мікросервіс кредитної оцінки не відповідає.
Для приймального тестування тести на зручність використання призначені для оцінки доступності інтерфейсу банківської обробки кредитів для людей з обмеженими можливостями.
Нижче наведено приклади тестів білої скриньки:
Для тестування компонентів тести розроблені для досягнення повного охоплення операторів і рішень для всіх компонентів, які виконують фінансові розрахунки.
Для тестування інтеграції компонентів тести призначені для визначення того, як кожен екран в інтерфейсі браузера передає дані на наступний екран і в бізнес-логіку.
Для тестування системи тести призначені для охоплення послідовностей веб-сторінок, які можуть з’являтися під час подачі заявки на кредитну лінію.
Для тестування системної інтеграції тести розроблені для виконання всіх можливих типів запитів, надісланих до мікросервісу кредитних оцінок.
Для приймального тестування тести розроблено для охоплення всіх підтримуваних структур файлів фінансових даних і діапазонів значень для міжбанківських переказів.
Нижче наведено приклади тестів, пов’язаних зі змінами:
Для тестування компонентів автоматизовані регресійні тести створюються для кожного компонента та включаються в структуру безперервної інтеграції.
Для тестування інтеграції компонентів тести призначені для підтвердження виправлень пов’язаних з інтерфейсом дефектів, коли виправлення перевіряються в сховищі коду.
Для тестування системи всі тести для даного робочого циклу виконуються повторно, якщо будь-який екран цього робочого процесу змінюється.
Для тестування системної інтеграції тести програми, яка взаємодіє з мікросервісом оцінки кредитоспроможності, повторно виконуються щодня в рамках безперервного розгортання цього мікросервісу.
Для приймального тестування всі попередньо невдалі тести виконуються повторно після усунення дефекту, виявленого під час приймального тестування.
Хоча в цьому розділі наведено приклади кожного типу тесту на кожному рівні, для всього програмного забезпечення необов’язково мати кожен тип тесту на кожному рівні. Однак важливо запускати відповідні типи тестів на кожному рівні, якомога раніше.
Типи тестування (версія 4.0)
Існує багато типів тестування, які можна застосовувати в проєктах. У цьому сілабусі розглядаються наступні чотири типи тестів: функціональне тестування, нефункціональне тестування, тестування чорної скриньки, тестування білої скриньки.
Функціональне тестування оцінює функції, які повинен виконувати компонент або система. Функції – це «те, що» повинен робити тестовий об’єкт. Основною метою функціонального тестування є перевірка функціональної повноти, функціональної правильності та функціональної відповідності.
Нефункціональне тестування оцінює атрибути, відмінні від функціональних характеристик компонента або системи. Нефункціональне тестування — це перевірка того, «наскільки добре поводиться система». Основною метою нефункціонального тестування є перевірка характеристик якості нефункціонального програмного забезпечення. Стандарт ISO/IEC 25010 надає таку класифікацію характеристик якості нефункціонального програмного забезпечення:
Ефективність виконання
Сумісність
Зручність використання
Надійність
Безпека
Ремонтопридатність
Портативність
Іноді нефункціональне тестування доцільно розпочинати на ранніх стадіях життєвого циклу (наприклад, як частину перевірки та тестування компонентів або тестування системи). Багато нефункціональних тестів є похідними від функціональних тестів, оскільки вони використовують ті самі функціональні тести, але перевіряють, що під час виконання функції виконується нефункціональне обмеження (наприклад, перевірка того, що функція виконується протягом заданого часу, або функція може перенести на нову платформу). Пізнє виявлення нефункціональних дефектів може становити серйозну загрозу для успіху проєкту. Для нефункціонального тестування іноді потрібне дуже специфічне тестове середовище, наприклад лабораторія зручності використання для тестування зручності використання.
Тестування чорної скриньки базується на специфікаціях і одержує тести з документації щодо об’єкта тестування. Основна мета тестування чорної скриньки — перевірити поведінку системи на відповідність її специфікаціям.
Тестування білої скриньки базується на структурі та виводить тести з реалізації або внутрішньої структури системи (наприклад, коду, архітектури, робочих процесів і потоків даних). Основна мета тестування білої скриньки — охопити базову структуру тестами до прийнятного рівня.
Усі чотири вищезазначені типи тестування можна застосовувати до всіх рівнів тестування, хоча фокус буде різним на кожному рівні. Різні методи тестування можуть бути використані для отримання тестових умов і тестових випадків для всіх згаданих типів тестування.
Тестування і зміни (v 4.0)
Зміни, як правило, вносяться до компонента чи системи, щоб або покращити його, додавши нову функцію, або виправити це, усунувши дефект. Тоді тестування має також включати тестування на підтвердження та регресійне тестування.
Підтверджувальне тестування підтверджує, що початковий дефект було успішно виправлено. Залежно від ризику можна протестувати виправлену версію програмного забезпечення кількома способами, зокрема:
виконання всіх тестових прикладів, які раніше були невдалими через дефект, або також через
додавання нових тестів для покриття будь-яких змін, необхідних для усунення дефекту
Однак, коли для усунення дефектів бракує часу або грошей, перевірка підтвердження може бути обмежена простим виконанням кроків, які повинні відтворити збій, викликаний дефектом, і перевіркою того, що збій не виникає.
Регресійне тестування підтверджує відсутність несприятливих наслідків через зміни, включаючи виправлення, яке вже пройшло підтверджувальне тестування. Ці несприятливі наслідки можуть вплинути на той самий компонент, де було внесено зміни, інші компоненти в тій же системі або навіть інші підключені системи. Регресійне тестування може не обмежуватися самим тестовим об’єктом, але також може бути пов’язане з навколишнім середовищем. Бажано спочатку виконати аналіз впливу, щоб оптимізувати обсяг регресійного тестування. Аналіз впливу показує, на які частини програмного забезпечення це може вплинути.
Набори регресійних тестів виконуються багато разів, і зазвичай кількість регресійних тестів зростатиме з кожною ітерацією або випуском, тому регресійне тестування є сильним кандидатом на автоматизацію. Автоматизацію цих тестів слід починати на ранніх стадіях проєкту. Там, де використовується CI, наприклад у DevOps, доцільно також включити автоматизовані регресійні тести. Залежно від ситуації це може включати регресійні тести на різних рівнях.
Підтверджувальне тестування та регресійне тестування об’єкта тестування необхідно на всіх рівнях тестування, якщо на цих рівнях тестування виправлено дефекти або внесено зміни.
ISTQB Certified Tester Foundation Level. Курс для початківців. Секція 2.3.
В цьому відео починаємо працювати з секцією 2.3. 00:00:43 Типи тестування 00:03:12 Функціональне тестування 00:07:18 Нефункціональне тестування 00:12:15 Тестування білої скриньки 00:17:04 Тестування пов’язане зі змінами 00:24:35 Типи тестування та Рівні тестування 00:37:39 Типи тестування (v 4.0)
Рівні тестування – це групи тестових дій, які організовуються та керуються разом. Кожен рівень тестування — це екземпляр процесу тестування, що виконується стосовно програмного забезпечення на даному рівні розробки, від окремих одиниць або компонентів до повних систем. Рівні тестування пов’язані з іншими діями в рамках життєвого циклу розробки програмного забезпечення. Виділяють такі рівні тестування:
Тестування компонентів
Інтеграційне тестування
Тестування системи
Приймальне тестування
Рівні тесту характеризуються такими ознаками:
Конкретні цілі
Основа тестування, на яку посилаються для отримання тестових випадків
Тестовий об’єкт (тобто те, що тестується)
Типові дефекти та збої
Специфічні підходи та відповідальність
Для кожного рівня тестування потрібне відповідне тестове середовище. Наприклад, під час приймального тестування ідеальним є тестове середовище, схоже на робоче, тоді як у компонентному тестуванні розробники зазвичай використовують власне середовище розробки.
Component Testing
Цілі компонентного тестування
Тестування компонентів (також відоме як модульне або юніт тестування) зосереджується на компонентах, які можна тестувати окремо. Цілі тестування компонентів включають:
Зменшення ризику
Перевірка того, чи функціональна та нефункціональна поведінка компонента відповідає специфікації
Побудова впевненості в якості компонента
Виявлення дефектів у компоненті
Запобігання виходу дефектів на вищі рівні тестування
У деяких випадках, особливо в поетапних і ітеративних моделях розробки (наприклад, Agile), де тривають зміни коду, автоматизовані регресійні тести компонентів відіграють ключову роль у зміцненні впевненості в тому, що зміни не пошкодили існуючі компоненти.
Тестування компонентів часто виконується ізольовано від решти системи, залежно від моделі життєвого циклу розробки програмного забезпечення та системи, для чого можуть знадобитися макетні об’єкти, віртуалізація служб, джгути, заглушки та драйвери. Тестування компонентів може охоплювати функціональні можливості (наприклад, правильність обчислень), нефункціональні характеристики (наприклад, пошук витоків пам’яті) і структурні властивості (наприклад, тестування рішень).
Тестова база
Приклади робочих продуктів, які можна використовувати як тестову базу для тестування компонентів, включають:
Детальний дизайн
Код
Модель даних
Характеристики компонентів
Об’єкти тестування
Типові тестові об’єкти для тестування компонентів включають:
Компоненти, вузли або модулі
Код і структури даних
Класи
Модулі бази даних
Дефекти, як правило, усуваються відразу після їх виявлення, часто без офіційного управління дефектами. Однак коли розробники повідомляють про дефекти, це надає важливу інформацію для аналізу першопричини та вдосконалення процесу.
Конкретні підходи та відповідальність
Тестування компонентів зазвичай виконує розробник, який написав код, але для цього принаймні потрібен доступ до тестованого коду. Розробники можуть чергувати розробку компонента з пошуком і виправленням дефектів. Розробники часто пишуть і виконують тести після написання коду для компонента. Однак, особливо в гнучкій розробці, написання автоматизованих тестових випадків компонентів може передувати написанню програмного коду.
Наприклад, розглянемо розробку, керовану тестуванням (TDD). Розробка, орієнтована на тестування, є високоітеративною та базується на циклах розробки автоматизованих тестових випадків, потім створення та інтеграції невеликих фрагментів коду, а потім виконання тестів компонентів, виправлення будь-яких проблем і рефакторинг коду. Цей процес триває до тих пір, поки компонент не буде повністю зібрано та всі компоненти не пройдуть тестування. Розробка, орієнтована на тестування, є прикладом підходу «спочатку тестування». Хоча розробка, керована тестуванням, виникла в eXtreme Programming (XP), вона поширилася на інші форми Agile, а також на послідовні життєві цикли.
Integration Testing
Цілі інтеграційного тестування
Інтеграційне тестування фокусується на взаємодії між компонентами або системами. Цілі інтеграційного тестування включають:
Зменшення ризику
Перевірка того, чи функціональна та нефункціональна поведінка інтерфейсів відповідає дизайну та специфікаціям
Побудова впевненості в якості інтерфейсів
Пошук дефектів (які можуть бути в самих інтерфейсах або всередині компонентів чи систем)
Запобігання виходу дефектів на вищі рівні тестування
Як і у випадку з тестуванням компонентів, у деяких випадках автоматизовані регресійні тести інтеграції забезпечують впевненість у тому, що зміни не порушили існуючі інтерфейси, компоненти чи системи.
Виділяють два різних рівня інтеграційного тестування, яке можна проводити на об’єктах тестування різного розміру, як описано нижче:
Тестування інтеграції компонентів фокусується на взаємодії та інтерфейсах між інтегрованими компонентами. Тестування інтеграції компонентів виконується після тестування компонентів і, як правило, автоматизоване. При ітераційній та поетапній розробці тести інтеграції компонентів зазвичай є частиною процесу безперервної інтеграції.
Тестування системної інтеграції фокусується на взаємодії та інтерфейсах між системами, пакетами та мікросервісами. Тестування системної інтеграції також може охоплювати взаємодію із зовнішніми організаціями (наприклад, веб-сервісами) та інтерфейси, які надаються ними. У цьому випадку організація-розробник не контролює зовнішні інтерфейси, що може створювати різні проблеми для тестування (наприклад, забезпечення усунення дефектів блокування тесту в коді зовнішньої організації, організація тестових середовищ тощо). Тестування системної інтеграції може проводитися після тестування системи або паралельно з поточними діями з тестування системи (як у послідовному, так і в ітеративному та поетапному розвитку).
Тестова база
Приклади робочих продуктів, які можна використовувати як тестову основу для інтеграційного тестування, включають:
Проєктування програмного забезпечення та системи
Діаграми послідовності
Специфікації інтерфейсу та протоколу зв’язку
Варіанти використання
Архітектура на рівні компонентів або системи
Робочі процеси
Визначення зовнішнього інтерфейсу
Об’єкти тестування
Типові тестові об’єкти для інтеграційного тестування включають:
Підсистеми
Бази даних
Інфраструктура
Інтерфейси
API
Мікросервіси
Типові дефекти та збої
Приклади типових дефектів і несправностей для тестування інтеграції компонентів включають:
Неправильні дані, відсутні дані або неправильне кодування даних
Неправильна послідовність або час викликів інтерфейсу
Невідповідність інтерфейсу
Збої в зв’язку між компонентами
Необроблені або неправильно оброблені збої зв’язку між компонентами
Неправильні припущення щодо значення, одиниць або меж даних, що передаються між компонентами
Приклади типових дефектів і збоїв для тестування системної інтеграції включають:
Неузгоджені структури повідомлень між системами
Неправильні дані, відсутні дані або неправильне кодування даних
Невідповідність інтерфейсу
Збої в зв’язку між системами
Необроблені або неправильно оброблені збої зв’язку між системами
Неправильні припущення щодо значення, одиниць або меж даних, що передаються між системами
Недотримання обов’язкових правил безпеки
Конкретні підходи та відповідальність
Тести інтеграції компонентів і тести інтеграції системи повинні зосереджуватися на самій інтеграції. Наприклад, у разі інтеграції модуля A з модулем B тести повинні зосереджуватися на зв’язку між модулями, а не на функціональності окремих модулів, оскільки це повинно бути розглянуто під час тестування компонентів. У разі інтеграції системи X із системою Y тести повинні зосереджуватися на зв’язку між системами, а не на функціональності окремих систем, оскільки це повинно бути розглянуто під час тестування системи. Застосовуються функціональні, нефункціональні та структурні типи випробувань.
Тестування інтеграції компонентів часто є обов’язком розробників. Тестування системної інтеграції зазвичай є обов’язком тестувальників. В ідеалі тестувальники, які виконують тестування інтеграції системи, повинні розуміти архітектуру системи та впливати на планування інтеграції.
Якщо інтеграційні тести та стратегія інтеграції плануються до створення компонентів або систем, ці компоненти або системи можна створювати в порядку, необхідному для найбільш ефективного тестування. Стратегії системної інтеграції можуть базуватися на архітектурі системи (наприклад, «зверху вниз» і «знизу вгору»), функціональних завданнях, послідовності обробки транзакцій або деяких інших аспектах системи чи компонентів. Щоб спростити ізоляцію дефектів і виявити дефекти на ранній стадії, інтеграція, як правило, повинна бути поступовою (тобто невелика кількість додаткових компонентів або систем одночасно), а не «великий вибух» (тобто інтеграція всіх компонентів або систем за один крок) . Аналіз ризиків найскладніших інтерфейсів може допомогти зосередити інтеграційне тестування.
Чим ширший обсяг інтеграції, тим важче стає ізолювати дефекти певного компонента чи системи, що може призвести до збільшення ризику та додаткового часу для усунення несправностей. Це одна з причин того, що безперервна інтеграція, коли програмне забезпечення інтегрується покомпонентно (тобто функціональна інтеграція), стала звичайною практикою. Така безперервна інтеграція часто включає автоматичне регресійне тестування, в ідеалі на кількох рівнях тестування.
Системне тестування
Цілі системного тестування
Тестування системи зосереджується на поведінці та можливостях усієї системи або продукту, часто враховуючи наскрізні завдання, які система може виконувати, і нефункціональну поведінку, яку вона демонструє під час виконання цих завдань. Цілі тестування системи включають:
Зменшення ризику
Перевірка того, чи функціональна та нефункціональна поведінка системи відповідає розробленим і специфікованим
Перевірка того, що система повна і працюватиме належним чином
Формування впевненості в якості системи в цілому
Пошук дефектів
Запобігання виходу дефектів на вищі рівні тестування або виробництва
Для певних систем перевірка якості даних також може бути метою. Подібно до тестування компонентів і тестування інтеграції, у деяких випадках автоматичні регресійні тести системи дають впевненість, що зміни не порушили існуючі функції чи наскрізні можливості. Тестування системи часто створює інформацію, яка використовується зацікавленими сторонами для прийняття рішень про випуск. Тестування системи також може задовольняти законодавчі чи нормативні вимоги або стандарти.
Тестове середовище в ідеалі має відповідати кінцевому цільовому або робочому середовищу.
Тестова база
Приклади робочих продуктів, які можна використовувати як тестову основу для тестування системи, включають:
Специфікації вимог до системи та програмного забезпечення (функціональні та нефункціональні)
Звіти про аналіз ризиків
Варіанти використання (Use cases)
Епіки та історії користувачів
Моделі поведінки системи
Діаграми стану
Системні інструкції та посібники користувача
Об’єкти тестування
Типові тестові об’єкти для тестування системи включають:
Додатки
Апаратні/програмні системи
Операційні системи
Система, яка тестується (SUT – System under test)
Конфігурація системи та конфігураційні дані
Типові дефекти та збої
Приклади типових дефектів і збоїв для тестування системи включають:
Неправильні розрахунки
Неправильна або несподівана функціональна або нефункціональна поведінка системи
Неправильний контроль і потоки даних у системі
Нездатність належним чином і повністю виконувати наскрізні функціональні завдання
Збій належної роботи системи в системному середовищі
Помилка роботи системи, порівняно з тим як описано в системній документації чи посібниках користувача
Конкретні підходи та відповідальність
Тестування системи має зосереджуватися на загальній наскрізній поведінці системи в цілому, як функціональної, так і нефункціональної. Тестування системи має використовувати найбільш відповідні методи для аспектів системи, що тестуються. Наприклад, може бути створена таблиця рішень, щоб перевірити, чи відповідає функціональна поведінка, як описано в бізнес-правилах.
Тестування системи зазвичай проводиться незалежними тестувальниками, які значною мірою покладаються на специфікації. Дефекти в специфікаціях (наприклад, відсутність історій користувачів, неправильно сформульовані бізнес-вимоги тощо) можуть призвести до нерозуміння або розбіжностей щодо очікуваної поведінки системи. Такі ситуації можуть спричинити хибні спрацьовування та хибні негативні результати, що витрачає час і знижує ефективність виявлення дефектів відповідно. Раннє залучення тестувальників до вдосконалення історій користувача або діяльності статичного тестування, наприклад оглядів, допомагає зменшити кількість таких ситуацій.
Приймальне тестування
Приймальне тестування, як і тестування системи, зазвичай зосереджується на поведінці та можливостях усієї системи чи продукту. Цілі приймального тестування включають:
Встановлення впевненості в якості системи в цілому
Перевірка того, що система повна і працюватиме належним чином
Перевірка того, що функціональна та нефункціональна поведінка системи відповідає специфікаціям
Приймальні випробування можуть дати інформацію для оцінки готовності системи до розгортання та використання замовником (кінцевим користувачем). Дефекти можуть бути виявлені під час приймального тестування, але виявлення дефектів часто не є метою, а виявлення значної кількості дефектів під час приймального тестування в деяких випадках може вважатися великим ризиком проєкту. Приймальне тестування також може перевіряти відповідність правовим чи нормативним вимогам або стандартам.
Загальні форми приймального тестування включають наступні:
Користувацьке приймальне тестування
Операційне приймальне тестування
Контрактне та регулятивне приймальне тестування
Альфа- і бета-тестування
Користувацьке приймальне тестування (UAT). Перевірка прийнятності системи для користувача зазвичай зосереджена на перевірці придатності системи для використання запланованими користувачами в реальному або змодельованому робочому середовищі. Основною метою є створення впевненості в тому, що користувачі можуть використовувати систему для задоволення своїх потреб, виконання вимог і виконання бізнес-процесів з мінімальними труднощами, витратами та ризиком.
Операційне приймальне тестування (OAT)
Приймальні випробування системи операторами цієї системи або системними адміністраторами, зазвичай їх виконують у (модельованому) виробничому(робочому) середовищі. Тести зосереджуються на робочих аспектах і можуть включати:
Тестування резервного копіювання та відновлення
Встановлення, видалення та оновлення
Аварійне відновлення
Керування користувачами
Завдання з технічного обслуговування
Завдання завантаження та міграції даних
Перевірка наявності вразливостей у безпеці
Тестування продуктивності
Основна мета операційної приймальної перевірки полягає в зміцненні впевненості в тому, що оператори або системні адміністратори можуть підтримувати належну роботу системи для користувачів у робочому середовищі, навіть за виняткових або складних умов.
Контрактне та нормативне приймальне тестування
Тестування прийнятності за контрактом виконується відповідно до критеріїв прийнятності контракту для виробництва програмного забезпечення, розробленого на замовлення. Критерії прийняття повинні бути визначені, коли сторони погоджуються на контракт. Контрактне приймальне тестування часто виконується користувачами або незалежними тестувальниками.
Нормативні приймальні випробування проводяться на відповідність будь-яким нормам, яких необхідно дотримуватися, наприклад державним, правовим нормам або нормам безпеки. Регуляторне приймальне тестування часто виконується користувачами або незалежними тестувальниками, іноді результати перевіряються або перевіряються регуляторними органами.
Основна мета тестування прийнятності за контрактами та нормативними документами полягає в зміцненні впевненості в тому, що було досягнуто відповідності договірним або нормативним вимогам.
Альфа і бета тестування
Альфа- та бета-тестування зазвичай використовують розробники комерційного готового програмного забезпечення (COTS), які хочуть отримати відгуки від потенційних або наявних користувачів, клієнтів та/або операторів до того, як програмний продукт буде випущено на ринок. Альфа-тестування виконується на сайті організації-розробника не командою розробників, а потенційними чи існуючими клієнтами та операторами чи незалежною командою тестування. Бета-тестування виконується потенційними чи існуючими клієнтами та операторами на їхніх власних місцях. Бета-тестування може відбуватися після альфа-тестування або може відбуватися без будь-якого попереднього альфа-тестування.
Однією з цілей альфа- та бета-тестування є формування впевненості серед потенційних або існуючих клієнтів або операторів у тому, що вони можуть використовувати систему в звичайних повсякденних умовах і в робочому середовищі для досягнення своїх цілей з мінімальними труднощами, витратами, і ризиком. Іншою метою може бути виявлення дефектів, пов’язаних з умовами та середовищем, у яких буде використовуватися система, особливо коли ці умови та середовище важко відтворити групі розробників.
Тестова база
Приклади робочих продуктів, які можна використовувати як тестову базу для будь-якої форми приймального тестування, включають:
Бізнес-процеси
Вимоги користувача або бізнесу
Норми, юридичні договори та стандарти
Варіанти використання та історії користувачів
Системні вимоги
Документація щодо системи або користувача
Процедури встановлення
Звіти про аналіз ризиків
Крім того, в якості тестової бази для отримання тестових прикладів для операційної приймальної перевірки можна використовувати один або кілька з наступних робочих продуктів:
Процедури резервного копіювання та відновлення
Процедури аварійного відновлення
Нефункціональні вимоги
Операційна документація
Інструкції з розгортання та встановлення
Цільові показники
Пакети баз даних
Стандарти або правила безпеки
Типові тест-об’єкти
Типові тестові об’єкти для будь-якої форми приймального тестування включають:
Система, яка тестується
Конфігурація системи та конфігураційні дані
Бізнес-процеси для повністю інтегрованої системи
Системи відновлення (для безперервності бізнесу та тестування аварійного відновлення)
Процеси експлуатації та обслуговування
Форми
Звіти
Існуючі та перетворені виробничі дані
Типові дефекти та збої
Приклади типових дефектів для будь-якої форми приймального тестування включають:
Системні робочі процеси не відповідають вимогам бізнесу чи користувача
Бізнес-правила реалізовані неправильно
Система не відповідає договірним або нормативним вимогам
Нефункціональні збої, як-от вразливість системи безпеки, недостатня продуктивність під час високих навантажень або неправильна робота на підтримуваній платформі
Конкретні підходи та відповідальність
Приймальне тестування часто є обов’язком клієнтів, бізнес-користувачів, власників продуктів або операторів системи, а також можуть бути залучені інші зацікавлені сторони.
Приймальне тестування часто розглядається як останній рівень тестування в послідовному життєвому циклі розробки, але воно також може відбуватися в інший час, наприклад:
Приймальні тестування програмного продукту COTS можуть відбуватися після його встановлення або інтеграції
Перед тестуванням системи може проводитися приймальне тестування нового функціонального вдосконалення
При ітераційній розробці команди проєкту можуть використовувати різні форми приймального тестування під час і в кінці кожної ітерації, наприклад ті, які зосереджені на перевірці нової функції за її критеріями прийнятності, і ті, які зосереджені на перевірці того, що нова функція задовольняє потреби користувачів. Крім того, альфа-тести та бета-тести можуть відбуватися в кінці кожної ітерації, після завершення кожної ітерації або після серії ітерацій. Користувацьке приймальне тестування, операційне приймальне тестування, нормативне приймальне тестування також можуть відбуватися наприкінці кожної ітерації, після завершення кожної ітерації або після серії ітерацій.
Тестові рівні (версія 4.0)
У сілабусі описано наступні п’ять рівнів тестування:
Тестування компонентів (також відоме як модульне тестування) зосереджується на тестуванні компонентів окремо. Для цього часто потрібна спеціальна підтримка, наприклад тестові пакети або фреймворки модульного тестування. Тестування компонентів зазвичай виконується розробниками у своїх середовищах розробки.
Тестування інтеграції компонентів (також відоме як тестування інтеграції модулів) зосереджується на тестуванні інтерфейсів і взаємодії між компонентами. Тестування інтеграції компонентів значною мірою залежить від підходів стратегії інтеграції, таких як «знизу вгору», «зверху вниз» або «великий вибух».
Тестування системи зосереджується на загальній поведінці та можливостях усієї системи або продукту, часто включаючи функціональне тестування наскрізних завдань і нефункціональне тестування характеристик якості. Для деяких нефункціональних характеристик якості бажано тестувати їх на повній системі в репрезентативному тестовому середовищі (наприклад, зручність використання). Також можливе використання моделювання підсистем. Тестування системи може виконуватися незалежною групою тестувальників і пов’язане зі специфікаціями системи.
Тестування системної інтеграції зосереджено на тестуванні інтерфейсів тестованої системи та інших систем і зовнішніх служб. Тестування системної інтеграції вимагає відповідних тестових середовищ, бажано подібних до робочого середовища.
Приймальне тестування зосереджено на перевірці та демонстрації готовності до розгортання, що означає, що система відповідає бізнес-потребам користувача. В ідеалі приймальне тестування має виконуватися цільовими користувачами. Основними формами приймального тестування є: приймальне тестування користувача (UAT), операційне приймальне тестування, договірне та нормативне приймальне тестування, альфа-тестування та бета-тестування.
Рівні тестування розрізняються за таким невичерпним списком атрибутів, щоб уникнути дублювання тестових дій:
Тестовий об’єкт
Цілі тестування
Тестова база
Дефекти та збої
Підхід та відповідальність
ISTQB Certified Tester Foundation Level. Курс для початківців. Секція 2.2.
В цьому відео починаємо працювати з секцією 2.2. 00:01:05 Рівні тестування 00:04:27 Тестування компонентів 00:14:38 Інтеграційне тестування 00:35:59 Системне тестування 00:51:33 Приймальне тестування 01:17:05 Рівні тестування (версія 4.0)
Моделі життєвого циклу програмного забезпечення (SDLC, версія 3.1)
Модель життєвого циклу розробки програмного забезпечення описує типи дій, що виконуються на кожному етапі проєкту розробки програмного забезпечення, а також те, як дії пов’язані одна з одною логічно та хронологічно. Існує кілька різних моделей життєвого циклу розробки програмного забезпечення, кожна з яких вимагає різних підходів до тестування.
Розробка програмного забезпечення і тестування ПЗ (версія 3.1)
Важливою частиною ролі тестувальника є знайомство із типовими моделями життєвого циклу розробки програмного забезпечення, щоб можна було проводити відповідні тестові дії.
У будь-якій моделі життєвого циклу розробки програмного забезпечення є кілька характеристик якісного тестування:
Для кожної розробки є відповідна тестова діяльність
Кожен рівень тестування має цілі тестування, специфічні для цього рівня
Аналіз і проєктування тестування для заданого рівня тестування починаються під час відповідної діяльності з розробки
Тестувальники беруть участь в обговореннях, щоб визначити й удосконалити вимоги та дизайн, а також залучаються до перегляду робочих продуктів (наприклад, вимог, історій користувачів тощо).
Незалежно від обраної моделі життєвого циклу розробки програмного забезпечення, тестування має починатися на ранніх стадіях життєвого циклу, дотримуючись принципу раннього тестування.
ISTQB класифікує загальні моделі життєвого циклу розробки програмного забезпечення таким чином:
Моделі послідовної розробки
Ітераційні та інкрементальні моделі розробки
Модель послідовної розробки описує процес розробки програмного забезпечення як лінійний послідовний потік дій. Це означає, що будь-яка фаза процесу розробки повинна починатися після завершення попередньої фази. Теоретично фази не збігаються, але на практиці корисно мати ранній зворотній зв’язок із наступної фази.
У моделі Waterfall дії з розробки (наприклад, аналіз вимог, проєктування, кодування, тестування) виконуються одна за одною. У цій моделі тестування відбувається лише після завершення всіх інших дій розробки.
На відміну від моделі Waterfall, V-модель інтегрує процес тестування протягом усього процесу розробки, реалізуючи принцип раннього тестування. Крім того, V-модель включає рівні тестування, пов’язані з кожною відповідною фазою розробки, що додатково підтримує раннє тестування. У цій моделі виконання тестів, пов’язаних з кожним рівнем тестування, відбувається послідовно, але в деяких випадках відбувається накладання.
Моделі послідовної розробки забезпечують програмне забезпечення, яке містить повний набір функцій, але зазвичай потрібні місяці або роки для доставки зацікавленим сторонам і користувачам.
Поступова розробка включає встановлення вимог, проєктування, створення та тестування системи по частинах, що означає, що функції програмного забезпечення розширюються поступово. Розмір цих приростів функцій змінюється, причому деякі методи мають більші частини, а деякі менші. Збільшення функцій може бути невеликим, як одна зміна екрана інтерфейсу користувача або новий параметр запиту.
Ітеративна розробка відбувається, коли групи функцій визначаються, проєктуються, створюються та тестуються разом у серії циклів, часто фіксованої тривалості. Ітерації можуть передбачати зміни функцій, розроблених на попередніх ітераціях, а також зміни обсягу проєкту. Кожна ітерація надає робоче програмне забезпечення, яке є зростаючою підмножиною загального набору функцій, поки не буде доставлено остаточне програмне забезпечення або розробку не буде припинено.
Приклади:
Раціональний уніфікований процес: кожна ітерація, як правило, є відносно довгою (наприклад, два-три місяці), а кроки функцій відповідно великі, наприклад дві або три групи пов’язаних функцій
Scrum: кожна ітерація має тенденцію бути відносно короткою (наприклад, години, дні або кілька тижнів), а кроки функцій відповідно невеликі, наприклад, кілька вдосконалень та/або дві-три нові функції
Kanban: реалізовано з ітераціями фіксованої довжини або без них, які можуть надавати або одне вдосконалення чи функцію після завершення, або можуть групувати функції разом для одночасного випуску
Спіраль: включає створення експериментальних приростів, деякі з яких можуть бути значно перероблені або навіть залишені в подальших розробках
Компоненти або системи, розроблені за допомогою цих методів, часто передбачають накладання та ітерацію рівнів тестування протягом розробки. В ідеалі кожна функція перевіряється на кількох тестових рівнях, коли вона просувається до доставки. У деяких випадках команди використовують безперервну доставку або безперервне розгортання, обидва з яких передбачають значну автоматизацію кількох рівнів тестування як частину їх конвеєрів доставки. Багато зусиль щодо розробки з використанням цих методів також включають концепцію самоорганізованих команд, які можуть змінити спосіб організації роботи з тестування, а також стосунки між тестувальниками та розробниками.
Ці методи формують зростаючу систему, яка може бути надана кінцевим користувачам на основі функції за функцією, на основі ітерації за ітерацією або більш традиційним способом основного випуску. Незалежно від того, чи випускаються доповнення програмного забезпечення для кінцевих користувачів, регресійне тестування стає все більш важливим із зростанням системи.
На відміну від послідовних моделей, ітераційні та інкрементні моделі можуть надати придатне для використання програмне забезпечення за тижні або навіть дні, але можуть запропонувати повний набір продуктів лише протягом місяців або навіть років.
Моделі SDLC в контексті (версія 3.1)
Моделі життєвого циклу розробки програмного забезпечення повинні бути обрані та адаптовані до контексту проєкту та характеристик продукту. Відповідна модель життєвого циклу розробки програмного забезпечення повинна бути обрана та адаптована на основі мети проєкту, типу продукту, що розробляється, бізнес-пріоритетів (наприклад, час виходу на ринок) і ідентифікованих ризиків продукту та проєкту. Наприклад, розробка та тестування незначної внутрішньої адміністративної системи має відрізнятися від розробки та тестування критично важливої для безпеки системи, такої як система керування гальмами автомобіля. Як інший приклад, у деяких випадках організаційні та культурні проблеми можуть перешкоджати спілкуванню між членами команди, що може перешкоджати ітераційному розвитку.
Залежно від контексту проєкту може виникнути необхідність об’єднати або реорганізувати рівні тестування та/або тестову діяльність. Наприклад, для інтеграції комерційного готового програмного продукту (COTS) у більшу систему покупець може виконати тестування сумісності на рівні тестування системної інтеграції (наприклад, інтеграція з інфраструктурою та іншими системами) та на рівень приймальної перевірки (функціональний і нефункціональний, разом із приймальним тестуванням користувача та робочим приймальним тестуванням).
Крім того, самі моделі життєвого циклу розробки програмного забезпечення можуть бути об’єднані. Наприклад, V-модель може використовуватися для розробки та тестування серверних систем та їх інтеграції, тоді як гнучка модель розробки може використовуватися для розробки та тестування зовнішнього інтерфейсу користувача (UI) та функціональності. Прототипування може використовуватися на ранніх стадіях проєкту з поетапною моделлю розробки, прийнятою після завершення експериментальної фази.
Системи Інтернету речей (IoT), які складаються з багатьох різних об’єктів, таких як пристрої, продукти та послуги, зазвичай застосовують окремі моделі життєвого циклу розробки програмного забезпечення для кожного об’єкта. Це становить особливий виклик для розробки версій системи Інтернету речей. Крім того, життєвий цикл розробки програмного забезпечення для таких об’єктів приділяє більшу увагу пізнішим фазам життєвого циклу розробки програмного забезпечення після їх введення в оперативне використання (наприклад, фази експлуатації, оновлення та виведення з експлуатації).
Причини, чому моделі розробки програмного забезпечення повинні бути адаптовані до контексту проєкту та характеристик продукту, можуть бути:
Різниця в ризиках продукту систем (складний або простий проєкт)
Багато бізнес-одиниць можуть бути частиною проєкту чи програми (поєднання послідовної та гнучкої розробки)
Короткий час доставки продукту на ринок (об’єднання рівнів тестування та/або інтеграція типів тестування в рівні тестування)
Тестування в контексті життєвого циклу розробки ПЗ (версія 4.0)
Модель життєвого циклу розробки програмного забезпечення (SDLC) — це абстрактне високорівневе представлення процесу розробки програмного забезпечення. Модель SDLC визначає, як різні фази розробки та типи дій, що виконуються в рамках цього процесу, співвідносяться один з одним, як логічно, так і хронологічно. Приклади моделей SDLC включають: моделі послідовної розробки (наприклад, модель водоспаду, V-модель), ітераційні моделі розробки (наприклад, спіральна модель, прототипування) та моделі поступової розробки (наприклад, уніфікований процес).
Деякі дії в рамках процесів розробки програмного забезпечення також можна описати більш детальними методами розробки програмного забезпечення та методами Agile. Приклади включають: розробку, керовану приймальним тестуванням (ATDD), розробку, керовану поведінкою (BDD), дизайн, керований доменом (DDD), екстремальне програмування (XP), розробка, керована функціями (FDD), Kanban, Lean IT, Scrum та розробка керована тестами (TDD).
Вплив життєвого циклу програмного забезпечення на тестування (версія 4.0)
Для успіху тестування має бути адаптовано до SDLC. Вибір SDLC впливає на:
Обсяг і час виконання тестових дій (наприклад, рівні та типи тестів)
Рівень деталізації тестової документації
Вибір тестових методик і тестового підходу
Ступінь автоматизації тестування
Роль і обов’язки тестувальника
У моделях послідовної розробки на початкових етапах тестувальники зазвичай беруть участь у перегляді вимог, аналізі тестів і дизайні тестів. Виконуваний код зазвичай створюється на пізніших етапах, тому зазвичай динамічне тестування не можна виконати на ранніх стадіях SDLC.
У деяких ітеративних і поетапних моделях розробки передбачається, що кожна ітерація забезпечує робочий прототип або приріст продукту. Це означає, що в кожній ітерації як статичне, так і динамічне тестування можуть виконуватися на всіх рівнях тестування. Часта доставка інкрементів вимагає швидкого зворотного зв’язку та ретельного регресійного тестування.
Гнучка розробка програмного забезпечення передбачає, що зміни можуть відбуватися протягом усього проєкту. Тому в гнучких проєктах перевагу надають спрощеній робочій документації продукту та розширеній автоматизації тестування для полегшення регресійного тестування. Крім того, більшість ручного тестування, як правило, виконується з використанням методів тестування, заснованих на досвіді, які не вимагають ретельного попереднього аналізу та розробки тестів.
SDLC та хороші тестові практики (версія 4.0)
Належні практики тестування, незалежно від обраної моделі SDLC, включають наступне:
Для кожної діяльності з розробки програмного забезпечення існує відповідна тестова діяльність, тому всі дії з розробки підлягають контролю якості
Різні рівні тестування мають конкретні та різні цілі тестування, що дозволяє тестуванню бути належним чином повним, уникаючи надмірності
Аналіз і прєктування тесту для даного рівня тестування починається під час відповідної фази розробки SDLC, щоб тестування могло відповідати принципу раннього тестування
Тестувальники беруть участь у перевірці робочих продуктів, щойно чернетки цієї документації доступні, щоб це раннє тестування та виявлення дефектів могли підтримувати стратегію зсуву вліво (shift-left approach)
Тестування як драйвер розробки ПЗ (версія 4.0)
TDD, ATDD і BDD є подібними підходами до розробки, де тести визначаються як засіб керування розробкою. Кожен із цих підходів реалізує принцип раннього тестування і дотримується підходу зсуву вліво, оскільки тести визначаються до написання коду. Вони підтримують ітераційну модель розробки. Ці підходи характеризуються наступним чином:
Розробка на основі тестування (TDD). Направляє кодування через тестові випадки (замість обширного про’ктування програмного забезпечення) (Бек 2003). Спочатку пишуться тести, потім пишеться код, щоб задовольнити тести, а потім тести та код переробляються.
Розробка на основі приймальних випробувань (ATDD). Виводить тести з критеріїв прийнятності як частину процесу про’ктування системи (Gärtner 2011). Тести пишуться до того, як частина програми розробляється для задоволення тестів
Розробка на основі поведінки (BDD). Виражає бажану поведінку програми за допомогою тестових випадків, написаних простою природною мовою, яку легко зрозуміти зацікавленим сторонам – зазвичай у форматі Given/When/Then. (Челімський 2010). Потім тестові випадки автоматично перетворюються на виконувані тести.
Для всіх вищевказаних підходів тести можуть зберігатися як автоматизовані тести, щоб гарантувати якість коду в майбутніх адаптаціях.
DevOps та тестування (версія 4.0)
DevOps — це організаційний підхід, спрямований на створення синергії шляхом спільної роботи розробки (включно з тестуванням) і операцій для досягнення набору спільних цілей. DevOps вимагає культурних змін в організації, щоб подолати розрив між розробкою (включно з тестуванням) і операціями, одночасно ставлячись до їхніх функцій рівноцінно. DevOps сприяє автономності команди, швидкому зворотному зв’язку, інтегрованим ланцюжкам інструментів і технічним практикам, таким як безперервна інтеграція (CI) і безперервна доставка (CD). Це дозволяє командам швидше створювати, тестувати та випускати високоякісний код через конвеєр доставки DevOps (Kim 2016).
З точки зору тестування, деякі з переваг DevOps:
Швидкий відгук про якість коду та те, чи зміни негативно впливають на наявний код
CI сприяє підходу зсуву вліво в тестуванні, заохочуючи розробників подавати високоякісний код, що супроводжується тестуванням компонентів і статичним аналізом
Сприяє автоматизованим процесам, таким як CI/CD, які полегшують створення стабільних тестових середовищ
Покращує погляд на нефункціональні характеристики якості (наприклад, продуктивність, надійність)
Автоматизація через конвеєр доставки зменшує потребу в повторному ручному тестуванні
Ризик при регресії зведений до мінімуму завдяки масштабу та діапазону автоматизованих регресійних тестів
DevOps не позбавлений ризиків і викликів, які включають:
Необхідно визначити та встановити конвеєр доставки DevOps
Необхідно запровадити та підтримувати інструменти CI/CD (Continuous Integration/ Continuous Development)
Автоматизація тестування потребує додаткових ресурсів, її може бути важко встановити та підтримувати
Незважаючи на те, що DevOps забезпечує високий рівень автоматизованого тестування, ручне тестування – особливо з точки зору користувача – все одно буде необхідним.
Підхід зсуву вліво (Shift-Left Approach, версія 4.0)
Принцип раннього тестування іноді називають зсувом вліво, оскільки це підхід, коли тестування виконується раніше в SDLC. Зсув вліво зазвичай означає, що тестування слід проводити раніше (наприклад, не чекати, поки код буде реалізовано або компоненти будуть інтегровані), але це не означає, що тестуванням пізніше в SDLC слід нехтувати.
Є кілька хороших практик, які ілюструють, як досягти «зсуву вліво» під час тестування, зокрема:
Перегляд специфікації з точки зору тестування. Ці перевірки специфікацій часто виявляють потенційні дефекти, такі як двозначність, неповнота та невідповідності
Написання тестів перед написанням коду та виконання коду в тестовій системі під час впровадження коду
Використання CI та навіть кращого CD, оскільки він надається зі швидким відгуком і автоматизованими тестами компонентів, які супроводжують вихідний код, коли він надсилається до репозиторія
Завершення статичного аналізу вихідного коду перед динамічним тестуванням або як частина автоматизованого процесу
Виконання нефункціонального тестування, починаючи з рівня тестування компонентів, де це можливо. Це форма зсуву вліво, оскільки ці нефункціональні типи тестів зазвичай виконуються пізніше в SDLC, коли доступна повна система та репрезентативне тестове середовище
Підхід зі зрушенням уліво може призвести до додаткового навчання, зусиль на ранніх етапах процесу, але очікується, що він заощадить зусилля пізніше в процесі.
Для підходу зрушення вліво важливо, щоб зацікавлені сторони були переконані та підтримали цю концепцію.
Ретроспективи та покращення процесу (версія 4.0)
Ретроспективи (також відомі як «постпроєктні зустрічі» та ретроспективи проєкту) часто проводяться в кінці проєкту або ітерації, на етапі випуску або можуть проводитися за потреби. Час і організація ретроспектив залежать від конкретної моделі SDLC. На цих зустрічах учасники (не лише тестувальники, а й, наприклад, розробники, архітектори, власники продуктів, бізнес-аналітики) обговорюють:
Що було успішним і що варто зберегти?
Що не вдалось і можна було б покращити?
Як запровадити вдосконалення та зберегти успіхи в майбутньому?
Серед типових переваг для тестування виділяють:
Підвищення результативності/ефективності тестування (наприклад, за допомогою впровадження пропозицій щодо вдосконалення процесу)
Підвищення якості програмного забезпечення для тестування (наприклад, шляхом спільного перегляду процесів тестування)
Згуртування команди та навчання (наприклад, у результаті можливості розв’язати проблему та запропонувати покращення)
Покращена якість тестової бази (наприклад, оскільки недоліки в обсязі та якості вимог можуть бути розглянуті та вирішені) Краща співпраця між розробкою та тестуванням (наприклад, оскільки взаємодія регулярно перевіряється та оптимізується)
ISTQB Certified Tester Foundation Level. Курс для початківців. Секція 2.1.
В цьому відео починаємо працювати з секцією 2.1. 00:01:11 Моделі життєвого циклу розробки програмного забезпечення (визначення) 00:02:08 Розробка і тестування програмного забезпечення 00:18:09 Моделі життєвого циклу розробки програмного забезпечення в контексті 00:27:18 Тестування в контексті Моделі життєвого циклу розробки програмного забезпечення 00:39:51 Життєвий цикл розробки програмного забезпечення і якісні тестові практики 00:43:07 Тестування як драйвер для Розробки програмного забезпечення 00:50:59 Девопс та тестування 01:00:22 Підхід “зсув-вліво” 01:07:00 Ретроспектива і покращення процесу
Перш ніж почати розгляд тестів. Варто зазначити кілька моментів, які можуть допомогти у виявленні правильної відповіді на тест.
Чим раніше буде знайдено помилку, тим менші наслідки це матиме для проєкту і тим легше таку помилку буде виправити.
І ще один момент. Чим раніше виявляється помилка чи дефект, тим дешевше їх виправити.
Якість ПЗ
Якість ПЗ – ступінь, в якій система, компонент або процес задовольняють потреби або очікування замовника або користувача.
Функціональність (Functionality) – визначається здатністю ПЗ вирішувати завдання, які відповідають зафіксованим і очікуваним потребам користувача, за заданих умов використання ПЗ. Тобто ця характеристика відповідає за те, що ПЗ працює справно і точно, функціонально сумісно, відповідає стандартам галузі та захищене від несанкціонованого доступу.
Надійність (Reliability) – здатність ПЗ виконувати необхідні завдання у зазначених умовах протягом заданого проміжку часу або вказаної кількості операцій. Атрибути даної характеристики – це завершеність і цілісність всієї системи, здатність самостійно і коректно відновлюватися після збоїв у роботі, відмовостійкість.
Зручність використання (Usability) – можливість легкого розуміння, вивчення, використання і привабливість ПЗ для користувача.
Ефективність (Efficiency) – здатність ПЗ забезпечувати необхідний рівень продуктивності згідно з виділеними ресурсами, часом та іншими зазначеними умовами.
Зручність супроводу (Maintainability) – легкість, з якою ПЗ може аналізуватися, тестуватися, змінюватися для виправлення дефектів, для реалізації нових вимог, для полегшення подальшого обслуговування та адаптуватися до наявного оточення.
Портативність (Portability) – характеризує ПЗ з точки зору легкості його перенесення з одного оточення (software/hardware) в інше.
Варто зазначити, що зараз є і діє серія стандартів ISO 25000, в якій міститься новий підхід до якості. Зокрема збільшення характеристик і виділення “підрівнів” чи додаткових характеристик якості. Тим не менше цей підхід вважається трохи ускладненим, тому для початківців часто дають саме попередню версію ISO 9126. Яка простіша для розуміння і вивчення якої полегшить процес ознайомлення з новою концепцією серії стандартів 25000.
Розбір тестових питань по першому розділу
ISTQB Certified Tester Foundation Level. Курс для початківців. Практика з тестами для 1 розділу
В цьому відео робиться спроба розібрати кілька десятків питань по першому розділу сілабусу ISTQB CTFL.
Всі питання з відео з правильними відповідями наводяться нижче.
Question 1
Which of the following is most important to promote and maintain good relationships between testers and developers?
Understanding what managers value about testing.
Explaining test results in a neutral fashion.
Identifying potential customer work-arounds for bugs.
Promoting better quality software at any cost.
Question 2
Which is not a testing principle
Early testing.
Pesticide paradox.
Exhaustive testing.
Defect clustering.
Question 3
According to the ISTQB Glossary, a risk relates to which of the following?
Negative consequences that could occur.
Negative consequences that will occur.
Negative feedback to the tester.
Negative consequences for the test object.
Question 4
According to the ISTQB Glossary, the word ‘bug’ is synonymous with which of the following words?
Defect
Mistake
Error
Incident
Question 5
A test team consistently find between 90% and 95% of the defects present in the system under test. While the test manager understands that this is a good defect-detection percentage for her test team and industry, senior management and executives remain disappointed in the test group, saying that the test team misses too many bugs. Given that the users are generally happy with the system and that the failures which have occurred have generally been low impact, which of the following testing principles is most likely to help the test manager explain to these managers and executives why some defects are likely to be missed?
Absence-of-errors fallacy
Exhaustive testing is impossible
Defect clustering
Pesticide paradox
Question 6
Deciding How much testing is enough should take into account: (i). Level of Risk including Technical and Business product and project risk. (ii.) Project constraints such as time and budget. (iii.) Size of Testing Team. (iv.) Size of the Development Team.
i,ii,iv are true and ii is false.
i,ii,iii are true and iv is false.
i,ii are true and iii,iv are false.
ii,iii,iv are true and i is false.
Question 7
Typically, exit criteria may consist of:
Defining the amount, level of detail structure, and templates for the test documentation.
Estimates of defect density or reliability measures.
Adequacy of the test approaches taken.
Discussions on disaster recovery.
Question 8
Detecting a defect at which of the following stage is most economical?
Build.
Deployment.
Testing.
Design.
Question 9
During which test activity could faults be found most cost effecftively?
Execution.
Design.
Check Exit criteria completion.
Planning.
Question 10
Ensuring that test design starts during the requirements definition phase is important to enable which of the following test objectives?
Finding defects through dynamic testing.
Preventing defects in the system.
Finishing the project on time.
Gaining confidence in the system.
Question 11
What factors should be considered to determine whether enough testing has been performed? I. The exit criteria. II. The budget. III. How big the test team is. IV. The product’s risk profile. V. How good the testing tools are. VI. Sufficient details of the system status to allow decisions
i and ii and iv and vi
i and ii and iii and vi
ii and iii and iv and v
i and ii and v and vi
Question 12
Evaluating testability of the requirements and system are a part of which phase?
Test Implementation and execution.
Test Analysis and Design.
Evaluating exit criteria and reporting.
Test Planning and control.
Question 13
Test Implementation and execution has which of the following major tasks? I. Developing and prioritizing test cases, creating test data, writing test procedures and optionally preparing the test harnesses and writing automated test scripts. II. Creating the test suite from the test cases for efficient test execution. III. Verifying that the test environment has been set up correctly. IV. Determining the exit criteria.
I,II are true and III, IV are false
I,IV,III are true and II is false
II,III,IV are true and I is false
I,II,III are true and IV is false
Question 14
Test planning has which of the following major tasks? I. Determining the scope and risks, and identifying the objectives of testing. II. Determining the test approach (techniques, test items, coverage, identifying and interfacing the teams involved in testing, testware). III. Reviewing the Test Basis (such as requirements, architecture, design, interface) IV. Determining the exit criteria.
Coverage of code, schedule, estimates of defect density.
The last executable statement within a component.
Cost overruns.
Question 16
Testing Process comprised of
Test Plan and Test Cases.
Test Log and Test Status.
Defect Tracking.
All of the above.
Question 17
Which of the following are valid test objectives? I. Finding defects. II. Gaining confidence about the level of quality and providing information. III. Preventing defects. IV. Debugging the code.
i, ii and iii
i, ii and iv
ii and iii
i and iv
Question 18
The goal of software testing is to
Validate that the system behaves as expected.
Let the developer know the defects injected by him.
Execute the program with the intent of finding errors.
Debug the system.
Question 19
Though activities in the Fundamental test process may overlap or occur concurrently, identify the logical sequential process. (i) Test Implementation and Execution (ii) Test Closure activities (iii) Evaluating exit criteria and reporting (iv) Test Planning and Control (v) Test Analysis and Design
v – i – iii – ii – iv
iv – v – iii – ii – i
iv – v – i – iii – ii
v – ii – iii – i – iv
Question 20
What is not the primary data given by the tester in test execution?
Number of test executed to date.
Number of test cases written for change request.
Total number of tests.
Number of tests executed successfully to date.
Question 21
What is the need for test planning?
to understand testing process.
to perform ad hoc testing.
to utilize a balance of testing techniques.
to collect metrics.
Question 22
Which of the following test organizations has the highest level of independence?
Independent testers within the development teams
Independent testers from the user community
Independent test specialists for specific test types, such as usability, performance or certification test specialists
Code tested by another developer from the development team
Question 23
What is the USUAL sequence for performing the following activities during the Fundamental Test Process? (a) Analyze the test basis documents. (b) Define the expected results. (c) Create the test execution schedule. (d) Establish the traceability of the test conditions
d, a, c, b
a, d, c
a, d, b, c
a, b, c, d
Question 24
What should be taken into account to determine when to stop testing? I Technical risk; II Business risk; III Project constraints; IV Product documentation
I, II, and IV are true; III is false
I and II are true. III and IV are false
I, II, and III are true, IV is false.
III is true, I, II, and IV are false
Question 25
When should you stop testing?
when the test completion criteria have been met.
when no faults have been found by the tests run.
when all planned tests have been run.
when time for testing has run out.
Question 26
When what is visible to end-users is an imperfection in a work product where it does not meet its requirements, this is called:
An error.
A defect.
A fault.
A mistake.
Question 27
Which activities form part of test planning? (i) Developing test cases. (ii) Defining the overall approach to testing. (iii) Assigning resources. (iv) Building the test environment. (v) Writing test conditions.
iv& v are true, i, ii & iii are false.
i, ii &iv are true, iii & v are false.
i, ii & iii are true iv& v are false.
ii & iii are true, i, iv& v are false.
Question 28
It is recommended to perform exhaustive tests for covering all combinations of inputs and preconditions
Yes, it’s strongly recommended.
No, risk analysis and priorities should be used to focus testing efforts
Yes, and it’s also necessary to include all the exit combinations
Only the expert testers can make exhaustive tests.
Question 29
Which of the following is a major task of test planning?
