Пока нет оценок.
Пожалуйста, подождите...

Итак, анализ изменений (англ. Impact Analysis) – это своеобразное исследование, с помощью которого можно указать наиболее часто затрагиваемые места на проекте при создании новой или изменении текущей функциональности, а также понять, насколько значительно они были затронуты.

Подобные затронутые области требуют существенного внимания при проведении всем известного регрессионного тестирования.

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

Данный анализ будет наиболее полезным в таких ситуациях:

  1. Когда на проекте есть изменения в требованиях;
  2. Есть запрос на внесение некоторых изменений в ПО;
  3. Ожидание внедрения нового модуля или функциональностей в уже существующее ПО;
  4. Постоянно, когда существуют изменения в текущих модулях или функциональности ПО.

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

Почему необходимо проводить анализ изменений?

Данные о взаимосвязи изменений могут помочь тестировщику:

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

Как правильно проводить анализ изменений (наглядный пример)?

  1. Изучение проблемы /бага/запроса изменения/тикета;
  2. Ознакомление с перепиской клиента и отдела менеджмента;
  3. Диалог с отделом разработки;
  4. Ознакомление с частью функциональности, где было внесено изменение;
  5. Анализ внесенного изменения;
  6. Анализ изменения внутри программного кода.

Разберем каждый пункт по-отдельности.

Изучение проблемы /бага/запроса изменения/тикета

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

  1. Шаги воспроизведения;
  2. Описание;
  3. Дополнительная информация;
  4. Прикрепленные файлы.

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

Ознакомление с перепиской клиента и отдела менеджмента

Порой много чего интересного можно отыскать в личных переписках клиента и отдела менеджмента:

  • Множество уточнений и указаний от пользователей;
  • Итоги исследований от других участников процесса создания и тестирования ПО;
  • Перечень схожих проблем;
  • Документы и прочие файлы.

Сложность данного пункта состоит в том, что подобная переписка может содержать минимум технических терминов, и в большинстве своем быть наполнена сленгом.

Диалог с отделом разработки

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

Ознакомление с частью функциональности, где было внесено изменение

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

Анализ внесенного изменения

Чтобы QA могли правильно интерпретировать описания багов, нужно для начала добиться того, чтобы разработчики создавали грамотные и корректные описания всех изменений.

Анализ изменения внутри программного кода

С этим пунктом все просто и понятно. Тестировщик должен уметь «читать» программный код и понимать за что конкретно он отвечает. Естественно, что не все QA могут с этим полноценно справиться, но есть конкретный путь, к которому нужно стремиться. Тестеру достаточно базовых знаний основ программирования и некоторых самых простых понятий ООП.

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

Оставить комментарий