Keywords anomaly, dynamic testing, formal review, informal review, inspection, review, static analysis, static testing, technical review, walkthrough

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

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

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

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

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

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

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

3.1.2. Значення статичного тестування

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

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

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

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

3.1.3. Відмінності між статичним та динамічним тестуванням

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

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

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

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

3.2. Процес зворотного зв’язку та перевірки

3.2.1. Переваги раннього та частого зворотного зв’язку зацікавлених сторін

Ранній та частий зворотний зв’язок дозволяє завчасно повідомляти про потенційні проблеми з якістю. Якщо під час SDLC буде мало участі зацікавлених сторін, продукт, що розробляється, може не відповідати початковому або поточному баченню зацікавлених сторін. Нездатність виконати те, що хоче зацікавлена ​​сторона, може призвести до дорогої переробки, зриву термінів, звинувачень і навіть може призвести до повного провалу проекту.

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

3.2.2. Діяльність процесу рецензування

Стандарт ISO/IEC 20246 визначає загальний процес рецензування, який забезпечує структуровану, але гнучку структуру, на основі якої конкретний процес рецензування може бути адаптований до конкретної ситуації. Якщо необхідний огляд є більш формальним, тоді буде потрібно більше завдань, описаних для різних видів діяльності. Розмір багатьох робочих продуктів робить їх занадто великими, щоб охопити їх одним оглядом. Процес перевірки можна запустити кілька разів, щоб завершити перевірку всього робочого продукту.

Дії в процесі рецензування:

1. Планування. На етапі планування обсяг перевірки, який включає:
   – мету,
   – робочий продукт, який потрібно перевірити,
   – якісні характеристики, які потрібно оцінити,
   – області, на яких слід зосередитися,
   – критерії виходу,
   – супровідну інформацію, таку як стандарти, зусилля та часові рамки для перевірки.
2. Початок огляду. Під час ініціювання перевірки мета полягає в тому, щоб переконатися, що всі учасники готові розпочати перевірку. Це включає переконання, що кожен учасник має доступ до робочого продукту, який перевіряється, розуміє свою роль і обов’язки та отримує все необхідне для виконання перевірки.
3. Індивідуальний огляд. Кожен рецензент проводить індивідуальну перевірку, щоб оцінити якість робочого продукту, що перевіряється, і виявити аномалії, рекомендації та запитання, застосовуючи один або кілька методів перевірки (наприклад, перевірка на основі контрольного списку, перевірка на основі сценарію). Стандарт ISO/IEC 20246 надає більш детальну інформацію про різні методи перевірки. Рецензенти реєструють усі виявлені аномалії, рекомендації та запитання.
4. Комунікація та аналіз. Оскільки аномалії, виявлені під час огляду, не обов’язково є дефектами, усі ці аномалії необхідно проаналізувати та обговорити. Для кожної аномалії необхідно прийняти рішення щодо її статусу, власності та необхідних дій. Зазвичай це робиться на оглядовій зустрічі, під час якої учасники також вирішують, який рівень якості перевіреного робочого продукту та які подальші дії потрібні. Для завершення дій може знадобитися повторний огляд.
5. Фіксація та звітність. Для кожного дефекту слід створити звіт про дефект, щоб можна було вжити подальших заходів щодо усунення. Після досягнення критеріїв виходу робочий продукт може бути прийнятий. Про результати розгляду повідомляється.

3.2.3. Ролі та обов’язки в оглядах.

В аналізах беруть участь різні зацікавлені сторони, які можуть виконувати кілька ролей.

Основні ролі та їхні обов’язки такі:

• Менеджер – вирішує, що підлягає перевірці, і надає ресурси, наприклад персонал і час для перевірки
• Автор – створює та виправляє робочий продукт, який перевіряється
• Модератор (також відомий як фасилітатор) – забезпечує ефективне проведення оглядових зустрічей, включаючи посередництво, управління часом і безпечне середовище для огляду, у якому кожен може вільно говорити
• Писар (також відомий як записувач) – збирає аномалії від рецензентів і записує огляд інформацію, таку як рішення та нові аномалії, виявлені під час оглядової наради
• Рецензент – виконує перевірки. Рецензентом може бути хтось, хто працює над проектом, експерт із предметної теми чи будь-яка інша зацікавлена ​​сторона
• Керівник рецензування – бере на себе загальну відповідальність за рецензування, наприклад, вирішує, хто буде залучений, а також організовує час і місце рецензування Інше, більше можливі детальні ролі, як описано в стандарті ISO/IEC 20246.

3.2.4. Типи рецензування

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

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

Деякі типові огляди, які зазвичай використовуються:

• Неофіційний огляд. Неофіційні перевірки не дотримуються визначеного процесу та не вимагають офіційно задокументованих результатів. Головне завдання – виявлення аномалій.
• Покрокове керівництво. Покрокове керівництво, яке очолює автор, може служити багатьом цілям, таким як оцінка якості та формування довіри до робочого продукту, навчання рецензентів, досягнення консенсусу, генерація нових ідей, мотивація та надання можливості авторам вдосконалюватися та виявляти аномалії. Рецензенти можуть виконати індивідуальний огляд перед покроковим керівництвом, але це не обов’язково.
• Технічний огляд. Технічний огляд виконується технічно кваліфікованими рецензентами під керівництвом модератора. Цілі технічної перевірки полягають у досягненні консенсусу та ухваленні рішень щодо технічної проблеми, а також у виявленні аномалій, оцінці якості та зміцненні довіри до робочого продукту, генеруванні нових ідей, а також мотивації та можливості авторам вдосконалюватися.
• Перевірка. Оскільки інспекції є найбільш формальним типом перевірки, вони дотримуються повного загального процесу (див. розділ 3.2.2). Основна мета – знайти максимальну кількість аномалій. Інші цілі полягають у оцінці якості, зміцненні довіри до продукту роботи, а також у мотивації та дозволі авторам вдосконалюватися. Показники збираються та використовуються для вдосконалення SDLC, включаючи процес перевірки. При перевірках автор не може виступати в ролі керівника рецензії чи писаря.

3.2.5. Фактори успіху рецензій

Існує кілька факторів, які визначають успіх рецензій, зокрема:

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