CamStudio в руках тестировщика. Применение видеофайлов на этапе разработки и отладки ПО::Журнал СА 3.2014
www.samag.ru
Льготная подписка для студентов      
Поиск   
              
 www.samag.ru    Web  0 товаров , сумма 0 руб.
E-mail
Пароль  
 Запомнить меня
Регистрация | Забыли пароль?
О журнале
Журнал «БИТ»
Наука и технологии
Подписка
Где купить
Авторам
Рекламодателям
Магазин
Архив номеров
Вакансии
Контакты
   

Jobsora


  Опросы

Какие курсы вы бы выбрали для себя?  

Очные
Онлайновые
Платные
Бесплатные
Я и так все знаю

 Читать далее...

  Статьи

Вектор роста  

Особенности сертификаций по этичному хакингу

В современном мире информационных технологий знания о них настолько широки и многообразны,

 Читать далее...

1001 и 1 книга  
04.12.2019г.
Просмотров: 70
Комментарии: 0
Особенности сертификаций по этичному хакингу

 Читать далее...

28.05.2019г.
Просмотров: 2580
Комментарии: 2
Анализ вредоносных программ

 Читать далее...

28.05.2019г.
Просмотров: 2587
Комментарии: 1
Микросервисы и контейнеры Docker

 Читать далее...

28.05.2019г.
Просмотров: 2087
Комментарии: 0
Django 2 в примерах

 Читать далее...

28.05.2019г.
Просмотров: 1648
Комментарии: 0
Введение в анализ алгоритмов

 Читать далее...

Друзья сайта  

Форум системных администраторов  

sysadmins.ru

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

Архив номеров / 2014 / Выпуск №3 (136) / CamStudio в руках тестировщика. Применение видеофайлов на этапе разработки и отладки ПО

Рубрика: Разработка /  Тестирование

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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


Комментарии отсутствуют

Добавить комментарий

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

               Copyright © Системный администратор

Яндекс.Метрика
Tel.: (499) 277-12-41
Fax: (499) 277-12-45
E-mail: sa@samag.ru