Содержание
- Что такое анализ воздействия?
- Когда следует проводить анализ воздействия?
- Зачем вам нужно проводить анализ воздействия?
- Как мне провести анализ воздействия?
- 1. Изучите проблему\тикет\ошибку\запрос на изменение *
- 2. Чтение электронной почты**
- 3. Общение с разработчиками**
- 4. Изучаем место внесения изменений***
- 5. Изучаем описание изменений***
- 6. Изучение кода изменения *****
- Почему я решил об этом написать?
Что такое анализ воздействия?
Прежде всего, Impact Analysis — это исследование, которое позволяет выявить затронутые области в проекте при разработке нового или изменении старого функционала, а также определить, насколько существенно они были затронуты.Затронутые области требуют большего внимания во время регрессионного тестирования.
Сразу отмечу, чтобы не пугать QA: анализ воздействия — это не «чтение кода».
Сюда входят и другие методы исследования.
Когда следует проводить анализ воздействия?
Анализ воздействия может быть полезен в следующих случаях:- есть изменения в требованиях;
- поступил запрос на внесение изменений в продукт;
- ожидается, что новый модуль или функциональность будут внедрены в существующий продукт;
- всякий раз, когда происходят изменения в существующих модулях или функциях продукта.
Изменение строчки кода в таком проекте может «сломать» абсолютно всё.
Разработчики исправляют производственную проблему
Зачем вам нужно проводить анализ воздействия?
Информация о взаимосвязи и взаимном влиянии изменений может помочь QA:- сосредоточьтесь на тестировании функциональности, в которую были внесены изменения;
- принять во внимание части проекта, которые были затронуты изменениями и могли пострадать;
- не тратьте время на тестирование тех частей проекта, которые не были затронуты изменениями.
Как мне провести анализ воздействия?
- Я изучаю проблему\тикет\ошибку\запрос на изменение *.
- Я читаю электронную переписку**.
- Я говорю с разработчиками**.
- Смотрю на место, где было изменение (место фиксации)***.
- Смотрю описание коммита ***.
- Я смотрю на изменения в коде *****.
Как видите, только «шаг 6» требует умения читать код; QA может справиться с «шагами 1–5» даже без знания языка программирования.
1. Изучите проблему\тикет\ошибку\запрос на изменение *
Самое элементарное и элементарное (отсюда и сложность*) — внимательно изучить вопрос в системе отслеживания ошибок.Вам следует обратить внимание на все поля, особенно:
- Шаги для повторения;
- Описание;
- Дополнительная справочная информация;
- Вложение;
Например, внимательно прочитав статью, вы обнаружили, что в разделе «Дополнительная справочная информация» есть пометка о том, что проблема воспроизводится только при использовании HTTPs. Поэтому можете отметить для себя, что при тестировании неплохо было бы проверить случай с HTTP.
2. Чтение электронной почты
Вы удивитесь, сколько всего можно найти в переписке, связанной с вашей задачей, которая была пропущена и не указана в выдаче:- более подробная информация от клиентов;
- результаты исследований других членов команды;
- список подобных проблем;
- изображения, графики, диаграммы и многое другое.
Почему об этом не упомянули в выпуске?!
3. Общение с разработчиками**
Контроль качества и разработчики При тестировании изменений ваша цель — найти как можно больше вещей, которые «сломанны», и поэтому вам следует смело подходить к разработчикам, тем, «кто их мог сломать», и напрямую спрашивать: «Вы внесли изменения, скажите мне, что они могут повлиять на то, какие области/модули мне нужно проверить более тщательно.
" Хороший разработчик, который понимает, что чем раньше будет обнаружена ошибка, тем дешевле будет ее исправить, поможет вам советом, даже если он абсолютно уверен в своих изменениях.
4. Изучаем место внесения изменений***
Внесенные изменения должны быть где-то сделаны.В моем случае это git, где довольно легко определить место внесения изменений.
Под «местом» я подразумеваю «конкретный файл, конкретную функцию\метод, конкретный модуль».
И поэтому это «место» (этот модуль, функционал) надо перепроверить, протестировать на регрессии.
Файл, в котором находятся изменения Например, на рисунке выше вы можете видеть, что изменения коснулись функциональности «ExtendedClassification», поэтому необходимо пройти как минимум Smoke Test для этой функциональности.
Также если в каких-то клиентских файлах (JS, HTML, CSS и т.д.) были изменения, то следует провести кроссбраузерное тестирование.
Сложность «***» — читать код по-прежнему не требуется, но нужно иметь представление об архитектуре проекта.
5. Изучаем описание изменений***
Чтобы QA мог изучать описания, нам в первую очередь нужно добиться того, чтобы Разработчики начали писать грамотные и понятные описания изменений.В моем отделе мы следуем следующему шаблону описания git-коммитов:
Номер и название билета - Ошибка: {В чем заключается дефект, каково реальное поведение системы?} - Проблема : {основная причина неисправности, что некорректно работает в системе?} - Исправить: {какое изменение}
Описание изменений Например, исходя из описания исходной проблемы «Логика не работает при версионировании корневого ItemType» (изображение выше), следует, что нужно проверить «эту логику при версионировании корневого ItemType».
А поскольку доступен только сам баг и его описание, эта важная проверка не так очевидна и ее можно пропустить.
6. Изучение кода изменения *****
Здесь все банально просто — нужно прочитать код и представить, что он делает. Конечно, на данном этапе это могут сделать не многие, но есть к чему стремиться.Кроме того, QA не требует глубокого понимания кода.
Базовых знаний программирования и поверхностных знаний ООП (в моем случае) вполне достаточно, чтобы представить себе вариант использования, охватывающий основные функции этого кода.
Почему я решил об этом написать?
Недавно отдел столкнулся с тем, что разработчик внес некоторые изменения и отправил его на QA-тестирование.Тестировщик, естественно, решил провести регрессионное тестирование, но без особого анализа и исследований определил, что необходимо провести все регрессионные тесты, что в общей сложности заняло 25 часов (проверка доступа, тестирование разного функционала, тестирование в разных браузерах).
Когда я решил посмотреть на внесенные изменения, то обнаружил следующее: 
Пример те.
единственное изменение, которое было сделано, это добавление проверки, если ItemType не равен "HG_Modification Orger", то делаем то же самое, что и раньше (вносим изменения и обновляем окно), если ItemType равен "HG_Modification Orger", затем пропустите (ничего не делайте и просто обновите окно).
Те.
эти изменения никак не затрагивают клиентскую часть (проверка в разных браузерах не нужна).
Изменения никак не влияют на доступ или рендеринг.
Они влияют только на определенные функции, которые необходимо проверить для ItemType = «HG_Modification Orger» и для ItenType != «HG_Modification Orger».
В худшем случае эти проверки займут 30 минут. Но не 25 часов.
Это наглядный пример того, как анализ воздействия помог значительно сократить время, необходимое для проведения необходимого тестирования.
Теги: #qa #тестирование #тестирование веб-сервисов #тестирование ИТ-систем #тестирование с использованием #тестирование #анализ воздействия #фиксация #анализ #регрессионное тестирование #анализ воздействия
-
Фильтр Введенных Во Вход Символов
19 Oct, 24 -
Как Вы Узнали О Хабре?
19 Oct, 24
