Любой маломальски опытный QA-инженер (или в простонародье тестировщик) сможет сходу назвать пяток различных видов тестов: удобство пользователя, дымовое, нагрузочное, регрессионное, конфигурационное, тестирование взаимодействия и т.д. Какие-то виды тестирования используются редко, например нагрузочное, почаще применяется тестирование удобства пользователя, о таких экзотических видах, как конфигурационное тестирование или тестирование взаимодействия, многие вообще слышали только в книгах Канера и Фолка «Тестирование программного обеспечения» и никогда не использовали в работе. Но есть вид тестирования, про который можно сказать совершенно четко: его делал каждый. Я говорю о регрессионном функциональном тестировании. Этот вид теста, пожалуй, является одним из наиболее важных, нудных и трудоемких.

Всю суть регрессионного функционального тестирования передает картинка:



Обычно для проведения регрессионного тестирования пишут тест-кейсы, в которых пошагово описывают последовательность действий для проверки той или иной функциональности. Но работать с тестовой документацией довольно сложно (само составление сценариев отнимает чертовски много времени), а в ситуации часто изменяющихся требований проводить регрессионный анализ по тест-кейсам и вовсе нецелесообразно. Прежде всего из-за того, что на их актуализирование может уходить до 50% от времени тестирования. Из-за этого качество регрессионного тестирования ухудшается: тест-кейсы перестают обновляться и через какое-то время (несколько релизов) у команды тестировщиков остается куча старых сценариев, которым место в корзине.

Разработчики ПО не понаслышке знакомы с тем, как часто меняются желания заказчика. В одной версии нужен простецкий калькулятор, чтоб 2 на 2 перемножать, а в другой уже требуется рабочая среда, которая будет считать интегралы по поверхности, решать диффуры и делить на 0. Как тестировать в агрессивной среде меняющихся требований? Об этом хотелось бы поговорить в данной статье.

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



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

Оптимальным инструментом, сочетающим в себе плюсы тест-кейсов и чек-листов, на мой взгляд, является MindMap (или альтернативное русское название интеллект-карта). Почему именно эта технология? Мозг плохо воспринимает информацию в виде текстов, списков и таблиц, намного естественнее и проще сознанию усваивать информацию, которая основана на ассоциациях, задействует иерархическое мышление, визуализирована. Вот, пример интеллект-карты



К плюсам интеллект-карт можно отнести:
• эффективное структурирование информации;
• возможность собрать всю необходимую информацию, относящуюся к проекту;
• охват всех взаимосвязей в проекте;
• видение единой картины проекта;
• возможность расстановки приоритетов.
Вообще этот инструмент удобен больше для специалистов по тестированию, но им могут пользоваться и аналитики, и менеджеры проектов и даже разработчики.

На вопрос «зачем MindMap аналитикам?» можно ответить так: отпадает необходимость писать подробные постановки задач для проектов с часто меняющимися требованиями. Достаточно поддерживать карту контроля актуальной, добавлять в нее новые ветки с описанием и удалять из карты функциональность, которая больше не используется. Аналитик сможет охватывать весь функционал разрабатываемого продукта. Отпадет необходимость заводить задачи и указывать все, что нужно проверить, так как актуальная MindMap будет содержать нововведения (поверьте, поддерживать MindMap легко). К тому же и аналитик, и менеджер проекта будут уверены в том, что все, что занесено в схему будет проверено (в противном случае можно дать этой картой по лбу тестировщику, если он не проверил какие-то пункты, а в них выявились ошибки).
Разработчики тоже извлекут из интеллект-карты пользу. Благодаря взаимосвязям на карте программист поймет, на каком уровне вложенности дерева ему нужно вносить изменения в код и на что это может повлиять.

Основные преимущества интеллект-карт получают QA-инженеры, а именно:
• удобная статистика: с MindMap можно сказать со уверенностью, какие именно компоненты продукта уже проверялись, а какие все еще нуждаются в проверке;
• надежность тестирования: можно очень долго тестировать приложение, но так и не убедиться в том, что проверено действительно все. Постоянно актуализированная MindMap, охватывающая весь функционал, позволит минимизировать риски по пропуску ошибок;
• полный охват картины тестирования: из постановок неясно какой процент требований реализован, какая информация неактуальна, что будет реализовано в будущем. Тестировщику, который знаком с проектом, проще войти в курс дела, не перечитывая постановки и задачи;
• иерархическая система интеллект-карты удобна своей наглядностью. Правка кода, соответствующего одной ветки наглядно показывает каких дочерних веток коснутся изменения – их и нужно будет проверять в первую очередь.

Ранее на Хабре в статье «В чем нарисовать MindMap? Детальный обзор 6 самых популярных программ для рисования mindmap» были описаны наиболее популярные утилиты для построения интеллект-карт. На мой взгляд самой удобной является Xmind. Даже бесплатная версия обладает хорошим набором компонент для построения удобной интеллект-карты. Ниже будет приведен краткий обзор функций, которые были использованы мною в работе.

Заметки
Чтобы описать какой-нибудь пункт плана в Xmind можно использовать систему заметок. Добавление заметок бывает удобно для хранения «паролей и явок», списка действий для проверки нужного пункта (не путать с тест-кейсом). Ниже приведен пример использования заметок.



Изображения
Функционал добавления фотографии к пункту интеллект-карты удобен в тех случаях, когда нужно визуализировать изменения в конкретной области. Например, изменение логотипа с одного на другой (изображение нового лого целесообразно прикрепить к пункту карты). Пример того как выглядит вложенное в пункт плана изображение ниже.



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



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



Ведение версионности
Чтобы идентифицировать новую функциональность на интеллект-карте, целесообразно указать версионность. Т.е. добавить пункт карты (по сути являющийся функционалом) и указать версию ПО, куда вошел данный функционал. При проверке новых фич сделать фильтр по «версии», и на карте будут подсвечены только те пункты, которые относятся к выбранной версии.



И напоследок, на вопрос «как организовать процедуру актуализации интеллект-карты и построить работу по проведению тестирования?» я бы ответил так. На первых порах, пока проект еще не велик, аналитик совместно со специалистом по тестированию создают первую простенькую интеллект-карту. Далее, перед выпуском нового релиза с новым функционалом, аналитик актуализирует интеллект-карту, проставляет на ней версию и передает в тестирование. Тестировщик выполняет свою работу, отмечает выполненные, невыполненные, проваленные пункты, отмечает время и прогресс выполнения – таким образом получает отчет о тестировании, который может передать руководителю подразделения или проекта.

В новом релизе аналитик вновь актуализирует интеллект-карту и передает копию в тестирование и все повторяется по указанной выше схеме. А если выгрузить MindMap в Excel, то можно получить удобный отчет о тестировании, который не стыдно показать заказчику.