Эволюция от IEEE 829 к ISO 29119

IEEE 829 дал нам стандартизированную документацию. Но документация — это лишь часть картины. А как насчёт самого процесса? Техник? Терминологии?

ISO 29119 стремится быть всеобъемлющим стандартом для тестирования ПО. Где IEEE 829 фокусировался узко на документации, ISO 29119 охватывает всю дисциплину.

Пять частей

Часть 1: Концепции и определения

Устанавливает терминологию (300+ терминов) и концептуальный фреймворк. Обеспечивает общий язык для точной коммуникации между организациями.

Часть 2: Процессы тестирования

Наиболее существенная часть. Определяет процессы в трёх слоях:

graph TD A[Организационный процесс] --> B[Процесс управления тестированием] B --> C[Динамический процесс] A -.->|Политики и стратегии| B B -.->|Планы и указания| C
  1. Организационный процесс — Политика тестирования, стратегия, общий подход
  2. Процесс управления — Планирование, мониторинг, контроль и завершение
  3. Динамический процесс — Проектирование, реализация, настройка окружения, выполнение, отчётность

Часть 3: Документация

Заменяет IEEE 829. Определяет шаблоны, включая организационные документы:

ДокументКогда создаётсяНазначение
Организационная политикаОдин раз, обновляетсяОбщеорганизационные правила
Организационная стратегияОдин раз, обновляетсяОбщеорганизационный подход
Тест-планНа проект/релизСпецифичный план
Отчёт о завершенииВ конце фазыИтоги тестирования
Отчёт о статусеРегулярноТекущий прогресс
Спецификация тест-кейсовПри проектированииКонкретные тест-кейсы
Требования к окружениюПри планированииНеобходимая инфраструктура
Отчёт готовности окруженияПеред выполнениемПодтверждение готовности

Часть 4: Техники тестирования

Полный каталог техник с инструкциями по применению:

КатегорияТехники
На основе спецификацииEquivalence partitioning, boundary value, decision tables, state transition, use case testing
На основе структурыStatement, branch, condition, MC/DC, path testing
На основе опытаError guessing, exploratory testing, checklist-based

Часть 5: Keyword-Driven Testing

Определяет фреймворк для keyword-driven автоматизации. Наименее принятая часть — большинство современных фреймворков (Playwright, Cypress) имеют собственные подходы.

ISO 29119 vs IEEE 829

АспектIEEE 829ISO 29119
ОбластьТолько документацияПроцессы, документация, техники, автоматизация
Частей15
Документация8 типов12+ типов включая организационный уровень
ПроцессыНе охваченыТрёхуровневая модель
ТехникиНе охваченыПолный каталог
СтатусЗаменён ISO 29119 Часть 3Действующий международный стандарт

Противоречия

ISO 29119 — один из самых спорных стандартов в тестировании.

Аргументы против

В 2014 году группа известных практиков запустила петицию за его отзыв (3,000+ подписей):

  1. Конфликт с ценностями Agile — Предписывает тяжёлую документацию, противоречащую принципу «работающее ПО важнее исчерпывающей документации»
  2. Одно решение для всех не работает — Подразумевает единственно верный способ тестирования
  3. Context-driven testing — Критики выступают за адаптацию практик к конкретному контексту
  4. Ограниченный вклад практиков — Разработан в основном комитетами по стандартам
  5. Давление сертификации — Опасения по поводу принудительного соответствия

Аргументы за

  1. Общий фреймворк — Разделяемая референция для организаций, особенно в аутсорсинге
  2. Руководство, не мандат — Стандарт явно допускает адаптацию
  3. Регуляторное соответствие — Упрощает обсуждения compliance
  4. Сохранение знаний — Документирует лучшие практики
  5. Контрактная ясность — Нейтральная основа для соглашений

Взвешенный взгляд

ISO 29119 ценен как справочник, но вреден при жёстком применении без учёта контекста. Старший QA-специалист должен знать содержание, понимать когда стандарт полезен, а когда избыточен, и уметь выбирать релевантные части.

Практические рекомендации

Для регулируемых отраслей

Принимайте Части 1-3 как организационный фреймворк. Часть 4 — как справочник.

Для крупных организаций с аутсорсингом

Используйте Часть 2 и 3 как контрактную основу.

Для Agile-команд

Выбирайте полезное: терминологию из Части 1, техники из Части 4. Пропускайте тяжёлую документацию Части 3.

Для подготовки к ISTQB

Знайте 5 частей, их область применения и связь с IEEE 829.

Упражнение: сравните ISO 29119 с вашим текущим процессом

Сценарий: Вы QA-консультант, оценивающий финтех-компанию. 80 разработчиков, 20 тестировщиков, Scrum, обязательно соответствие PCI-DSS для платёжного модуля.

Текущий процесс:

  • Нет организационной политики или стратегии тестирования
  • У каждой Scrum-команды свой подход
  • Тест-кейсы в TestRail по user story
  • Баг-репорты в Jira
  • Отчёты по спринтам из TestRail
  • Нет формальной документации техник
  • Автоматизация на Playwright, без keyword-driven

Задания:

  1. Для каждой из 5 частей ISO 29119 оцените текущую реализацию (полностью, частично, нет)
  2. Учитывая PCI-DSS, какие элементы приоритизировать?
  3. Учитывая Agile, какие элементы явно пропустить и почему?
Подсказка

Учитывайте двойственность: PCI-DSS требует формальности, а Agile — гибкости. Найдите баланс, применяя формальные элементы только там, где требует регуляция (платёжный модуль), а остальное оставляя лёгким.

Решение

1. Оценка

ЧастьЭлементСтатус
Часть 1Общая терминологияЧастично (неформально)
Часть 2Организационный процессНе реализован
Часть 2Процесс управленияЧастично (по командам, непоследовательно)
Часть 3Организационная политикаНе реализована
Часть 3Тест-планыЧастично (уровень спринта)
Часть 3Спецификации тест-кейсовПолностью (TestRail)
Часть 4Формальные техникиНе реализованы
Часть 5Keyword-drivenНе применимо

2. Приоритеты для PCI-DSS

  1. Организационная политика — Аудиторы PCI-DSS ожидают документированные политики
  2. Формальный процесс для платёжного модуля — Планирование, мониторинг и завершение
  3. Формальная документация для платёжного модуля — Тест-планы, спецификации, отчёты
  4. Формальные техники для security testing — Документированное применение техник

3. Элементы для пропуска

  1. Часть 5 — Playwright работает, переход на keyword-driven без пользы
  2. Полная документация Части 3 для не-платёжных функций — TestRail и Jira достаточны
  3. Формальный организационный процесс для всех команд — Конфликтует с самоорганизацией Agile
  4. Документация техник для каждой фичи — Только для высокорисковых функций

Ключевой вывод: Применяйте формальность ISO 29119 пропорционально риску.

Ключевые выводы

  • ISO 29119 — всеобъемлющий 5-частный стандарт, охватывающий концепции, процессы, документацию, техники и keyword-driven testing
  • Заменяет IEEE 829 для документации (Часть 3), добавляя покрытие процессов и техник
  • Стандарт спорный — критики считают его конфликтующим с Agile; сторонники ценят полноту фреймворка
  • Практическое принятие должно быть context-driven: формальность там, где требует регуляция или риск
  • ISO 29119 — справочник для выбора, а не жёсткий свод правил