CamStudio в руках тестировщика. Применение видеофайлов на этапе разработки и отладки ПО

 АННА СЕРГЕЕВА, старший инженер службы обеспечения качества Alloy Software Inc., annserge@rambler.ru

CamStudio в руках тестировщика
Применение видеофайлов на этапе разработки и отладки ПО

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

К слову о бережливом производстве

Есть два пути развития технологии:

• Первый – экстенсивный. Он характеризуется минимумом затрат, помноженным на максимум ручного труда. Но так или иначе неизбежны затраты на зарплату, компьютерный ресурс, длительность процесса.
• Второй – интенсивный. Здесь ручной труд сокращается за счет привлечения вспомогательных программных инструментов. Часть затрат идет на их приобретение, часть на повышение зарплаты более квалифицированным сотрудникам. Выигрыш такого подхода в сокращении числа ошибок и времени работы над проектом. Называется это «бережливое производство» (Lean Manufacturing) [1].

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

При этом автоматизация бывает разная:

• новостные корпоративные рассылки о запланированных мероприятиях и совещаниях;
• оповещение работников о назначенных задачах и сроках исполнения;
• составление автоматических отчетов о проделанной работе.

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

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

Взгляд изнутри

Достаточно много лет я занимаюсь тестированием и часто сталкиваюсь с такой ситуацией.

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

Далее тикет обрабатывается менеджерами проекта и передается в разработку программистам. Результаты исправлений попадают в новую сборку проекта, и менеджеры возвращают тикет в тестирование. В соответствии с планом работ, ориентируясь на описание тикета, а также на примечания программистов по исправлениям, тестировщик спокойно выполняет свою работу по проверке устранения дефекта.

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

А что же на практике?

С момента создания тикета проходит время – в зависимости от планирования проекта от пары дней до нескольких недель, а иногда и того дольше.

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

И программист просит тестировщика наглядно воспроизвести дефект еще раз, по шагам, показать, что и как тот делал, какие диалоги вызывал, какие кнопки нажимал и т.д.

Возможно, описание проблемы в тикете было несовершенным, или последовательность шагов описана не полностью, или в не достаточно доходчивой форме, или этот программист – новичок в данном проекте. Мало ли что.

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

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

Разумеется, это актуально не для всех дефектов поголовно, однако для описания наиболее проблемных из них и в целях экономии времени можно записать последовательность действий с программой, приводящих к ошибке, с помощью видеоролика. А затем при описании проблемы прикрепить его к создаваемому тикету.

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

Поясним, в чем тут дело.

Статью целиком читайте в журнале «Системный администратор», №3 за 2014 г. на страницах 60-64.

Комментарии могут оставлять только зарегистрированные пользователи