Weekend testing #01: Тестовая стратегия

В субботу 31 января пройдет первая сессия
Weekend testing на русском языке. Подробнее об участии - на сайте SPB SQA сообщества - http://sqagroup.spb.ru/announces/weekend-testing-01/. Приходите, мы будем вам рады!

В этом сообщении я хотел бы рассказать о своем понимании тестовой cтрат‎егии и поделиться опытом ее создания.

‎Тестовая стратегия определяет то, как мы тестируем продукт. Это набор мыслей и идей, которые направляют процесс тестирования. В разных компаниях, а также в разных источниках это понятие может звучать по-разному - например, как подход к тестированию или высокоуровневый тест план. Я считаю, что разница между тестовой стратегией и тест планом заключается в покрытии и ‎уровне детализации. Стратегия покрывает процесс тестирования продукта в целом, а тест план обычно покрывает какую-то часть тестирования или отдельный релиз. Уровень детализации у тест плана как правило выше, он в своем роде уточняет тестовую стратегию, наполняет ее необходимыми деталями. Но граница между этими понятиями - условна и размыта. В тестовой стратегии могут покрываться в деталях некоторые важные моменты, в тест плане могут быть обобщения.

Формирование тестовой стратегии - интересный процесс, который часто выполняется нами на уровне интуиции, когда мы сами не до конца осознаем, почему мы решили делать так или иначе. Часто после своего формирования где-то на уровне интуиции стратегия так и продолжает жить там, в области неосознанного. Давайте попробуем достать её оттуда.

Для этого - разложим по шагам процесс формирования стратегии. Я вижу его примерно так:

1 шаг. Сбор информации. На этом этапе мы изучаем продукт и его контекст. Мы получаем информацию из разных источников: разговоры со стейкхолдерами, исследовательское тестирование (или туры, цель которых - изучить продукт, а не найти его проблемы), чтение документации.

 

2 шаг. Анализ информации. На следующем этапе мы из всей кучи информации пытаемся выбрать важное, чтобы на основе этого сформировать стратегию. Мы фильтруем собранную информацию и оставляем самое необходимое.

 

3 шаг. Принятие решений. После того, как у нас есть база знаний о продукте и его контексте - мы готовы к формированию стратегии. На данном этапе происходит ее рождение. Мы принимаем решения относительно того, как мы будем тестировать продукт. Набор этих решений и будет составлять основу тестовой стратегии.

 

4 шаг. Презентация.‎ До этого этапа доходит не всегда. Иногда вас просто не спрашивают о том, как вы тестируете и почему. Но если спросят - вы должны быть готовы объяснить ваши решения и обосновать их правильность. Если вы умеете выражать стратегию на бумаге - это вам здорово поможет.

‎Границу между этими 4-мя шагами не всегда просто найти. Например, мы не всегда отдаем себе отчет, когда переходим от сбора информации к анализу. Мы не всегда двигаемся последовательно от 1-го шага к 4-му, а, например, часто делаем прямой переход от 1-го сразу к 3-му. Мы также можем возвращаться назад - от принятия решений обратно к сбору информации. Это творческий процесс.

‎При создании тестовой стратегии я иногда использую HTSM (Heuristic Test Strategy Model - http://satisfice.com/tools/htsm.pdf), созданную Джеймсом Бахом. У этой модели есть интересная особенность - она явно не говорит, что вам нужно делать. Эта модель дается как подсказка-эвристика, которая помогает вам думать в определенном направлении. Она помогает вам принимать решения, но не делает их за вас. Это как своеобразная стратегия для создания тестовой стратегии :)

HTSM состоит из следующих частей:

Project Environment. Я понимаю это как контекст продукта, то есть все, что его окружает: команда, график релизов, ресурсы, артефакты, репорты.

Product Elements. То, из чего состоит продукт. В модели HTSM дается полезная мнемоника SFDIPOT (San Francisco Depot) для того, чтобы структурировать подход к изучению элементов продукта. Просто пройдитесь по расшифровке этой мнемоники - и получите готовые идеи разбиения продукта на части. 

Quality criteria. Какие критерии качества будут важны для нас? В модели перечисляются как основные и общеизвестные критерии (Security, Compatibility, Reliability), так и менее ожидаемые (лично для меня), такие как Charisma. Внутри этих крупных критериев качества вы найдете более мелкие критерии, которые тоже являются своеобразными идеями того, что продукт может уметь в принципе.

Test techniques. Техники тестирования, которые вы можете применять. Опять же, в этой части модели перечисляются основные и общеизвестные техники (функциональное тестирование, доменное тестирование, тестирование, основанное на рисках), которые дают вам некоторую наводку, вроде: "Функциональное тестирование. Подумайте в этом направлении. Тестирование потока данных и операций. Применимо ли это к вашему продукту? А важно ли для вас выполнить тестирование со стороны пользователей? Решать, конечно, вам."

 

Perceived Quality. Это результат работы нашей тестовой стратегии. Возможно я не совсем понимаю смысл этой части, но мне непонятно, как эта часть помогает думать о тестовой стратегии :)

Можно проследить, какие части HTSM мы используем во время выполнения шагов по формированию тестовой стратегии. Картинка:

При сборе информации и её анализе нам пригодятся в основном части модели, посвященные элементам продукта (Product Elements), критериям качества (Quality Criteria) и окружению продукта (Project Environment). При принятии решений - нам пригодится часть модели, описанная в техниках тестирования (Test Techniques). А вот с этапом презентации мы будем разбираться без помощи HTSM :)

Конкретная реализация описанных шагов, использование HTSM как подсказки - вопрос практики и тренировки. Я попробовал предложить только некоторую структуру - последовательность действий, которая вам может помочь. Приходите на сессию Weekend testing, потренируемся!