ISTQB Fundamentals: Статичне тестування, або Рецензування

Привіт, мене звати Наталія Попелишко, я працюю Test Automation інженеркою 4 роки, а також навчаю трейнят тестуванню:)

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

1. Хоче здати сертифікацію ISTQB Foundation.
2. Хоче підготуватись до КЕ, PE та інших способів отримати більшу зарплатню.
3. Хоче покращити знання в сфері мануального тестування.

Що таке статичне тестування та навіщо його проводити

Статична перевірка або Рецензування — це перевірка будь-яких робочих продуктів (документів), створених у процесі розробки ПЗ.

В кінці статті ви будете знати і розрізняти види статичного тестування, а також ролі і процеси в статичному тестуванні.

Загалом існує 4 типи статичних перевірок:

1. Неформальна перевірка — Informal review.
2. Покроковий розбір — Walkthrough.
3. Технічна перевірка — Technican review.
4. Інспекція — Inspection.

Різницю між ними ви дізнаєтесь в кінці статті, а поки що — нумо вчити всі деталі, необхідні для цієї теми :)

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

• Специфікації, включаючи бізнес-вимоги, функціональні вимоги та вимоги безпеки.
• Епіки, користувальницькі історії, критерії прийняття з вашої Jira.
• Код — за допомогою процесу code review.
• Тестову документацію, включаючи тест-плани, тест-кейси, тестові процедури та автоматизовані тестові сценарії.
• Посібники користувача (гайди, інструкції).
• Вебсторінки та їх макети.
• Контракти, проєктні плани, графіки та бюджети.
• Моделі та діаграми, наприклад, Use Case та State-Transition.

Навіщо взагалі потрібні статичні перевірки

• Виявлення та виправлення дефектів більш ефективне до проведення динамічного тестування (того, що вимагає запуску програми). Тому спершу перевіряємо документацію (вимоги, код, тест-кейси) і шукаємо помилки там.
• Запобігання дефектам дизайну або коду шляхом виправлення вимог. Для цього ми шукаємо в документах невідповідності, неоднозначності, суперечності, упущення, неточності та «нереальність» вимог.
• Через покращення дизайну та коду — підвищення продуктивності розробки.
• Скорочення витрат та часу на розробку (бо ж перевірені вимоги зрозуміліші та повніші).
• Скорочення витрат та часу на тестування (бо і код хороший, і документація є).
• Покращення комунікації між членами команди в процесі участі у Рецензуванні.

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

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

Активності процесу Рецензування

Тепер перейдемо до деталей. Процес перевірки (Рецензування) складається з наступних активностей:

1. Планування.
2. Ініціація перевірки.
3. Індивідуальна перевірка.
4. Обговорення проблем та аналіз.
5. Виправлення та звіт.

Що відбувається в процесі планування:

• Визначення обсягу роботи, що включає рецензування, які документи або частини документа підлягають розгляду.
• Оцінка тривалості перевірки та трудовитрат.
• Визначення типу рецензування, ролей, які братимуть участь.
• Вибір людей для участі у рецензуванні та розподіл ролей.

Ініціювання рецензування включає:

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

Під час індивідуального рецензування:

• Рецензенти перевіряють документ або його частину.
• Вони шукають та описують недоліки, рекомендації та питання.

В обговорення проблем та аналіз входять:

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

Під час внесення змін та звітності:

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

Ролі процесу рецензування

Коли процес рецензування офіційний, він має 6 ролей.

1. Автор

• Створює документ для перевірки.
• Виправляє дефекти в цьому документі.

2. Менеджер

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

3. Ведучий, або модератор

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

4. Керівник рецензування

• Бере на себе загальну відповідальність за рецензування.
• Вирішує, хто братиме участь, організовує час та місце проведення.

5. Рецензенти, або Контролери

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

6. Секретар, або Реєстратор

• Записує всі дефекти, відкриті питання та рішення під час проведення наради з рецензування.

Види статичних перевірок та відмінності між ними

Окей. Тепер ви знаєте достатньо, щоб навчитися головного: розрізняти 4 типи статичних перевірок. Розглянемо кожну детально, в порядку зростання формальності.

Неформальна перевірка

Власне, неформальний процес. Він може набувати форми парного програмування. Зазвичай Техлід перевіряє дизайн чи код. Найпопулярнішим прикладом неформальної перевірки є code review. Основна мета: недорогий спосіб знайти потенційні дефекти.

Покроковий розбір

Цей мітинг проводиться автором документа, що перевіряється. Мітинг у форматі відкритої сесії, куди може прийти будь-хто. Він може бути і формальним, і неформальним. Підготовка перед мітингом, звіти про перевірку документа, роль секретаря не є обов’язковими.

Основна мета — навчання, розуміння, пошук дефектів.

Технічна перевірка

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

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

Інспекція

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

Основна мета — пошук дефектів.

***

Вся теоретична інформація взята з навчальної програми ISTQB fundamentals.

Якщо вам сподобалась стаття / ви хочете підготуватися до ISTQB fundamentals / вивчити різні теми з тестування ПЗ, ласкаво прошу до мого ютубчика, де я щодня викладаю нові лекції з тестування.