Итак, анализ изменений (англ. Impact Analysis) – это своеобразное исследование, с помощью которого можно указать наиболее часто затрагиваемые места на проекте при создании новой или изменении текущей функциональности, а также понять, насколько значительно они были затронуты.
Подобные затронутые области требуют существенного внимания при проведении всем известного регрессионного тестирования.
Когда возникает актуальность проведения анализа изменений?
Данный анализ будет наиболее полезным в таких ситуациях:
- Когда на проекте есть изменения в требованиях;
- Есть запрос на внесение некоторых изменений в ПО;
- Ожидание внедрения нового модуля или функциональностей в уже существующее ПО;
- Постоянно, когда существуют изменения в текущих модулях или функциональности ПО.
В сегодняшних реалиях IT-сообществ тенденции таковы, что ПО становится более комплексным и большим, а его компоненты так или иначе связаны между собой. Изменение одной строки программного кода может вывести из строя абсолютно все.
Почему необходимо проводить анализ изменений?
Данные о взаимосвязи изменений могут помочь тестировщику:
- Полноценно сконцентрироваться на проверке функциональности, где изменения были выполнены;
- Не тестировать те составные элементы проектов, которые не были затронуты изменениями;
- Обратить внимание на те функциональные части ПО, где были изменения и которые, возможно, требуют исправлений.
Как правильно проводить анализ изменений (наглядный пример)?
- Изучение проблемы /бага/запроса изменения/тикета;
- Ознакомление с перепиской клиента и отдела менеджмента;
- Диалог с отделом разработки;
- Ознакомление с частью функциональности, где было внесено изменение;
- Анализ внесенного изменения;
- Анализ изменения внутри программного кода.
Разберем каждый пункт по-отдельности.
Изучение проблемы /бага/запроса изменения/тикета
Самое главное и важное, что требуется сделать в первую очередь, – это изучить историю внесения и исправления дефекта в системе отслеживания ошибок. Обязательно нужно быть внимательными при изучении следующих полей:
- Шаги воспроизведения;
- Описание;
- Дополнительная информация;
- Прикрепленные файлы.
Несколько важных условий или особенностей, которые могут содержаться в issue, помогают QA идентифицировать сферу будущего тестирования.
Ознакомление с перепиской клиента и отдела менеджмента
Порой много чего интересного можно отыскать в личных переписках клиента и отдела менеджмента:
- Множество уточнений и указаний от пользователей;
- Итоги исследований от других участников процесса создания и тестирования ПО;
- Перечень схожих проблем;
- Документы и прочие файлы.
Сложность данного пункта состоит в том, что подобная переписка может содержать минимум технических терминов, и в большинстве своем быть наполнена сленгом.
Диалог с отделом разработки
При тестировании изменений базовая цель отдела компании по обеспечению качества – найти как можно больше багов, а значит, диалог с разработчиками должен строиться на взаимовыгодных началах. Можно смело спрашивать, где конкретно были изменения и на что нужно обратить больше внимания. Хороший разработчик понимает, что чем раньше дефект найден, тем дешевле будет его починить.
Ознакомление с частью функциональности, где было внесено изменение
Изменения, которые были выполнены, должны где-то храниться. Такое «место» может обозначать определенный документ, метод, функцию или конкретный модуль функциональности. А значит, его нужно перепроверять на наличие возможной регрессии.
Анализ внесенного изменения
Чтобы QA могли правильно интерпретировать описания багов, нужно для начала добиться того, чтобы разработчики создавали грамотные и корректные описания всех изменений.
Анализ изменения внутри программного кода
С этим пунктом все просто и понятно. Тестировщик должен уметь «читать» программный код и понимать за что конкретно он отвечает. Естественно, что не все QA могут с этим полноценно справиться, но есть конкретный путь, к которому нужно стремиться. Тестеру достаточно базовых знаний основ программирования и некоторых самых простых понятий ООП.
Таким образом, правильно проведенный анализ изменений может значительно уменьшить время, необходимое для проведения тестирования. Ведь если вы знаете, где именно произошли изменения в веб-продукте, вам не придется тратить массу времени, заново проверяя весь продукт.
Оставить комментарий