 |
|
|
|
CamStudio в руках тестировщика. Применение видеофайлов на этапе разработки и отладки ПО
CamStudio в руках тестировщика Предлагается улучшение менеджмента ИТ-проекта: на этапе разработки и отладки ПО документацию о прохождении тестирования сохранять в форме видеоматериалов. Это будет полезно программистам при фиксировании ошибок, обнаруженных тестировщиками, и для создания презентаций и видеоинструкций К слову о бережливом производстве Есть два пути развития технологии:
В «правильных» ИТ-компаниях, разрабатывающих программное обеспечение, руководство сосредотачивает силы на том, чтобы на выходе получить продукцию наиболее высокого качества, насколько это возможно и целесообразно, с наименьшими затратами времени, финансов и труда наемных работников. Поэтому автоматизации процессов производства уделяется все больше внимания. При этом автоматизация бывает разная:
Разумеется, затрагиваются и сами процессы выполнения рабочих задач программистов, технических писателей, тестировщиков, релиз-инженеров и далее по списку. Все это призвано не только повысить качество готового программного продукта, но и в значительной мере облегчить ежедневный труд команды специалистов, а также улучшить их взаимодействие. Однако практика зачастую имеет тенденцию расходиться с теорией. Взгляд изнутри Достаточно много лет я занимаюсь тестированием и часто сталкиваюсь с такой ситуацией. Тестировщик в ходе своей работы находит тот или иной дефект в исследуемой программе. Добавляет в багтрекер новый тикет, где детально описывает проблему, настройки и шаги по воспроизведению, при необходимости снабжая тикет поясняющими скриншотами. Далее тикет обрабатывается менеджерами проекта и передается в разработку программистам. Результаты исправлений попадают в новую сборку проекта, и менеджеры возвращают тикет в тестирование. В соответствии с планом работ, ориентируясь на описание тикета, а также на примечания программистов по исправлениям, тестировщик спокойно выполняет свою работу по проверке устранения дефекта. Теоретически до этого момента от тестировщика никаких действий по данной конкретной проблеме не требуется. В ожидании устранения дефекта он благополучно о нем забывает и переключается на решение совершенно других задач. А что же на практике? С момента создания тикета проходит время – в зависимости от планирования проекта от пары дней до нескольких недель, а иногда и того дольше. Тестировщик уже давно сосредоточенно трудится над очередной задачей или расслабленно отдыхает от выполнения своего титанического самоотверженного труда, и тут... И тут к нему приходит программист, которого менеджер проекта щедро назначил добровольцем по устранению того самого дефекта, о котором у нас велась речь ранее. И программист просит тестировщика наглядно воспроизвести дефект еще раз, по шагам, показать, что и как тот делал, какие диалоги вызывал, какие кнопки нажимал и т.д. Возможно, описание проблемы в тикете было несовершенным, или последовательность шагов описана не полностью, или в не достаточно доходчивой форме, или этот программист – новичок в данном проекте. Мало ли что. Вот и получается, что тестировщик вынужден терять кучу времени, приостановив решение той задачи, над которой он в настоящий момент трудится, вспомнить и понять, о чем конкретно его просит программист. Ну и воспроизвести, разумеется... Частично этих проволочек можно избежать, если к тикету добавить скриншот с ошибкой, снабдив его поясняющими надписями и выделив проблемный блок. Или если максимально формализовано описать шаги по воспроизведению. Но случается, что первого бывает недостаточно, второе же отнимает неоправданно много сил и времени. Разумеется, это актуально не для всех дефектов поголовно, однако для описания наиболее проблемных из них и в целях экономии времени можно записать последовательность действий с программой, приводящих к ошибке, с помощью видеоролика. А затем при описании проблемы прикрепить его к создаваемому тикету. Это помогает программистам понять суть ошибки, заменяет печать текста на полстраницы и сокращает время работы, избавляет от необходимости бегать за разъяснениями, а тестировщикам не придется лишний раз отвлекаться от текущих дел. И вот именно здесь возникает переломный момент. Ибо, имея такую технологию, можно шагнуть гораздо дальше. Перейти на качественно новый уровень работы над всем проектом. Поясним, в чем тут дело. Статью целиком читайте в журнале «Системный администратор», №3 за 2014 г. на страницах 60-64. |
АННА СЕРГЕЕВА, старший инженер службы обеспечения качества Alloy Software Inc., Комментарии отсутствуют
| Добавить комментарий |
|
Комментарии могут оставлять только зарегистрированные пользователи |
|
