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

Как возникла таска

Проводят ли тестировщики демонстрацию программного продукта? (Отвечать не буду. Но оставлю этот вопрос на обсуждение читателям).

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

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

«Айтишник – не айтишник, если не загуглит планы и/или примеры». Из результатов поиска по веб-сайтам ничего толкового найти не удалось. Находились планы демонстрации по продажам различных товаров.

Этапы разработки программного продукта

Я изучила пример плана демонстрации, проанализировала бизнес-процесс программного продукта. Определила прямой вектор функциональности. И начала создавать свой шаблон демонстрации. После наполнять его информацией о функциональной части программного продукта.

Составила таблицы:

1. Повестка

2. Демонстрация ключевого функционала модуля от команды разработки

3. Сессия вопросов

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

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

Потыкав экземпляр заказчика, пошла обрисовывать функционал в созданных таблицах.

Готовый сценарий?

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

Такая программа демо не подойдет!

«Всё ерунда! Давай по новой»

Удаляю первую версия плана демо. И начинаю заново составлять искать тот шаблон, который мне нужен. Попадаются мне все те же примеры по продажам. Ищу дальше. Наткнулась на сайт, на котором был представлен какой-то документ с большим количеством страниц. Изучаю его подробнее… Наконец-то! Это именно то, что я искала. Из огромного документа нахожу блок текста плана демонстрации. Этот сайт дал мне хорошую основу для разработки сценария (хотя сайт является правительственным). Беру на вооружение описание в тексте и составляю новую таблицу:

Теперь такая таблица мне нравится больше.

Готовый сценарий v.2?

Да! Программа демонстрации готова. Отправляю её руководителю проекта на проверку. У него вопросов не возникло. А вот теперь второй этап утверждения – это заказчик. Который отлично знает свой программный продукт. Пришли мелкие замечания, но в основном к функциональным этапам. Исправляю. Отправляю проектному менеджеру. Руководитель отправляет заказчику. Заказчик утвердил. Готово!

А демонстрация прошла успешно?

Наступает день икс. Тревожность подло подступает к назначенному времени (даже сейчас, описывая свои ощущения, ловлю мандраж). Команда разработчиков спокойно заваривают себе чай перед представлением, усаживаются поудобнее, отключают микрофоны и приступают к просмотру моими танцами (*легкая зависть*).

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

Итог: демонстрация прошла хорошо. Эмоции облегченности были на пике. Потом уже отдельно с командой разработки созваниваемся и рассказываем свои впечатления. Меня разработчики хвалят. Но архитектор ПО попросил созвониться…

Фидбэк демонстрации

Я благодарна архитектору, которые сказал мне о моих ошибках. Если план уже утвержден, то нужно четко следовать ему. И ни в коем случае не давать заказчикам менять этапы демонстрации по время демо.

Этот фидбэк помог мне провести следующую демонстрацию второй части ПО. Здесь я уже чувствовала себя увереннее. А при попытке заказчика увести меня в сторону, просила задать вопросы в конце демо.

И теперь задам снова тот же вопрос из начала статьи: проводят ли тестировщики демонстрацию программного продукта?