Я поискал в тексте этой заметки слова, которые вы используете в своём комментарии: «обман», «запугивание» и «принуждение» и тоже не нашёл их. Вероятно, это потому, что речь вовсе и не шла об этих понятиях.
1. В комментариях к каждой ветке описываю список багов со ссылкой на баг-трекер (в формате номер бага — заголовок).
2. По элементу ветки ставлю прогресс тестирования (спец иконка с заполнением содержимого по клику). Так с лету определяю, на каком этапе процесс.
3. В особо сложных местах ставлю на элементах ветки номера приоритетов для тестирования (1-супер важно,… 4-не важно).
4. Использую перекрестные ссылки на другие ветки (связи одних элементов с другими, если те идут не от родительского) — так проще понять логические связи, если они децентрализованы.
5. Использую смайлы и палец вверх/вниз, чтобы визуально определить, куда направить свое внимание.
6. Ввел для себя термин bpo (bug per option) в виде числа, чтобы охватив взглядом карту я мог понять концентрацию багов в тех или иных местах.
И многое другое :) Это универсальная система, в том числе для учета багов, оценки прогресса тестирования по всем фронтам, оценки концентрации багов, контроля внесенных в ПО изменений и всё такое. наверное такие вещи лучше живьем показывать.
Когда то я пришел к именно такому выводу: делать mind map вместо бесконечной писанины. Проект у нас большой, документации получилось бы выше крыши, а в тест отделе только я :) Именно майнд мап как метод спасла мне всю работу в тестировании. И как вы правильно заметили — создавать всю долго, а отдельные элементы на раз-два. Пара минут и у тебя готовый кейс и его легче воспринять визуально. Есть еще несколько фишек, с помощью которых можно круто прокачать карту (но это наверное уже не сюда). Так что я вас полностью поддерживаю.
2. По элементу ветки ставлю прогресс тестирования (спец иконка с заполнением содержимого по клику). Так с лету определяю, на каком этапе процесс.
3. В особо сложных местах ставлю на элементах ветки номера приоритетов для тестирования (1-супер важно,… 4-не важно).
4. Использую перекрестные ссылки на другие ветки (связи одних элементов с другими, если те идут не от родительского) — так проще понять логические связи, если они децентрализованы.
5. Использую смайлы и палец вверх/вниз, чтобы визуально определить, куда направить свое внимание.
6. Ввел для себя термин bpo (bug per option) в виде числа, чтобы охватив взглядом карту я мог понять концентрацию багов в тех или иных местах.
И многое другое :) Это универсальная система, в том числе для учета багов, оценки прогресса тестирования по всем фронтам, оценки концентрации багов, контроля внесенных в ПО изменений и всё такое. наверное такие вещи лучше живьем показывать.