У світі розробки програмного забезпечення неможливо перевірити абсолютно все. Обмеженість ресурсів та часу вимагає від команди чіткого розуміння: що саме, як, коли і наскільки глибоко ми будемо тестувати. Саме на ці питання відповідає тестова стратегія (Test Strategy).

Що таке тестова стратегія згідно зі стандартами?

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

Якщо звернутися до міжнародних стандартів, сучасним орієнтиром є ISO/IEC/IEEE 29119 (в Україні адаптований як ДСТУ ISO/IEC/IEEE 29119). Цей стандарт чітко розділяє тестову стратегію на два рівні:

• Організаційна тестова стратегія (Organizational Test Strategy)

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

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

• Проєктна тестова стратегія (Project Test Strategy)

Деталізований підхід до тестування конкретного проєкту, який зазвичай є частиною тест-плану.

Історична довідка

У часи використання стандартів ГОСТ 19 та ГОСТ 34 (які іноді досі зустрічаються в державному секторі) аналогом тестової стратегії та тест-плану був документ «Программа и методика испытаний».

Він містив:

• перелік об’єктів тестування
• умови проведення випробувань
• детальні методики перевірки функцій

Сучасна IT-індустрія переважно використовує гнучкі міжнародні стандарти ISTQB та ISO.

Ієрархія документів: Політика → Стратегія → Тест-план

Щоб уникнути плутанини між документами, стандарт ISO/IEC/IEEE 29119 пропонує чітку ієрархію.

• Тестова політика (Test Policy)

Документ найвищого рівня, який описує мету, принципи та цілі тестування мовою бізнесу.

Відповідає на питання: «Чому ми тестуємо?»

• Організаційна тестова стратегія (Test Strategy)

Випливає з політики і визначає загальні правила тестування в компанії.

Відповідає на питання: «Як ми тестуємо в нашій організації?»

• Тест-план (Test Plan)

Документ конкретного проєкту, який описує:

• цілі тестування
• ресурси
• розклад
• бюджет
• тестовий підхід (Test Approach)

Тестовий підхід (Test Approach) — це спосіб реалізації тестування на конкретному проєкті. Саме він визначає рівні тестування, типи тестування та техніки тест-дизайну.

З чого складається проєктна тестова стратегія?

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

Зазвичай тестова стратегія містить такі компоненти.

Рівні тестування (Test Levels)

На яких етапах перевіряється продукт:

• Component testing (Unit testing)
• Integration testing
• System testing
• Acceptance testing (UAT)

Типи тестування (Test Types)

Які характеристики якості перевіряються:

• Functional testing
• Performance testing
• Security testing
• Usability testing

Техніки тест-дизайну (Test Techniques)

Методи створення тестів:

• техніки чорного ящика (класи еквівалентності, граничні значення)
• техніки білого ящика (аналіз коду)
• дослідницьке тестування (Exploratory testing)

Ступінь автоматизації

Визначається, які перевірки виконуються:

• вручну
• автоматизованими тестами

Наприклад, автоматизація часто використовується для регресійного тестування.

Критерії початку та завершення тестування

Entry Criteria — умови, за яких тестування можна починати.

Наприклад:

• середовище розгорнуте
• збірка стабільна
• вимоги доступні

Exit Criteria — умови завершення тестування. Наприклад:

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

Ризик-орієнтоване тестування (Risk-Based Testing)

Стандарти ISTQB та ISO підкреслюють важливий принцип: неможливо протестувати абсолютно все.

Саме тому сучасна тестова стратегія базується на аналізі ризиків (Risk-Based Testing).

Ризик — це потенційна проблема, яка оцінюється за двома параметрами:

• Likelihood — ймовірність виникнення
• Impact — вплив на бізнес або користувача

Чим вищий ризик, тим:

• раніше починається тестування
• більше ресурсів виділяється
• застосовуються більш суворі техніки тестування.

Наприклад:

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

Практичні приклади тестових стратегій

Різні продукти потребують кардинально різних тестових стратегій.

Приклад 1: програмне забезпечення для медичного обладнання (високий ризик)

Контекст і ризики

• можливий вплив на життя пацієнтів
• жорсткі регуляторні вимоги
• високі юридичні ризики

Тестовий підхід

• максимальний акцент на безпеці та надійності
• інтенсивне приймальне тестування (UAT)
• використання формальних технік (наприклад, FMEA або Hazard Analysis)
• суворе покриття коду

Автоматизація та документація

• формалізовані тест-кейси
• повна трасованість вимог (Traceability)
• незалежність команди тестування.

Приклад 2: маркетинговий веб-сайт для короткої промо-кампанії (низький ризик)

Контекст і ризики

• короткий життєвий цикл продукту (2–3 місяці)
• мінімальні бізнес-ризики
• основна мета — швидкий запуск.

Тестовий підхід

• акцент на крос-браузерному тестуванні
• перевірка UI та адаптивності
• використання чек-листів
• активне Exploratory testing

Автоматизація

• мінімальна або відсутня, оскільки економічно недоцільна.

Висновок

Тестова стратегія — це інтелектуальний план розподілу ресурсів тестування для досягнення максимальної якості продукту.

Відповідно до стандартів ISTQB та ISO/IEC/IEEE 29119, вона:

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

Якщо ти хочеш глибше розібратися у тестуванні програмного забезпечення, техніках тест-дизайну та стандартах ISTQB, приєднуйся до навчання в QALight. Наші курси допоможуть отримати практичні навички тестування та підготуватися до роботи в реальних IT-проєктах.