Month: December 2023

Категорії тестових технік (версія 3.1)

Метою методів тестування є допомога у визначенні умов тестування, тестових кейсів і тестових даних.

Вибір методів тестування залежить від ряду факторів, зокрема:

• Складність компонентів або системи
• Регуляторні стандарти
• Вимоги замовника або контракту
• Рівні та типи ризиків
• Наявна документація
• Знань і навичок тестувальника
• Доступних інструментів
• Часу і бюджету
• Моделі життєвого циклу розробки програмного забезпечення
• Типів дефектів, які очікуються в компоненті чи системі

Деякі техніки більш застосовні до певних ситуацій і рівнів тестування; інші застосовні до всіх рівнів тестування. Створюючи тестові випадки, тестувальники зазвичай використовують комбінацію технік тестування, щоб досягти найкращих результатів тестування.

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

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

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

Методи тестування на основі досвіду використовують досвід розробників, тестувальників і користувачів для розробки, реалізації та виконання тестів. Ці методи часто поєднуються з методами тестування чорної та білої скриньок.

Загальні характеристики методів тестування чорної скриньки включають наступне:

• Умови тестування, тестові кейси та тестові дані отримані з тестової бази, яка може включати вимоги до програмного забезпечення, специфікації, варіанти використання та історії користувачів
• Тестові приклади можуть бути використані для виявлення прогалин між вимогами та виконанням вимог, а також відхилень від вимог
• Покриття вимірюється на основі елементів, протестованих у тестовій базі, і техніки, застосованої до тестової бази

Загальні характеристики методів тестування білого ящика включають:

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

Загальні характеристики методів тестування на основі досвіду включають:

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

Міжнародний стандарт (ISO/IEC/IEEE 29119-4) містить описи методів тестування та відповідних показників покриття.

Категорії тестових технік (версія 4.0)

Методи тестування допомагають тестувальнику в аналізі тесту (що тестувати) і в дизайні тесту (як тестувати). Методи тестування допомагають систематично розробити відносно невеликий, але достатній набір тестів. Методи тестування також допомагають тестувальнику визначити умови тестування, ідентифікувати елементи покриття та ідентифікувати тестові дані під час аналізу та розробки тесту. Додаткову інформацію щодо методів тестування та відповідних заходів можна знайти в стандарті ISO/IEC/IEEE 29119-4, а також у (Beizer 1990, Craig 2002, Copeland 2004, Koomen 2006, Jorgensen 2014, Ammann 2016, Forgács 2019).

У цьому сілабусі методи тестування класифікуються як «чорної скриньки», «білої скриньки» і засновані на досвіді.

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

Методи тестування білої скриньки (також відомі як методи на основі структури) базуються на аналізі внутрішньої структури тестового об’єкта та обробки. Оскільки тестові кейси залежать від того, як розроблено програмне забезпечення, їх можна створити лише після розробки або впровадження тестового об’єкта.

Методи тестування, засновані на досвіді, ефективно використовують знання та досвід тестувальників для розробки та реалізації тестів. Ефективність цих методів значною мірою залежить від навичок тестувальника. Методи тестування, засновані на досвіді, можуть виявити дефекти, які можна пропустити за допомогою методів тестування чорної та білої скриньок. Таким чином, методи тестування, засновані на досвіді, доповнюють методи тестування чорної та білої скриньок.

В цьому відео починаємо працювати з секцією 4.1.
00:00:54 Категорії тестових технік
00:09:25 Техніки чорної скриньки, білої скриньки, техніки тестування засновані на досвіді

Статичний аналіз за допомогою інструментів

Метою статичного аналізу є виявлення дефектів у вихідному коді програмного забезпечення та моделях програмного забезпечення.

Потік керування — це послідовність подій (шляхів) у виконанні через компонент або систему.

Потік даних — це абстрактне представлення послідовності та можливих змін стану об’єктів даних, де стан об’єкта є будь-яким із наступних: створення, використання або видалення.

Метрики коду

Під час виконання статичного аналізу коду обчислюється інформація про структурні атрибути коду, такі як:

• Частота коментарів
• Глибина вкладення
• Цикломатичне число
• Кількість рядків коду

Показники складності ідентифікують зони з високим ризиком і складність. Досвідчені програмісти знають, що 20% коду викличуть 80% проблем, а аналіз складності допомагає знайти ці важливі 20%.

Цінність статичного аналізу

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

Типові дефекти

Типові дефекти, виявлені інструментами статичного аналізу:

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

Статичні Інструменти

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

Інструменти статичного аналізу можуть створювати велику кількість попереджувальних повідомлень, якими потрібно добре керувати, щоб забезпечити найбільш ефективне використання інструменту. Компілятори можуть запропонувати певну підтримку для статичного аналізу, включаючи обчислення показників.

Розбір тестових питань по третьому розділу

В цьому відео робиться спроба розібрати кілька десятків питань по третьому розділу сілабусу ISTQB CTFL.

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

1. Software code
2. Requirements specification
3. Test designs
4. 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

1. Moderator
2. Reviewers
3. Author
4. 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?

1. II, III and IV.
2. I, II, III and IV
3. I, II and III
4. I, II and IV

Question 4

A program with high cyclomatic complexity is almost likely to be:

1. Difficult to write.
2. Difficult to test.
3. Small.
4. Large.

Question 5

An important benefit of code inspections is that they:

1. enable the code to be tested before the execution environment is ready.
2. can be performed by inexperienced staff.
3. can be performed by the person who wrote the code.
4. are cheap to perform.

Question 6

Could reviews or inspections be considered part of testing:

1. No, because they apply to development documentation.
2. No, because they do not apply to the test documentation.
3. Yes, because testing includes all non-constructive activities.
4. Yes, because both help detect faults and improve quality.

Question 7

In a review meeting a moderator is a person who

1. Takes telephone calls
2. Takes minutes of the meeting
3. Mediates between people
4. Writes the documents to be reviewed

Question 8

Peer Reviews are also called as:

1. Formal Review.
2. Walkthrough.
3. Technical Review.
4. Inspection.

Question 9

People who don’t participate in technical reviews:

1. Analysts.
2. Testers.
3. Management.
4. Developers.

Question 10

Static analysis is best described as:

1. the use of black box testing.
2. the analysis of program code.
3. the analysis of batch programs.
4. the reviewing of test plans.

Question 11

Static code analysis typically identifies all but one of the following problems. Which is it?

1. Too few comments
2. Faults in the requirements
3. Unreachable code
4. 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.

1. II is correct.
2. II, III, IV are correct and I is incorrect.
3. III, I, IV is correct and II is incorrect.
4. I, III, IV, II is incorrect.

Question 13

The Kick Off phase of a formal review includes the following:

1. Explaining the objective.
2. Fixing defects found typically done by author.
3. Individual Meeting preparations.
4. Follow up.

Question 14

What can static analysis NOT find?

1. Whether the value stored in a variable is correct.
2. The use of a variable before it has been defined.
3. Array bound violations.
4. Unreachable (“dead”) code.

Question 15

What is the main difference between a walkthrough and an inspection?

1. A walkthrough is led by the author, while an inspection is led by a trained moderator.
2. An inspection has a trained leader, while a walk through has no leader.
3. An inspection is led by the authors, while a walk through is led by a trained moderator.
4. Authors are not present during inspections, while they are during walkthroughs.

Question 16

What is the main purpose of Informal review

1. Discuss, make decisions, solve technical problems
2. Inexpensive way to get some benefit
3. Find defects
4. Learning, gaining understanding, effect finding

Question 17

What statement about reviews is true?

1. Inspections are led by a trained moderator, whereas technical reviews are not necessarily.
2. In a walkthrough, the author does not attend.
3. Participants for a walkthrough always need to be thoroughly trained.
4. Technical reviews are led by a trained leader, inspections are not.

Question 18

What statement about static analysis is true?

1. Compiling is not a form of static analysis.
2. Static analysis finds all faults.
3. With static analysis, defects can be found that are difficult to find with dynamic testing.
4. 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

s) Inspection
t) Peer review
u) Informal review
v) Walkthrough

1. s = 4, t = 3, u = 2 and 5, v = 1
2. s = 5, t = 4, u = 3, v = 1 and 2
3. s = 1 and 5, t = 3, u = 2, v = 4
4. s = 4 and 5, t = 3, u = 2, v = 1

Question 20

Which is not a type of review?

1. Informal review
2. Inspection
3. Walkthrough
4. Management approval

Question 21

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.

1. II, III and IV
2. I, II and III
3. IV
4. I and III

Question 22

Which statement about the function of a static analysis tool is true?

1. Gives information about what code has and has not been exercised.
2. Can detect memory leaks.
3. Gives quality information about the code without executing it.
4. Checks expected results against actual results.

Процес перегляду (версія 3.1)

Перегляди варіюються від неофіційних до офіційних. Неофіційні перегляди характеризуються недотриманням визначеного процесу та відсутністю офіційно задокументованих результатів. Для формальних перевірок характерна участь команди, задокументовані результати перевірки та задокументовані процедури проведення перевірки. Формальність процесу перевірки пов’язана з такими факторами, як модель життєвого циклу розробки програмного забезпечення, зрілість процесу розробки, складність робочого продукту, який перевіряється, будь-які законодавчі чи нормативні вимоги та/або необхідність аудиторського сліду.

Спрямованість перевірки залежить від узгоджених цілей перевірки (наприклад, виявлення дефектів, отримання розуміння, навчання учасників, таких як тестувальники та нові члени команди, або обговорення та прийняття рішень шляхом консенсусу).

Стандарт 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)

Є кілька факторів, які визначають успіх оглядів, зокрема:

• Визначення чітких цілей і вимірних критеріїв виходу. Оцінка учасників ніколи не повинна бути об’єктивною
• Вибір відповідного типу перевірки для досягнення поставлених цілей і відповідно до типу робочого продукту, учасників перевірки, потреб проєкту та контексту
• Проведення оглядів невеликими частинами, щоб рецензенти не втрачали концентрацію під час окремого огляду та/або зустрічі з огляду (якщо вона проводиться)
• Надання відгуків зацікавленим сторонам і авторам від рецензій, щоб вони могли покращити продукт і свою діяльність
• Надання достатнього часу учасникам для підготовки до перегляду
• Підтримка процесу перегляду з боку керівництва
• Зробити огляди частиною культури організації, щоб сприяти навчанню та вдосконаленню процесу
• Забезпечення відповідного навчання для всіх учасників, щоб вони знали, як виконувати свою роль
• Спрощення зустрічей

В цьому відео починаємо працювати з секцією 3.2.
00:00:54 Процес перегляду/перевірки (Review process)
00:07:11 Процес перегляду/перевірки робочих продуктів
00:29:18 Ролі і відповідальсть при формальному перегляді
00:41:16 Типи переглядів/перевірок
01:05:30 Застосування технік переглядів/перевірок
01:21:52 Фактори успіху для перегляду/перевірки

Основи статичного тестування (версія 3.1)

На відміну від динамічного тестування, яке вимагає виконання програмного забезпечення, що тестується, статичне тестування спирається на перевірку робочих продуктів вручну (тобто перегляди) або керовану інструментами оцінку коду чи інших робочих продуктів (тобто статичний аналіз). Обидва типи статичного тестування оцінюють код або інший робочий продукт, що тестується, без фактичного виконання коду або робочого продукту, що тестується.

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

Основи статичного тестування (версія 4.0)

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

Тестувальники, представники бізнесу та розробники працюють разом під час зіставлення прикладів, спільного написання історій користувачів і сеансів уточнення резервів, щоб переконатися, що історії користувачів і пов’язані з ними робочі продукти відповідають визначеним критеріям, наприклад, визначенню Ready. Щоб переконатися, що історії користувачів повні та зрозумілі, а також включають критерії прийнятності, які можна перевірити, можна застосувати методи перевірки. Ставлячи правильні запитання, тестувальники досліджують, оскаржують і допомагають покращити запропоновані історії користувачів.

Статичний аналіз може виявити проблеми до динамічного тестування, хоча часто вимагає менше зусиль, оскільки тестові приклади не потрібні, і зазвичай використовуються інструменти. Статичний аналіз часто включений у фреймворки CI (continuous integration). Хоча в основному використовується для виявлення конкретних дефектів коду, статичний аналіз також використовується для оцінки зручності супроводу та безпеки. Іншими прикладами інструментів статичного аналізу є засоби перевірки орфографії та засоби читабельності.

Робочі продукти, які можуть бути перевірені за допомогою статичного тестування (версія 3.1)

Майже будь-який робочий продукт можна перевірити за допомогою статичного тестування (переглядів та/або статичного аналізу), наприклад:

• Специфікації, включаючи бізнес-вимоги, функціональні вимоги та вимоги безпеки
• Епіки, історії користувачів і критерії прийняття
• Специфікації архітектури та дизайну
• Код
• Програмне забезпечення для тестування, включаючи плани тестування, тестові кейси, процедури тестування та сценарії автоматизованого тестування
• Посібники користувача
• Веб-сторінки
• Контракти, плани проєктів, графіки та бюджетне планування
• Налаштування конфігурації та налаштування інфраструктури
• Моделі, такі як діаграми діяльності, які можна використовувати для тестування на основі моделі

Перегляди можна застосовувати до будь-якого робочого продукту, який учасники можуть читати та розуміти. Статичний аналіз можна ефективно застосовувати до будь-якого робочого продукту з формальною структурою (як правило, кодом або моделями), для якого існує відповідний інструмент статичного аналізу. Статичний аналіз можна навіть застосувати за допомогою інструментів, які оцінюють робочі продукти, написані природною мовою, такі як вимоги (наприклад, перевірка орфографії, граматики та читабельності).

Робочі продукти, які можуть бути перевірені за допомогою статичного тестування (версія 4.0)

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

Предметом рецензії може бути будь-який продукт роботи, який можна прочитати і зрозуміти. Однак для статичного аналізу робочим продуктам потрібна структура, за якою їх можна перевірити (наприклад, моделі, код або текст із формальним синтаксисом).

Робочі продукти, які не підходять для статичного тестування, включають ті, які важко інтерпретувати людям і які не слід аналізувати інструментами (наприклад, виконуваний код третьої сторони через юридичні причини).

Переваги статичного тестування (версія 3.1)

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

Додаткові переваги статичного тестування можуть включати:

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

Цінність статичного тестування (версія 4.0)

Статичне тестування може виявити дефекти на самих ранніх фазах SDLC, дотримуючись принципу раннього тестування. Воно також може ідентифікувати дефекти, які неможливо виявити за допомогою динамічного тестування (наприклад, недоступний код, шаблони проєктування, які не реалізовані належним чином, дефекти в невиконуваних робочих продуктах).

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

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

Відмінності між статичним і динамічним тестуванням (версія 3.1)

Статичне тестування та динамічне тестування можуть мати однакові цілі, наприклад, забезпечити оцінку якості робочих продуктів і виявити дефекти якомога раніше. Статичні та динамічні тести доповнюють одне одного, виявляючи різні типи дефектів.

Однією з головних відмінностей є те, що статичне тестування виявляє дефекти в робочих продуктах безпосередньо, а не визначає збої, викликані дефектами під час запуску програмного забезпечення. Дефект може існувати в робочому продукті протягом дуже тривалого часу, не викликаючи збою. Шлях, де знаходиться дефект, може рідко проходити або бути важкодоступним, тому буде непросто побудувати та виконати динамічний тест, який його виявить. Статичне тестування може виявити дефект із набагато меншими зусиллями.

Інша відмінність полягає в тому, що статичне тестування можна використовувати для покращення узгодженості та внутрішньої якості робочих продуктів, тоді як динамічне тестування зазвичай зосереджується на зовнішніх видимих поведінках.

У порівнянні з динамічним тестуванням типові дефекти, які легше та дешевше знайти та виправити за допомогою статичного тестування, включають:

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

Крім того, більшість типів ремонтопридатних дефектів можна виявити лише за допомогою статичного тестування (наприклад, неправильна модульність, погана можливість повторного використання компонентів, код, який важко аналізувати та змінювати без введення нових дефектів).

Відмінності між статичним і динамічним тестуванням (версія 4.0)

Практики статичного та динамічного тестування доповнюють одна одну. Вони мають схожі цілі, як-от підтримка виявлення дефектів у робочих продуктах, але є й деякі відмінності, як-от:

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

Типові дефекти, які легше або дешевше знайти за допомогою статичного тестування, включають:

• Дефекти вимог (наприклад, невідповідності, двозначності, протиріччя, упущення, неточності, дублювання)
• Дефекти дизайну (наприклад, неефективна структура бази даних, погана модульність)
• Певні типи дефектів кодування (наприклад, змінні з невизначеними значеннями, неоголошені змінні, недоступний або дубльований код, надмірна складність коду)
• Відхилення від стандартів (наприклад, недотримання правил іменування в стандартах кодування)
• Неправильні характеристики інтерфейсу (наприклад, невідповідність кількості, типу або порядку параметрів)
• Конкретні типи вразливостей безпеки (наприклад, переповнення буфера)
• Прогалини або неточності в охопленні тестової бази (наприклад, відсутність тестів для критерію прийнятності)

В цьому відео починаємо працювати з секцією 3.1.
00:00:30 Основи статичного тестування
00:11:30 Робочі продукти, які можуть бути перевірені за допомогою статичного тестування
00:22:07 Переваги статичного тестування
00:31:56 Різниця між статичним та динамічним тестуванням