Метою статичного аналізу є виявлення дефектів у вихідному коді програмного забезпечення та моделях програмного забезпечення.
Потік керування — це послідовність подій (шляхів) у виконанні через компонент або систему.
Потік даних — це абстрактне представлення послідовності та можливих змін стану об’єктів даних, де стан об’єкта є будь-яким із наступних: створення, використання або видалення.
Метрики коду
Під час виконання статичного аналізу коду обчислюється інформація про структурні атрибути коду, такі як:
Частота коментарів
Глибина вкладення
Цикломатичне число
Кількість рядків коду
Показники складності ідентифікують зони з високим ризиком і складність. Досвідчені програмісти знають, що 20% коду викличуть 80% проблем, а аналіз складності допомагає знайти ці важливі 20%.
Цінність статичного аналізу
Раннє виявлення дефектів до виконання тесту
Раннє попередження про підозрілі аспекти коду або дизайну шляхом обчислення показників.
Ідентифікація дефектів, які важко знайти під час динамічного тестування
Виявлення залежностей і невідповідностей у моделях програмного забезпечення, таких як посилання
Покращена підтримка коду та дизайну
Попередження дефектів, якщо робиться аналіз і висновки.
Типові дефекти
Типові дефекти, виявлені інструментами статичного аналізу:
Посилання на змінну з невизначеним значенням
Непослідовні інтерфейси між модулями та компонентами
Змінні, які не використовуються або оголошені неправильно
Недосяжний (мертвий) код
Відсутня та помилкова логіка (потенційно нескінченні цикли)
Надто складні конструкції
Порушення стандартів програмування
Вразливі місця безпеки
Порушення синтаксису коду та моделей програмного забезпечення
Статичні Інструменти
Інструменти статичного аналізу зазвичай використовуються розробниками (перевірка на попередньо визначені правила або стандарти програмування) до та під час тестування компонентів та інтеграції або під час реєстрації коду в інструментах керування конфігурацією, а також розробниками під час моделювання програмного забезпечення.
Інструменти статичного аналізу можуть створювати велику кількість попереджувальних повідомлень, якими потрібно добре керувати, щоб забезпечити найбільш ефективне використання інструменту. Компілятори можуть запропонувати певну підтримку для статичного аналізу, включаючи обчислення показників.
Розбір тестових питань по третьому розділу
В цьому відео робиться спроба розібрати кілька десятків питань по третьому розділу сілабусу ISTQB CTFL.
ISTQB Certified Tester Foundation Level. Курс для початківців. Розділ 3. Практика.
В цьому відео працюємо з тестами до розділу 3. 00:00:17 Статичний аналіз за допомогою інструментів 00:02:13 Метрики коду 00:05:03 Цінність статичного аналізу 00:06:44 Типові дефекти 00:09:50 Статичні інструменти 00:13:16 Робота з тестами
Всі питання з відео з правильними відповідями наводяться нижче.
Question 1
Which of the following artifacts can be examined by using review techniques?
Software code
Requirements specification
Test designs
All of the above
Question 2
Who is responsible for documenting all the issues, problems and open point that were identified during the review meeting
Moderator
Reviewers
Author
Scribe
Question 3
‘Entry criteria’ should address questions such as (I.) Are the necessary documentation, design and requirements information available that will allow testers to operate the system and judge correct behaviour. (II.) Is the test environment-lab, hardware, software and system administration support ready? (III.) Those conditions and situations that must prevail in the testing process to allow testing to continue effectively and efficiently. (IV.) Are the supporting utilities, accessories and prerequisites available in forms that testers can use?
II, III and IV.
I, II, III and IV
I, II and III
I, II and IV
Question 4
A program with high cyclomatic complexity is almost likely to be:
Difficult to write.
Difficult to test.
Small.
Large.
Question 5
An important benefit of code inspections is that they:
enable the code to be tested before the execution environment is ready.
can be performed by inexperienced staff.
can be performed by the person who wrote the code.
are cheap to perform.
Question 6
Could reviews or inspections be considered part of testing:
No, because they apply to development documentation.
No, because they do not apply to the test documentation.
Yes, because testing includes all non-constructive activities.
Yes, because both help detect faults and improve quality.
Question 7
In a review meeting a moderator is a person who
Takes telephone calls
Takes minutes of the meeting
Mediates between people
Writes the documents to be reviewed
Question 8
Peer Reviews are also called as:
Formal Review.
Walkthrough.
Technical Review.
Inspection.
Question 9
People who don’t participate in technical reviews:
Analysts.
Testers.
Management.
Developers.
Question 10
Static analysis is best described as:
the use of black box testing.
the analysis of program code.
the analysis of batch programs.
the reviewing of test plans.
Question 11
Static code analysis typically identifies all but one of the following problems. Which is it?
Too few comments
Faults in the requirements
Unreachable code
Undeclared variables
Question 12
Success Factors for a review include: I. Each Review does not have a predefined objective. II. Defects found are welcomed and expressed objectively. III. Management supports a good review process. IV. There is an emphasis on learning and process improvement.
II is correct.
II, III, IV are correct and I is incorrect.
III, I, IV is correct and II is incorrect.
I, III, IV, II is incorrect.
Question 13
The Kick Off phase of a formal review includes the following:
Explaining the objective.
Fixing defects found typically done by author.
Individual Meeting preparations.
Follow up.
Question 14
What can static analysis NOT find?
Whether the value stored in a variable is correct.
The use of a variable before it has been defined.
Array bound violations.
Unreachable (“dead”) code.
Question 15
What is the main difference between a walkthrough and an inspection?
A walkthrough is led by the author, while an inspection is led by a trained moderator.
An inspection has a trained leader, while a walk through has no leader.
An inspection is led by the authors, while a walk through is led by a trained moderator.
Authors are not present during inspections, while they are during walkthroughs.
Question 16
What is the main purpose of Informal review
Discuss, make decisions, solve technical problems
Inexpensive way to get some benefit
Find defects
Learning, gaining understanding, effect finding
Question 17
What statement about reviews is true?
Inspections are led by a trained moderator, whereas technical reviews are not necessarily.
In a walkthrough, the author does not attend.
Participants for a walkthrough always need to be thoroughly trained.
Technical reviews are led by a trained leader, inspections are not.
Question 18
What statement about static analysis is true?
Compiling is not a form of static analysis.
Static analysis finds all faults.
With static analysis, defects can be found that are difficult to find with dynamic testing.
When properly performed, static analysis makes functional testing redundant.
Question 19
Which expression best matches the following characteristics or review processes: 1. Led by author 2. Undocumented 3. No management participation 4. Led by a trained moderator or leader 5. Uses entry exit criteria
Which of the following are success factors for reviews? (I.) Clear objectives for each review. (II.) Checklists and/or roles are used to increase effectiveness of defect identification. (III.) There is an emphasis on process improvement. (IV.) People issues and psychological aspects are not reviewed.
II, III and IV
I, II and III
IV
I and III
Question 22
Which statement about the function of a static analysis tool is true?
Gives information about what code has and has not been exercised.
Can detect memory leaks.
Gives quality information about the code without executing it.
Перегляди варіюються від неофіційних до офіційних. Неофіційні перегляди характеризуються недотриманням визначеного процесу та відсутністю офіційно задокументованих результатів. Для формальних перевірок характерна участь команди, задокументовані результати перевірки та задокументовані процедури проведення перевірки. Формальність процесу перевірки пов’язана з такими факторами, як модель життєвого циклу розробки програмного забезпечення, зрілість процесу розробки, складність робочого продукту, який перевіряється, будь-які законодавчі чи нормативні вимоги та/або необхідність аудиторського сліду.
Спрямованість перевірки залежить від узгоджених цілей перевірки (наприклад, виявлення дефектів, отримання розуміння, навчання учасників, таких як тестувальники та нові члени команди, або обговорення та прийняття рішень шляхом консенсусу).
Стандарт ISO (ISO/IEC 20246) містить більш поглиблений опис процесу перевірки робочих продуктів, включаючи ролі та методи перевірки.
Переваги раннього зворотнього зв’язку (версія 4.0)
Ранні та часті зворотні зв’язки дозволяють завчасно повідомити про потенційні проблеми з якістю. Якщо під час SDLC буде мало участі зацікавлених сторін, продукт, що розробляється, може не відповідати початковому або поточному баченню зацікавлених сторін. Нездатність виконати те, що хоче зацікавлена сторона, може призвести до дорогої переробки, зриву термінів, звинувачень і навіть може призвести до повного провалу проєкту.
Частий зворотний зв’язок із зацікавленими сторонами в рамках SDLC може запобігти непорозумінням щодо вимог і гарантувати, що зміни вимог будуть зрозумілі та впроваджені раніше. Це допомагає команді розробників краще зрозуміти, що вони створюють. Це дозволяє їм зосередитися на тих функціях, які приносять найбільшу цінність зацікавленим сторонам і мають найбільш позитивний вплив на виявлені ризики.
Процес перегляду робочих документів (версія 3.1)
Процес перегляду включає такі основні дії:
Планування
Визначення обсягу, який включає мету перевірки, які документи або частини документів перевіряти, а також якісні характеристики, що підлягають оцінці
Оцінка зусиль і часових рамок
Визначення характеристик перевірки, таких як тип перевірки з ролями, видами діяльності та контрольними списками
Вибір людей для участі в огляді та розподіл ролей
Визначення критеріїв входу та виходу для більш формальних типів огляду (наприклад, перевірки)
Перевірка відповідності критеріям входу (для більш формальних типів переглядів)
Початок перегляду
Розповсюдження робочого продукту (фізично чи за допомогою електронних засобів) та інших матеріалів, таких як форми журналу випусків, контрольні списки та відповідні робочі продукти
Пояснення учасникам обсягу, цілей, процесу, ролей і результатів роботи
Відповіді на будь-які запитання щодо огляду, які можуть виникнути в учасників
Індивідуальний огляд (тобто індивідуальна підготовка)
Перегляд всього або частини робочого продукту
Позначення можливих недоліків, рекомендації та запитання
Комунікація проблем та аналіз
Повідомлення про виявлені потенційні дефекти (наприклад, на оглядовій зустрічі)
Аналіз потенційних дефектів, визначення приналежності та статусу
Оцінка та документування характеристик якості
Оцінка результатів перевірки за критеріями виходу для прийняття рішення про перевірку (відхилити; необхідні значні зміни; прийняти, можливо, з незначними змінами)
Виправлення та звітність
Створення звітів про дефекти для тих знахідок, які потребують змін у робочому продукті
Виправлення дефектів, виявлених (як правило, виконується автором) у перевіреному робочому продукті
Повідомлення про дефекти відповідній особі або групі (якщо виявлені в робочому продукті, пов’язаному з перевіреним робочим продуктом)
Запис оновленого статусу дефектів (у офіційних переглядах), потенційно включаючи згоду автора коментаря
Збір показників (для більш формальних типів перегляду)
Перевірка відповідності критеріям виходу (для більш формальних типів перегляду)
Прийняття робочого продукту після досягнення критеріїв виходу
Процес перегляду робочих документів (версія 4.0)
Стандарт ISO/IEC 20246 визначає загальний процес перегляду, який забезпечує структуровану, але гнучку структуру, на основі якої конкретний процес перевірки може бути адаптований до конкретної ситуації. Якщо необхідний огляд є більш формальним, тоді буде потрібно більше завдань, описаних для різних видів діяльності.
Розмір багатьох робочих продуктів робить їх занадто великими, щоб охопити їх одним оглядом. Процес перегляду можна запустити кілька разів, щоб завершити перевірку всього робочого продукту.
Дії в процесі перегляду:
Планування. На етапі планування обсяг перегляду, який включає мету, робочий продукт, який потрібно перевірити, якісні характеристики, які потрібно оцінити, області, на яких слід зосередитися, критерії виходу, супровідну інформацію, таку як стандарти, зусилля та часові рамки для перевірки, визначаються.
Початок перегляду. Під час ініціювання перегляду мета полягає в тому, щоб переконатися, що всі учасники готові розпочати перевірку. Це включає переконання, що кожен учасник має доступ до робочого продукту, який перевіряється, розуміє свою роль і обов’язки та отримує все необхідне для виконання перегляду.
Індивідуальний огляд. Кожен рецензент проводить індивідуальний перегляд, щоб оцінити якість робочого продукту, що перевіряється, і виявити аномалії, рекомендації та запитання, застосовуючи один або кілька методів перевірки (наприклад, перевірка на основі контрольного списку, перевірка на основі сценарію). Стандарт ISO/IEC 20246 надає більше інформації про різні методи переглядів. Рецензенти реєструють усі виявлені аномалії, рекомендації та запитання.
Комунікація та аналіз. Оскільки аномалії, виявлені під час огляду, не обов’язково є дефектами, усі ці аномалії необхідно проаналізувати та обговорити. Для кожної аномалії необхідно прийняти рішення щодо її статусу, приналежності та необхідних дій. Зазвичай це робиться на оглядовій зустрічі, під час якої учасники також вирішують, який рівень якості перевіреного робочого продукту та які подальші дії необхідні. Для завершення дій може знадобитися повторний огляд.
Виправлення та звітність. Для кожного дефекту слід створити звіт про дефект, щоб можна було вжити подальших заходів щодо усунення. Після досягнення критеріїв виходу робочий продукт може бути прийнятий. Про результати розгляду повідомляється.
Ролі та відповідальність у процесі перегляду (версія 3.1)
Типовий перегляд включатиме такі ролі:
Автор
Створює робочий продукт, що перевіряється
Виправляє дефекти робочого продукту, що перевіряється (при необхідності)
Менеджмент
Відповідає за планування огляду
Приймає рішення про виконання переглядів
Призначає персонал, бюджет і час
Контролює поточну ефективність
Виконує контрольні рішення у разі неадекватних результатів
Фасилітатор (часто його називають модератором)
Забезпечує ефективне проведення оглядових нарад (якщо вони проводяться)
Посередництво, якщо необхідно, між різними точками зору
Часто є особою, від якої залежить успіх перевірки
Ведучий огляду
Бере на себе загальну відповідальність за перегляд
Вирішує, хто буде залучений, і організовує час і місце проведення
Рецензенти
Можуть бути експертами в галузі, особами, які працюють над проєктом, зацікавленими сторонами, які зацікавлені в робочому продукті, та/або особами з певним технічним чи бізнес-досвідом
Визначати потенційні дефекти в робочому продукті, що перевіряється
Може представляти різні точки зору (наприклад, тестувальник, розробник, користувач, оператор, бізнес-аналітик, експерт з зручності використання тощо)
Секретар (Scribe дослівно шкрябальник)
Зіставляє потенційні дефекти, виявлені під час індивідуального перегляду
Записує нові потенційні дефекти, відкриті питання та рішення наради з перегляду (якщо вона проводиться)
У деяких типах рецензування одна особа може виконувати кілька ролей, і дії, пов’язані з кожною роллю, також можуть відрізнятися залежно від типу рецензування. Крім того, з появою інструментів для підтримки процесу перегляду, особливо реєстрації дефектів, відкритих питань і рішень, часто відпадає потреба в секретарі.
Більш детальна інформація в стандарті ISO (ISO/IEC 20246).
Ролі та відповідальність у процесі перегляду (версія 4.0)
Огляди включають різні зацікавлені сторони, які можуть виконувати кілька ролей. Основними ролями та їх обов’язками є:
Менеджер – вирішує, що потрібно перевірити, і надає ресурси, наприклад персонал і час для перевірки
Автор – створює та виправляє робочий продукт, що перевіряється
Модератор (також відомий як фасилітатор) – забезпечує ефективне проведення оглядових зустрічей, включаючи посередництво, управління часом і безпечне середовище для огляду, в якому кожен може вільно говорити
Керівник перегляду – бере на себе загальну відповідальність за перегляд, наприклад, вирішує, хто буде залучений, а також організовує час і місце рецензування
Секретар (Scribe дослівно шкрябальник) – зіставляє аномалії від рецензентів і записує інформацію про рецензування, таку як рішення та нові аномалії, виявлені під час наради з перегляду
Рецензент – проводить перегляду робочого продукту. Рецензентом може бути хтось, хто працює над проєктом, експерт із предметної теми або будь-яка інша зацікавлена особа.
Більш детальна інформація в стандарті ISO/IEC 20246.
Типи переглядів (версі 3.1)
Хоча перегляди можна використовувати для різних цілей, одна з головних цілей – виявити дефекти. Усі типи перевірки можуть допомогти у виявленні дефектів, і вибраний тип перевірки має ґрунтуватися на потребах проєкту, наявних ресурсах, типі продукту та ризиках, бізнес-сфері та культурі компанії, серед інших критеріїв вибору.
Один робочий продукт може бути предметом кількох типів огляду. Якщо використовується більше ніж один тип перегляду, порядок може відрізнятися. Наприклад, перед технічною перевіркою можна провести неформальну перевірку, щоб переконатися, що робочий продукт готовий до технічної перевірки.
Типи перевірок можуть проводитися як експертні перевірки, тобто проводитися колегами, кваліфікованими для виконання тієї ж роботи.
Типи дефектів, виявлених під час огляду, відрізняються, особливо залежно від робочого продукту, який перевіряється. Перегляди можна класифікувати за різними ознаками. Наведемо чотири найпоширеніші типи відгуків і пов’язані з ними атрибути.
Неофіційний огляд (наприклад, «дружня» перевірка, парний перегляд)
Основне призначення: виявлення потенційних дефектів
Можливі додаткові цілі: генерація нових ідей або рішень, швидке вирішення незначних проблем
Не базується на офіційному (задокументованому) процесі
Може не включати оглядову зустріч
Може виконуватись колегою автора (buddy check) або кількома людьми
Результати можуть бути задокументовані
Корисність залежить від рецензентів
Використання контрольних списків необов’язкове
Дуже часто використовується в гнучкій розробці
Проходження
Основні цілі: виявлення дефектів, вдосконалення програмного продукту, розгляд альтернативних реалізацій, оцінка відповідності стандартам і специфікаціям
Можливі додаткові цілі: обмін ідеями щодо технік чи варіацій стилю, навчання учасників, досягнення консенсусу
Індивідуальна підготовка перед оглядовою зустріччю необов’язкова
Оглядову зустріч зазвичай проводить автор продукту роботи
Секретар обов’язковий
Використання контрольних списків необов’язкове
Може мати форму сценаріїв, пробних прогонів або моделювання
Створюються журнали потенційних дефектів і звіти про перевірку
На практиці може варіюватися від досить неформального до дуже офіційного
Технічний огляд
Основні цілі: досягнення консенсусу, виявлення потенційних дефектів
Можливі подальші цілі: оцінка якості та зміцнення довіри до робочого продукту, генерація нових ідей, мотивація та надання можливості авторам покращувати майбутні робочі продукти, розгляд альтернативних реалізацій
Рецензенти мають бути технічними колегами автора та технічними експертами в тій самій чи інших дисциплінах
Необхідна індивідуальна підготовка перед оглядовою зустріччю
Зустріч для перегляду є необов’язковою, в ідеалі її проводить навчений фасилітатор (зазвичай не автор)
Секретар обов’язковий, в ідеалі не автор
Використання контрольних списків необов’язкове
Створюються журнали потенційних дефектів і звіти про перевірку
Інспекція
Основні цілі: виявлення потенційних дефектів, оцінка якості та формування довіри до робочого продукту, запобігання майбутнім подібним дефектам шляхом навчання автора та аналізу першопричини
Можливі подальші цілі: мотивація та надання можливості авторам покращувати майбутні робочі продукти та процес розробки програмного забезпечення, досягнення консенсусу
Дотримується визначеного процесу з офіційно задокументованими результатами на основі правил і контрольних списків
Використовує чітко визначені ролі та може включати спеціального читача (який читає продукт роботи вголос, часто перефразовуючи, тобто описуючи його своїми словами, під час оглядової зустрічі)
Необхідна індивідуальна підготовка перед оглядовою зустріччю
Рецензенти є або колегами автора, або експертами в інших дисциплінах, які стосуються продукту роботи
Використовуються визначені критерії входу та виходу
Секретар обов’язковий
Оглядову зустріч проводить навчений фасилітатор (не автор)
Автор не може виступати в ролі керівника огляду, читача чи писаря
Створюються журнали потенційних дефектів і звіт про перевірку
Показники збираються та використовуються для вдосконалення всього процесу розробки програмного забезпечення, включаючи процес перевірки
Типи переглядів (версі 4.0)
Існує багато типів оглядів, починаючи від неофіційних до офіційних. Необхідний рівень формальності залежить від таких факторів, як дотримання стандарту SDLC, зрілість процесу розробки, критичність і складність робочого продукту, що перевіряється, законодавчі чи нормативні вимоги та потреба в журналі аудиту. Той самий робочий продукт можна перевірити за допомогою різних типів перевірки, наприклад, спочатку неофіційної, а потім більш формальної.
Вибір правильного типу рецензування є ключовим для досягнення необхідних цілей рецензування. Вибір ґрунтується не лише на цілях, але й на таких факторах, як потреби проєкту, наявні ресурси, тип робочого продукту та ризики, сфера діяльності та корпоративна культура.
Кілька поширених типів переглядів:
Неформальний огляд. Неофіційні перегляди не дотримуються визначеного процесу та не вимагають офіційно задокументованих результатів. Головне завдання – виявлення аномалій.
Проходження. Покрокове керівництво, яке очолює автор, може служити багатьом цілям, таким як оцінка якості та формування довіри до робочого продукту, навчання рецензентів, досягнення консенсусу, генерування нових ідей, мотивація та надання можливості авторам вдосконалюватися та виявляти аномалії. Рецензенти можуть виконати індивідуальний огляд перед проходженням, але це не обов’язково.
Технічний огляд. Технічний огляд виконується кваліфікованими рецензентами під керівництвом модератора. Цілі технічної перевірки полягають у досягненні консенсусу та ухваленні рішень щодо технічної проблеми, а також у виявленні аномалій, оцінці якості та зміцненні довіри до робочого продукту, створенні нових ідей, а також мотивації та можливості авторам вдосконалюватися.
Інспекція. Оскільки інспекції є найбільш формальним типом перевірки, вони дотримуються повного загального процесу. Основна мета – виявити максимальну кількість аномалій. Інші цілі полягають у тому, щоб оцінити якість, зміцнити довіру до продукту роботи, а також мотивувати та дозволити авторам вдосконалюватися. Показники збираються та використовуються для вдосконалення SDLC, включаючи процес перевірки. У ревізіях автор не може виступати в ролі рецензента чи писаря.
Застосування технік перегляду (версія 3.1)
Існує ряд методів переглядів, які можна застосувати під час індивідуальної перегляду (тобто індивідуальної підготовки) для виявлення дефектів. Ці методи можна використовувати в описаних вище типах перевірок. Ефективність методів може відрізнятися залежно від типу огляду, який використовується. Нижче наведено приклади різних методів індивідуального рецензування для різних типів переглядів.
Ad hoc
Під час спеціального перегляду рецензентам надається мало або взагалі не надається вказівок щодо того, як слід виконувати це завдання. Рецензенти часто читають робочий продукт послідовно, виявляючи та документуючи проблеми, коли вони з ними стикаються. Спеціальне рецензування – це широко використовувана техніка, яка потребує невеликої підготовки. Ця техніка сильно залежить від навичок рецензента та може призвести до багатьох повторюваних проблем, про які повідомляють різні рецензенти.
На основі контрольного списку
Огляд на основі контрольного списку – це систематичний метод, за допомогою якого рецензенти виявляють проблеми на основі контрольних списків, які розповсюджуються на початку перевірки (наприклад, фасилітатором). Контрольний список перевірки складається з набору запитань, заснованих на потенційних дефектах, які можуть бути отримані з досвіду. Контрольні списки мають бути специфічними для типу робочого продукту, що перевіряється, і їх слід підтримувати регулярно, щоб охоплювати типи проблем, пропущені під час попередніх перевірок. Основна перевага методу, заснованого на контрольному списку, полягає в систематичному охопленні типових дефектів. Слід подбати про те, щоб не просто слідувати контрольному списку під час індивідуального перегляду, а й шукати дефекти поза контрольним списком.
Сценарії та пробні прогони
Під час перегляду на основі сценарію рецензентам надаються структуровані вказівки щодо того, як прочитати робочий продукт. Перевірка на основі сценаріїв підтримує рецензентів у виконанні «пробних прогонів» робочого продукту на основі очікуваного використання робочого продукту (якщо робочий продукт задокументовано у відповідному форматі, наприклад варіанти використання). Ці сценарії надають рецензентам кращі вказівки щодо визначення конкретних типів дефектів, ніж прості записи контрольного списку. Як і у випадку перевірки на основі контрольного списку, щоб не пропустити інші типи дефектів (наприклад, відсутні функції), рецензенти не повинні бути обмежені задокументованими сценаріями.
На основі перспективи
У перспективному читанні, подібному до рольового рецензування, рецензенти розглядають різні точки зору зацікавлених сторін під час індивідуального рецензування. Типові точки зору зацікавлених сторін включають кінцевого користувача, маркетолога, дизайнера, тестувальника або оператора. Використання різних точок зору зацікавлених сторін веде до більшої глибини індивідуального рецензування з меншим дублюванням проблем між рецензентами.
Крім того, читання, засноване на перспективі, також вимагає від рецензентів спроби використати робочий продукт, який перевіряється, для створення продукту, який вони б витягли з нього. Наприклад, тестувальник спробував би згенерувати проекти приймальних випробувань, якщо зчитує специфікацію вимог на основі перспективи, щоб перевірити, чи включена вся необхідна інформація. Крім того, при читанні в перспективі очікується використання контрольних списків.
Емпіричні дослідження показали, що читання на основі перспективи є найефективнішою загальною технікою перегляду вимог і технічних робочих продуктів. Ключовим фактором успіху є включення та належне зважування точок зору різних зацікавлених сторін на основі ризиків.
Рольовий
Огляд на основі ролей — це техніка, за якої рецензенти оцінюють робочий продукт з точки зору окремих ролей зацікавлених сторін. Типові ролі включають конкретні типи кінцевих користувачів (досвідчені, недосвідчені, старші, діти тощо), а також конкретні ролі в організації (адміністратор користувача, системний адміністратор, тестувальник продуктивності тощо). Застосовуються ті самі принципи, що й у читанні в перспективі, оскільки ролі подібні.
Фактори успіху переглядів (версія 3.1)
Для успішного огляду необхідно розглянути відповідний тип огляду та використані методи. Крім того, існує низка інших факторів, які впливатимуть на результат перегляду.
Організаційні фактори успіху для оглядів включають:
Кожний перегляд має чіткі цілі, визначені під час планування перегляду та використані як вимірні критерії виходу
Застосовуються типи огляду, які підходять для досягнення цілей і відповідають типу та рівню робочих продуктів програмного забезпечення та учасників
Будь-які використовувані методи перегляду, такі як перевірка на основі контрольного списку або на основі ролей, підходять для ефективного виявлення дефектів у робочому продукті, який перевіряється
Будь-які використовувані контрольні списки стосуються основних ризиків і є актуальними
Великі документи пишуться та переглядаються невеликими частинами, щоб контролювати якість шляхом надання авторам ранніх і частих відгуків про недоліки
Учасники мають достатньо часу для підготовки
Огляди плануються з належним повідомленням
Керівництво підтримує процес перегляду (наприклад, шляхом включення достатнього часу для діяльності з перегляду в графіки проєкту)
Огляди інтегровані в політику якості та/або тестування компанії.
Пов’язані з людьми фактори успіху відгуків включають:
Для досягнення цілей перегляду залучаються потрібні люди, наприклад, люди з різними навичками або поглядами
Тестувальники вважаються цінними рецензентами, які роблять внесок у рецензування та дізнаються про робочий продукт, що дає їм змогу готувати більш ефективні тести та готувати ці тести раніше
Учасники приділяють достатньо часу та уваги до деталей
Огляди проводяться невеликими частинами, щоб рецензенти не втрачали концентрації під час індивідуального огляду та/або зустрічі з огляду (якщо вона проводиться)
Виявлені дефекти визнаються, оцінюються та розглядаються об’єктивно
Зустріч добре організована, щоб учасники вважали її цінним використанням свого часу
Огляд проводиться в атмосфері довіри; результат не використовуватиметься для оцінки учасників
Учасники уникають мови тіла та поведінки, які можуть вказувати на нудьгу, роздратування або ворожість до інших учасників
Забезпечується адекватне навчання, особливо для більш формальних видів перевірок, таких як перевірки
Пропагується культура навчання та вдосконалення процесу
Фактори успіху переглядів (версія 4.0)
Є кілька факторів, які визначають успіх оглядів, зокрема:
Визначення чітких цілей і вимірних критеріїв виходу. Оцінка учасників ніколи не повинна бути об’єктивною
Вибір відповідного типу перевірки для досягнення поставлених цілей і відповідно до типу робочого продукту, учасників перевірки, потреб проєкту та контексту
Проведення оглядів невеликими частинами, щоб рецензенти не втрачали концентрацію під час окремого огляду та/або зустрічі з огляду (якщо вона проводиться)
Надання відгуків зацікавленим сторонам і авторам від рецензій, щоб вони могли покращити продукт і свою діяльність
Надання достатнього часу учасникам для підготовки до перегляду
Підтримка процесу перегляду з боку керівництва
Зробити огляди частиною культури організації, щоб сприяти навчанню та вдосконаленню процесу
Забезпечення відповідного навчання для всіх учасників, щоб вони знали, як виконувати свою роль
Спрощення зустрічей
ISTQB Certified Tester Foundation Level. Курс для початківців. Секція 3.2.
В цьому відео починаємо працювати з секцією 3.2. 00:00:54 Процес перегляду/перевірки (Review process) 00:07:11 Процес перегляду/перевірки робочих продуктів 00:29:18 Ролі і відповідальсть при формальному перегляді 00:41:16 Типи переглядів/перевірок 01:05:30 Застосування технік переглядів/перевірок 01:21:52 Фактори успіху для перегляду/перевірки
На відміну від динамічного тестування, яке вимагає виконання програмного забезпечення, що тестується, статичне тестування спирається на перевірку робочих продуктів вручну (тобто перегляди) або керовану інструментами оцінку коду чи інших робочих продуктів (тобто статичний аналіз). Обидва типи статичного тестування оцінюють код або інший робочий продукт, що тестується, без фактичного виконання коду або робочого продукту, що тестується.
Статичний аналіз важливий для сейфті-крітікал (критично важливих безпекових) комп’ютерних систем (наприклад, авіаційного, медичного або ядерного програмного забезпечення), але статичний аналіз також став важливим і поширеним в інших середовищах. Наприклад, статичний аналіз є важливою частиною тестування безпеки. Статичний аналіз також часто включається в автоматизовані інструменти створення та розповсюдження програмного забезпечення, наприклад, у гнучкій розробці, безперервній доставці та безперервному розгортанні.
Основи статичного тестування (версія 4.0)
На відміну від динамічного тестування, у статичному тестуванні програмне забезпечення, що тестується, не потрібно виконувати. Код, специфікація процесу, специфікація архітектури системи або інші робочі продукти оцінюються шляхом перевірки вручну (наприклад, переглядів) або за допомогою інструменту (наприклад, статичного аналізу). Цілі тестування включають покращення якості, виявлення дефектів і оцінку таких характеристик, як читабельність, повнота, правильність, можливість тестування та послідовність. Статичне тестування можна застосовувати як для перевірки, так і для валідації.
Тестувальники, представники бізнесу та розробники працюють разом під час зіставлення прикладів, спільного написання історій користувачів і сеансів уточнення резервів, щоб переконатися, що історії користувачів і пов’язані з ними робочі продукти відповідають визначеним критеріям, наприклад, визначенню Ready. Щоб переконатися, що історії користувачів повні та зрозумілі, а також включають критерії прийнятності, які можна перевірити, можна застосувати методи перевірки. Ставлячи правильні запитання, тестувальники досліджують, оскаржують і допомагають покращити запропоновані історії користувачів.
Статичний аналіз може виявити проблеми до динамічного тестування, хоча часто вимагає менше зусиль, оскільки тестові приклади не потрібні, і зазвичай використовуються інструменти. Статичний аналіз часто включений у фреймворки CI (continuous integration). Хоча в основному використовується для виявлення конкретних дефектів коду, статичний аналіз також використовується для оцінки зручності супроводу та безпеки. Іншими прикладами інструментів статичного аналізу є засоби перевірки орфографії та засоби читабельності.
Робочі продукти, які можуть бути перевірені за допомогою статичного тестування (версія 3.1)
Майже будь-який робочий продукт можна перевірити за допомогою статичного тестування (переглядів та/або статичного аналізу), наприклад:
Специфікації, включаючи бізнес-вимоги, функціональні вимоги та вимоги безпеки
Епіки, історії користувачів і критерії прийняття
Специфікації архітектури та дизайну
Код
Програмне забезпечення для тестування, включаючи плани тестування, тестові кейси, процедури тестування та сценарії автоматизованого тестування
Посібники користувача
Веб-сторінки
Контракти, плани проєктів, графіки та бюджетне планування
Налаштування конфігурації та налаштування інфраструктури
Моделі, такі як діаграми діяльності, які можна використовувати для тестування на основі моделі
Перегляди можна застосовувати до будь-якого робочого продукту, який учасники можуть читати та розуміти. Статичний аналіз можна ефективно застосовувати до будь-якого робочого продукту з формальною структурою (як правило, кодом або моделями), для якого існує відповідний інструмент статичного аналізу. Статичний аналіз можна навіть застосувати за допомогою інструментів, які оцінюють робочі продукти, написані природною мовою, такі як вимоги (наприклад, перевірка орфографії, граматики та читабельності).
Робочі продукти, які можуть бути перевірені за допомогою статичного тестування (версія 4.0)
Практично будь-який робочий продукт можна перевірити за допомогою статичного тестування. Приклади включають документи специфікації вимог, вихідний код, плани тестування, тестові випадки, елементи невиконаних продуктів, статути тестування, проєктну документацію, контракти та моделі.
Предметом рецензії може бути будь-який продукт роботи, який можна прочитати і зрозуміти. Однак для статичного аналізу робочим продуктам потрібна структура, за якою їх можна перевірити (наприклад, моделі, код або текст із формальним синтаксисом).
Робочі продукти, які не підходять для статичного тестування, включають ті, які важко інтерпретувати людям і які не слід аналізувати інструментами (наприклад, виконуваний код третьої сторони через юридичні причини).
Переваги статичного тестування (версія 3.1)
Методи статичного тестування дають ряд переваг. При застосуванні на ранніх стадіях життєвого циклу розробки програмного забезпечення статичне тестування дозволяє завчасно виявити дефекти до виконання динамічного тестування (наприклад, під час перегляду вимог або специфікацій дизайну, уточнення невиконаних завдань тощо). Дефекти, виявлені на ранній стадії, часто набагато дешевше усунути, ніж дефекти, виявлені пізніше в життєвому циклі, особливо порівняно з дефектами, виявленими після розгортання програмного забезпечення та його активного використання. Використання методів статичного тестування для пошуку дефектів і подальшого негайного усунення цих дефектів майже завжди набагато дешевше для організації, ніж використання динамічного тестування для пошуку дефектів в об’єкті тестування та їх подальшого усунення, особливо якщо враховувати додаткові витрати, пов’язані з оновленням інших робочих продуктів і проведення підтверджувального та регресійного тестування.
Додаткові переваги статичного тестування можуть включати:
Більш ефективне виявлення та виправлення дефектів до виконання динамічного тесту
Виявлення дефектів, які нелегко виявити динамічним тестуванням
Запобігання дефектам у дизайні чи кодуванні шляхом виявлення невідповідностей, двозначностей, протиріч, упущень, неточностей і надмірностей у вимогах
Підвищення продуктивності розробки (наприклад, за рахунок покращеного дизайну, більш зручного обслуговування коду)
Зменшення витрат і часу розробки
Зменшення вартості та часу тестування
Зменшення загальної вартості якості протягом усього терміну служби програмного забезпечення завдяки меншій кількості збоїв у подальшому життєвому циклі або після введення в експлуатацію
Покращення комунікації між членами команди під час участі в переглядах
Цінність статичного тестування (версія 4.0)
Статичне тестування може виявити дефекти на самих ранніх фазах SDLC, дотримуючись принципу раннього тестування. Воно також може ідентифікувати дефекти, які неможливо виявити за допомогою динамічного тестування (наприклад, недоступний код, шаблони проєктування, які не реалізовані належним чином, дефекти в невиконуваних робочих продуктах).
Статичне тестування дає можливість оцінити якість робочих продуктів і створити довіру до них. Перевіряючи задокументовані вимоги, зацікавлені сторони також можуть переконатися, що ці вимоги описують їхні фактичні потреби. Оскільки статичне тестування можна виконати на ранній стадії SDLC, можна досягти спільного розуміння між залученими зацікавленими сторонами. Також буде покращено спілкування між залученими зацікавленими сторонами. З цієї причини рекомендується залучати до статичного тестування широкий спектр зацікавлених сторін.
Незважаючи на те, що впровадження перевірки може бути дорогим, загальні витрати на проєкт зазвичай набагато нижчі, ніж у випадку, коли перевірки не виконуються, оскільки потрібно витрачати менше часу та зусиль на виправлення дефектів у подальшому проєкті.
Відмінності між статичним і динамічним тестуванням (версія 3.1)
Статичне тестування та динамічне тестування можуть мати однакові цілі, наприклад, забезпечити оцінку якості робочих продуктів і виявити дефекти якомога раніше. Статичні та динамічні тести доповнюють одне одного, виявляючи різні типи дефектів.
Однією з головних відмінностей є те, що статичне тестування виявляє дефекти в робочих продуктах безпосередньо, а не визначає збої, викликані дефектами під час запуску програмного забезпечення. Дефект може існувати в робочому продукті протягом дуже тривалого часу, не викликаючи збою. Шлях, де знаходиться дефект, може рідко проходити або бути важкодоступним, тому буде непросто побудувати та виконати динамічний тест, який його виявить. Статичне тестування може виявити дефект із набагато меншими зусиллями.
Інша відмінність полягає в тому, що статичне тестування можна використовувати для покращення узгодженості та внутрішньої якості робочих продуктів, тоді як динамічне тестування зазвичай зосереджується на зовнішніх видимих поведінках.
У порівнянні з динамічним тестуванням типові дефекти, які легше та дешевше знайти та виправити за допомогою статичного тестування, включають:
Дефекти вимог (наприклад, невідповідності, двозначності, протиріччя, упущення, неточності та надмірності)
Дефекти дизайну (наприклад, неефективні алгоритми або структури бази даних)
Дефекти кодування (наприклад, змінні з невизначеними значеннями, змінні, які оголошені, але ніколи не використовуються, недоступний код, повторюваний код)
Відхилення від стандартів (наприклад, недотримання стандартів кодування)
Неправильні специфікації інтерфейсу (наприклад, інші одиниці вимірювання, що використовуються системою, що викликає, та системою, що викликається)
Вразливості системи безпеки (наприклад, сприйнятливість до переповнення буфера)
Прогалини або неточності в простежуваності бази тестів або охопленні (наприклад, відсутність тестів для критерію прийнятності)
Крім того, більшість типів ремонтопридатних дефектів можна виявити лише за допомогою статичного тестування (наприклад, неправильна модульність, погана можливість повторного використання компонентів, код, який важко аналізувати та змінювати без введення нових дефектів).
Відмінності між статичним і динамічним тестуванням (версія 4.0)
Практики статичного та динамічного тестування доповнюють одна одну. Вони мають схожі цілі, як-от підтримка виявлення дефектів у робочих продуктах, але є й деякі відмінності, як-от:
Як статичне, так і динамічне тестування (з аналізом несправностей) можуть призвести до виявлення дефектів, однак є деякі типи дефектів, які можна знайти лише за допомогою статичного чи динамічного тестування.
Статичне тестування виявляє дефекти безпосередньо, тоді як динамічне тестування викликає збої, з яких пов’язані дефекти визначаються шляхом подальшого аналізу
Статичне тестування може легше виявляти дефекти, які лежать на шляху через код, який рідко виконується або важкодоступний за допомогою динамічного тестування
Статичне тестування можна застосовувати до невиконуваних робочих продуктів, тоді як динамічне тестування можна застосовувати лише до виконуваних робочих продуктів
Статичне тестування можна використовувати для вимірювання характеристик якості, які не залежать від коду, що виконується (наприклад, зручність супроводу), тоді як динамічне тестування можна використовувати для вимірювання характеристик якості, які залежать від коду, що виконується (наприклад, ефективність продуктивності)
Типові дефекти, які легше або дешевше знайти за допомогою статичного тестування, включають:
Дефекти вимог (наприклад, невідповідності, двозначності, протиріччя, упущення, неточності, дублювання)
Дефекти дизайну (наприклад, неефективна структура бази даних, погана модульність)
Певні типи дефектів кодування (наприклад, змінні з невизначеними значеннями, неоголошені змінні, недоступний або дубльований код, надмірна складність коду)
Відхилення від стандартів (наприклад, недотримання правил іменування в стандартах кодування)
Неправильні характеристики інтерфейсу (наприклад, невідповідність кількості, типу або порядку параметрів)
Конкретні типи вразливостей безпеки (наприклад, переповнення буфера)
Прогалини або неточності в охопленні тестової бази (наприклад, відсутність тестів для критерію прийнятності)
ISTQB Certified Tester Foundation Level. Курс для початківців. Секція 3.1.
В цьому відео починаємо працювати з секцією 3.1. 00:00:30 Основи статичного тестування 00:11:30 Робочі продукти, які можуть бути перевірені за допомогою статичного тестування 00:22:07 Переваги статичного тестування 00:31:56 Різниця між статичним та динамічним тестуванням
ISTQB Certified Tester Foundation Level. Курс для початківців. Розділ 2. Практика.
В цьому відео робиться спроба розібрати кілька десятків питань по другому розділу сілабуса ISTQB CTFL.
Всі питання з відео з правильними відповідями наводяться нижче.
Question 1
Which of the following is a test type?
Component testing
Functional testing
Acceptance testing
System testing
Question 2
Which option best describes objectives for test levels with a life cycle model?
Objectives should be generic for any test level.
Each level has objectives specific to that level.
The objectives of a test level don’t need to be defined in advance.
Objectives are the same for each test level.
Question 3
A regression test:
Will check unchanged areas of the software to see if they have been affected.
Will check changed areas of the software to see if they have been affected.
Will always be automated.
Is only run once.
Question 4
The four test levels defined for a common V-model testing approach are:
Unit, integration, system and maintenance.
Functional, glass box, incremental and maintenance.
Component, integration, system and acceptance.
Unit, component, functional and alpha/beta
Question 5
According to the ISTQB Glossary, regression testing is required for what purpose?
To prevent a task from being incorrectly considered completed.
To motivate better unit testing by the programmers
To ensure that defects have not been introduced by a modification
To verify the success of corrective actions.
Question 6
Beta testing is:
Performed by customers at the software developer’s site.
Useful to test software developed for a specific customer or user.
Performed by an independent test team.
Performed by customers at their own site.
Question 7
Alpha testing is:
Post-release testing by end user representatives at the developer`s site.
Pre-release testing by end user representatives at their sites.
The first testing that is performed.
Pre-release testing by end user representatives at the developer’s site.
Question 8
System Integration testing in the large involves:
Testing the system when combined with other systems.
Testing a system with a large number of users.
Combing software components and testing them in one go.
Testing a sub-system using stubs and drivers.
Question 9
Non-functional testing includes:
Testing a system feature using only the software required for that function.
Testing the quality attributes of the system including reliability and usability.
Testing to see where the system does not function correctly.
Gaining user approval for the system.
Question 10
Component testing may include
Sociability testing.
User acceptance testing.
Beta testing.
The use of stubs and drivers.
Question 11
Regression testing always involves
Executing a large number of different tests.
Using a test automation tool.
Testing whether a known software fault been fixed.
Testing whether modifications have introduced adverse side effects.
Question 12
Regression testing should be performed: I. Every week. II. After the software has changed. III. As often as possible. IV. When the environment has changed. V. When the project manager says.
II, III & IV are true, I & V are false.
II is true, I, III, IV & V are false.
I & II are true, III, IV & V are false.
II & IV are true, I, III & V are false.
Question 13
System testing is:
Used to search for defects in software modules that are separately testable.
The responsibility of the users of a system.
Concerned with the behavior of a whole system/product as defined by the scope of a development project.
Triggered by modifications, migration or retirement of the software system.
Question 14
System testing should investigate
Non-functional requirements or Functional requirements
Non-functional requirements only not Functional requirements
Functional requirements only not non-functional requirements
Non-functional requirements and Functional requirements
Question 15
What are good practices for testing within the development life cycle?
Early test analysis and design.
Different test levels are defined with specific objectives.
Testers will start to get involved as soon as coding is done.
A and B.
Question 16
Validation involves which of the following (i.) Helps to check the Quality of the Built Product. (ii.) Helps to check that we have built the right product. (iii.) Helps in developing the product. (iv.)Monitoring tool wastage and obsoleteness.
i,ii,iii are true and iv is false
Options i,ii,iii,iv are true.
iii is true and i,ii,iv are false.
ii is true and i,iii,iv are false.
Question 17
Verification involves which of the following : (i.) Helps to check the Quality of the built product (ii.) Helps to check that we have built the right product. (iii.) Helps in developing the product (iv.) Monitoring tool wastage and obsoleteness.
ii is true and i,iii,iv are false.
i is true and ii,iii,iv are false
Options i,ii,iii,iv are true.
i,ii,iii are true and iv is false
Question 18
What is the MAIN benefit of designing tests early in the life cycle?
It is cheaper than designing tests during the test phases.
Tests designed early are more effective than tests designed later.
It helps prevent defects from being introduced into the code.
It saves time during the testing phases when testers are busy.
Question 19
When a defect is detected and fixed then the software should be retested to confirm that the original defect has been successfully removed. This is called
Regression testing.
Maintenance testing.
Confirmation testing.
None of the above.
Question 20
Which of the following are characteristic of regression testing? (i) Regression testing is run ONLY once (ii) Regression testing is used after fixes have been made (iii) Regression testing is often automated (iv) Regression tests need not be maintained
i, iii, iv.
ii, iii.
iii.
ii, iv.
Question 21
Which of the following is a nonfunctional quality characteristic?
Usability
Maintenance
Feasibility
Regression
Question 22
Which of the following combinations correctly describes a valid approach to component testing: (i.) Functional testing of the component in isolation. (ii.) Structure-based testing of the code without recording incidents. (iii.) Automated tests that are run until the component passes. (iv.) Functional testing of the interfaces between modules.
iii.
i and ii.
ii and iv
i, ii and iii
Question 23
Which one of the following statements about system testing is NOT true?
End-users should be involved in system tests.
Faults found during system tests can be very expensive to fix.
System tests are often performed by independent teams.
Functional testing is used more than structural testing.
Після розгортання у виробничих середовищах програмне забезпечення та системи потребують обслуговування. Зміни різного роду майже неминучі в наданому програмному забезпеченні та системах, або для виправлення дефектів, виявлених під час оперативного використання, для додавання нових функціональних можливостей, або для видалення чи зміни вже наданих функціональних можливостей. Технічне обслуговування також необхідне для збереження або покращення нефункціональних якісних характеристик компонента або системи протягом терміну служби, особливо продуктивності, сумісності, надійності, безпеки та портативності.
Коли вносяться будь-які зміни в рамках технічного обслуговування, необхідно провести тестування технічного обслуговування, щоб оцінити успішність внесених змін і перевірити можливі побічні ефекти (наприклад, регресії) у частинах системи, які залишаються незмінними (що зазвичай є більшою частиною системи).
Технічне обслуговування може включати заплановані та незаплановані випуски (гарячі виправлення).
Реліз обслуговування може вимагати тестування обслуговування на кількох рівнях тестування з використанням різних типів тестування залежно від його обсягу. Обсяг технічного обслуговування залежить від:
Ступіню ризику зміни, наприклад, ступінь зв’язку зміненої області програмного забезпечення з іншими компонентами чи системами
Розмір існуючої системи
Розмір зміни
Тригери для супроводу
Існує кілька причин, чому технічне обслуговування програмного забезпечення, а отже, тестування супроводу, має місце як для запланованих, так і для незапланованих змін.
Модифікації, такі як заплановані вдосконалення (наприклад, на основі випуску), коригування та екстрені зміни, зміни робочого середовища (наприклад, заплановані оновлення операційної системи або бази даних), оновлення програмного забезпечення 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)