Только вкатился, помогите разобраться :(

Друзья, привет!

Я тут новичок, рассчитываю на вашу помощь. Опишу свою ситуацию:
Мы пишем стратегию тестирования - общую (прям так и называется “общая стратегия тестирования). Потом мы пишем стратегию тестирования частную и пишем ее для каждой системы, которую разрабатываем (частная стратегия тестирования для АС[название]).

Вопрос: Нужно ли это всё, если ценность этого документа, как и его наполнения понимает только автор?

Тоесть вроде как с точки зрения иерархии это можно объяснить тем, что есть уровни:

Стратегический. Описывает цели, правила и контекст тестирования: Общая стратегия тестирования общая, Стратегия тестирования АС.

Процессный. Описывает процессы, потоки работ и правила взаимодействия: Регламенты, Процедуры, Методики.

Операционный. Описывает максимально детализированные артефакты для непосредственного исполнения: Инструкции, Тест-кейсы, Чек-листы, Отчеты о тестировании и т.п.

Но я не понимаю, почему мы не идем относительно этих уровней?

Стратегический - общая стратегия

Процессный - уровень системы (у нас сейчас - это как раз на уровне частной стратегии, просто я в принципе не понимаю, чем на стратегическом уровне может отличатся тестирование АС от общей стратегии?)

Операционный - это уже команда, артефакты, описания и тд.

Ну и даже если я не прав с точки зрения онтологии (что скорее всего) мысль следующая: сначала нам надо отмоделировать иерархию какую-то. Чтобы понять вообще где какой уровень находится. Ну мы же должны понимать, от чего мы пляшем, когда это все пишем? Также нам надо заземлиться, верно же? Какая разница на каком уровне описание, если оно не понятно команде, потому что там все написано общими фразами? Мы написали частную стратегию, намешали уровни, с одной стороны, но с другой - максимально понятно сделали это для команды…

Важно: этот ответ дает человек, сопричастный к ШСМ/МИМ с 2022 года, а не автор руководства «1. Рациональная работа».

Для полноты обратитесь к наставникам.


Как я понял Ваш запрос, так и отвечаю.

Главное: Вы не ошиблись в интуиции. Иерархия нужна. Но только если её заполнять моделированием, а не формой.

Подробности.

1.

Мне лично этот вопрос кажется архиважным: иерархия уровней работает только если у Вас есть ясная модель предметной области.

Осторожно предположу, что прежде чем писать “стратегии”, хорошо бы вместе с командой определить-проговорить:

  • какие объекты и типы существуют в вашей системе тестирования? (система, модули, требования, риски, виды тестирования). И

  • почему вы их выделили именно так, а не иначе.

Без этой модели иерархия — просто “мёртвая/статичная форма” (“фотография”). С этой моделью — это “живая/подвижная структура” (“видеофильм”), которая направляет, что писать на каждом уровне.


2.

Адназначна!)) И на каждом уровне иерархии.

  • На стратегическом уровне — приводите конкретные типы объектов вашей системы (не «риски», а «риск некорректного расчета при делении на ноль», «риск потери данных при сбое БД»).

  • На процессном уровне — конкретные причинно-следственные связи (не «тестируем по требованиям», а «если требование описывает граничный случай, то применяем методику X; если требование описывает обычный случай, то методику Y»).

  • На операционном уровне — конкретные инструкции и примеры (чек-лист с номерами пунктов, тест-кейсы с данными и т.п. конкретика. Ваши сотрудники не желают дополнительной когнитивной нагрузки. Помогите им в этом).

Если на любом уровне Вы видите только общие фразы — это сигнал, что уровень недостаточно заземлён.


3.

Хм…))) Разница есть, и Вы её уже почувствовали.

С одной стороны, я считываю так: Ваша частная стратегия АС X максимально понятна команде — потому что она фактически написана как методика тестирования (операционный уровень). И, как я понял, это у Вас уже работает.

Но, с другой — Ваше общая стратегия непонятна — скорее всего, потому что в ней нет ни типов объектов, ни причинно-следственных связей, только общие слова (?).

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

Подумайте: м.б. Вам нужно переименовать вашу частную стратегию в “Методику тестирования АС X”? И, возможно, и она останется такой же понятной, но будет честнее по названию?

Как это можно проверить?
Я бы делал так: написал процессный уровень (причинно-следственные связи, почему для АС X применяется именно эта методика). Затем стратегический уровень (типы объектов, общие для всех систем).

Итого.

  1. Выделите модель предметной области (какие объекты вы различаете в тестировании).

  2. Заземляйтесь на каждом уровне конкретными примерами.

  3. Согласуйте модель с командой — чтобы все удерживали внимание на одних и тех же объектах. Прислушивайтесь к лексике Ваших сотрудников.

  4. Честно переименуйте документы: методика — методика, процесс — процесс, стратегия — стратегия…

Обязательно:

5. Не верьте ни единому моему слову.

Только эксперимент покажет Вам насколько полезны мои скромные рекомендации. Попробуйте на одной, не самой важной для Вас системе — и посмотрите, что изменится в Вашем понимании и понимании Вашей команды.

1 лайк

На посошок.

Моя триада ‘стратегический-процессный-операционный’ — рабочая модель в рамках топика. Возможно, Вы захотите пересмотреть описанный мной уровни, если обнаружите, что они не ловят важные различия.

Подумайте: мог быть, разница не в “уровнях”, а в ролях?

  • Кто читает Вашу общую стратегию?

  • Кто читает частную?

    • И ваще… может, общая стратегия адресована Вами для роли архитектора тестирования? А частная — для роли тестировщика конкретной системы?..

    • “Ролей всегда на одну больше”)))…

1 лайк

Стратегический уровень - это документ для тех, кто пишет частные методики для каждой системы. Им и решать, нужна ли она. Тем кто исполняет частные методики - стратегический уровень не нужен.

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

Про различение всех этих понятий много говорится в курсах системного мышления и методологии.

Вообще лучше бы сделать так, чтобы “стратегии”, “стратегическое”, “методы”, “методики” – всё это не путалось как термины.