На прошлой неделе я посетил Agile Testing Days 2015 (крупнейшее в Европе событие Agile Software Testing ) . Было много лекций о Исследовательском тестировании , но я обнаружил, что один из наиболее интересных был назван «Заметка о том, как делать заметки с помощью интеллектуальных 
карт». Там я услышал идею о документировании ваших тестовых журналов через карты разума .
Семинар оказался не таким практичным, как я ожидал. Это было больше о том, как использовать конкретный инструмент для создания интеллектуальных карт. Тем не менее, мне очень понравилась идея использовать карты разума для хранения моих тестовых записей, поэтому я попробовал это немедленно, когда вернулся из Германии.
В этой статье я поделюсь своим подходом к документированию исследовательского тестирования с использованием Mind Maps. Я также попробовал это на работе, и моим коллегам тоже понравилось.
Определение поисковых испытаний
Вот определение пробного тестирования для людей, которые не слышали об этом.
Поисковое тестирование — это подход к тестированию программного обеспечения,
который кратко описывается как одновременное обучение, разработка и выполнение теста.
Иногда такой подход может быть более мощным и увлекательным, чем тестирование по сценарию . Это зависит от навыков и предметных знаний тестера. Для дальнейшего объяснения можно провести сравнение свободного исследовательского тестирования в стиле фристайл с его тестированием на основе сценариев антитезиса . В последнем упражнении тестовые случаи разрабатываются заранее. Это включает как отдельные шаги, так и ожидаемые результаты. Эти тесты позже выполняются тестером, который сравнивает фактический результат с ожидаемым. При проведении поисковых испытаний ожидания открыты. Некоторые результаты могут быть предсказаны и ожидаемы; другие не могут. Документация по поисковым испытаниям варьируется от документирования всех проведенных испытаний до простого документирования ошибок .
Основными преимуществами исследовательского тестирования является то, что требуется меньше подготовки, быстро обнаруживаются критические ошибки, и во время выполнения этот подход, как правило, более интеллектуально стимулирует, чем выполнение тестов с использованием сценариев. Поисковые испытания особенно подходят, если требования и технические характеристики являются неполными или если не хватает времени.
По моему мнению, одним из самых больших недостатков является то, что предварительные испытания труднее документировать, чем другие подходы .
Журналы испытаний стиля блокнота
Я действительно считаю, что вести записи о том, что было проверено, — это правильный путь. Однако многие QA все еще не полностью согласны с этой идеей. В любом случае, вы можете проверить мой старый подход к документированию моих действий по тестированию в статье Be Better QA — начать создание тестовых журналов .
Вот пример журнала «Стиль блокнота» .
1. *NEW* /LIVE/ “Browser: Login with Gmail Chrome” (23-Sep-2013 09:44:20)
newUser@gmail.com
Client id = 123
https://mail.google.com/mail/u/0/#inbox
Login page displayed => OK
Previous account name displayed => OK
Login => OK
Logout Button available => OK
</OK>Там вы можете найти информацию о среде выполнения, дате, времени, тестовом примере, вводе тестов, выводе и сводке. Этот формат довольно нечитабелен, особенно для людей, которые не знакомы с синтаксисом. Кроме того, нет никаких встроенных ярлыков для облегчения использования заметок «Стиль блокнота» . Конечно, я создал несколько скриптов Autohotkey, чтобы облегчить процесс, но даже после этого его использование не является простым.
Разведочные испытания в стиле Mind Map
Для создания карты ума я использую бесплатную версию XMind 7 . Также есть веб-версия инструмента. Я думаю, что мысленные карты стиля по умолчанию не подходят для документирования исследовательского тестирования, потому что узлы вращаются повсюду. Тем не менее, я обнаружил, что шаблон на основе вертикальной шкалы времени (похожий на Facebook) был весьма полезен. Таким образом, каждый новый узел представляет новый тестовый пример. Обычно я не использую чисто предварительное тестирование — я проектирую большинство тестовых случаев высокого уровня заранее. В большинстве случаев нам нужны только заголовки тестовых случаев + контрольный список проверки + требования к функции .
Какую проблему я пытаюсь решить?
- После завершения тестирования я отправляю свои результаты и выполненные тестовые задания моим товарищам по команде, чтобы просмотреть их и предложить новые отсутствующие тесты, если таковые имеются. Однако, если формат тестовых журналов нечитабелен и сложен, они не будут его читать, или, если они это сделают, они не будут полностью понимать его.
- Когда мы загружаем некоторые из наших приложений в производство, нам необходимо хранить все журналы испытаний и результаты тестов в течение неограниченного времени в случае аудита. Протоколы испытаний должны быть понятны для аудиторов, иначе они не смогут их проверить, и после этого могут произойти плохие вещи.
Подготовьте Mind Map перед началом исследовательской сессии
Как я упоминал ранее, я обычно создаю все высокоуровневые тестовые случаи, о которых я могу подумать заранее. С документированием «Стиль карты разума» я создаю все контрольные примеры как разные узлы и сохраняю карту разума как новый шаблон.
Таким образом, я могу выполнить эту сессию несколько раз на случай, если мне нужно будет что-то повторно протестировать. После первого выполнения всех подготовленных тестов я обычно добавляю новые тесты во время сеанса (в этом весь смысл исследовательского тестирования). После завершения первого сеанса я добавляю вновь созданные тестовые примеры в шаблон по умолчанию.
Исследовательское тестирование документов с помощью Mind Maps
Как я уже упоминал ранее, я записываю всю информацию во время выполнения теста. Примеры включают дату, время, среду, браузер выполнения, тему сайта, входные данные и выходные данные.
Я вставляю дату и время в качестве метки текущего выполняемого узла Mind Map (текущий контрольный пример).
Another interesting thing that I set on the nodes is a URL if there is a particular URL for the test. Just mark the node and insert a new hyperlink, it can be later opened through the planet icon.
The final result of the test – pass, fail, inconclusive, more information needed is set using the built-in XMind’s markers.
All other kind of information is logged as subnodes of the executed test case’s node. If there is a bug, you can insert an image of it directly on the map. I also associate the URLs of the bugs (from the bug tracking system) with the currently executed node.
If one particular test case should be executed against multiple combinations of browsers and themes or something like that, you can easily create different nodes for this combinations.
You can find the final result below.
Another handy thing is that you can save your mind maps directly to Evernote (you don’t need the Pro version). After that, you can encrypt them if you want.
