Static - Reviews
Рецензирование (review): Оценка состояния продукта или проекта с целью установления расхождений с запланированными результатами и для выдвижения предложений по совершенствованию. Примерами рецензирования могут служить: управленческое рецензирование, неформальное рецензирование, технический анализ, инспекция и разбор. (ISTQB)
Неформальное рецензирование (informal review): Рецензирование, которое не основано на формальной (документированной) процедуре. (ISTQB)
Разбор (walkthrough): Пошаговый разбор, проводимый автором документа для сбора информации и обеспечения одинакового понимания содержания документа. (IEEE 1028)
Равноправный анализ (peer review): Рецензирование разрабатываемого программного продукта, проводящееся сотрудниками компании-разработчика с целью нахождения дефектов и внесение улучшений. Примерами рецензирования являются: инспекция, технический анализ и разбор. (ISTQB)
Инспекция (inspection): Тип равноправного анализа, основанный на визуальной проверке документов для поиска ошибок. Например, нарушение стандартов разработки и несоответствие документации более высокого уровня. Наиболее формальная методика рецензирования и поэтому всегда основывается на документированной процедуре. (IEEE 610, IEEE 1028). См. также равноправный анализ.
Методы статического тестирования делятся на две основные категории, одной из которых являются ревью. Ранжирование по уровню формальности:
https://www.tutorialspoint.com/software_testing_dictionary/images/peer_review.jpg
Экспертные обзоры (Peer Reviews): Рецензирование - это стандартизированный метод проверки правильности исходного кода при разработке программного обеспечения, который проводится для выявления дефектов на ранних этапах жизненного цикла и которые не могут быть обнаружены с помощью методов тестирования черного ящика.
Прохождение/просмотр/пошаговый разбор (walkthrough ): это метод проведения неформального группового / индивидуального просмотра. В walkthrough автор описывает и объясняет рабочий продукт на неформальной встрече своим коллегам или руководителю, чтобы получить обратную связь. Здесь проверяется применимость предложенного решения для рабочего продукта. Либо рабочий продукт проверяется на наличие дефектов несколькими лицами, кроме человека, который его фактически произвел;
Технический обзор (Technical Review): Это метод более высокого уровня по сравнению с inspection или walkthrough, поскольку он также включает в себя управление. Этот метод используется для оценки (assess and evaluate) продукта путем проверки его соответствия стандартам разработки, руководствам и спецификациям. У него нет определенного процесса, и большая часть работы выпо лняется модератором, как описано ниже:
- Модератор собирает и раздает материал и документацию всем членам команды;
- Модератор также готовит набор показателей для оценки продукта в соответствии со спецификациями и уже установленными стандартами и гайдлайнами:
- последовательность;
- документация;
- соблюдение стандартов;
- полнота;
- определение проблемы и требования (? problem definition and requirements);
- Результаты фиксируются в документе, который включает как дефекты, так и предлож ения;
- Наконец, устраняются дефекты и учитываются предложения по улучшению продукта;
Инспекция: Инспекция определяется как наиболее формальная, тщательная, глубокая групповая проверка, направленная на выявление проблем как можно ближе к их исходной точке. Процесс проверки выполняется на ранних этапах SDLC и применяется к определенной части продукта, такой как SRS, код, дизайн продукта. и т. д. Это включает в себя ручное изучение различных компонентов продукта на более ранних этапах. Инспекционная деятельность следует определенному процессу, и участники играют четко определенные роли. Инспекционная группа состоит из трех-восьми человек, которые играют роли модератора, автора, читателя, записывающего и инспектора. Например, разработчик может выступать в качестве инспектора во время проверки кода, в то время как представитель по обеспечению качества может действовать как исполнитель стандартов.
Software inspection process:
- Планирование встречи: на этом этапе основное внимание уделяется определению продукта, подлежащего инспекции, и цели этой инспекции. На этом этапе назначается модератор, который управляет всем процессом. Назначенный модерат ор проверяет, готов продукт к инспекции или нет. Модератор также выбирает инспекционную группу и назначает им их роли. Модератор также планирует инспекционную встречу и раздает необходимые материалы инспекционной группе;
- Обзор: на этом этапе инспекционной группе предоставляется вся справочная информация для инспекционного совещания. Автор, который является программистом или дизайнером, ответственным за разработку продукта, представляет свою логику и рассуждения о продукте, включая функции продукта, его предполагаемое назначение и подход или концепцию, использованные при его разработке. Удостоверяется, что каждый член инспекционной группы понял и знаком с задачами и целью инспекционного совещания, которое должно быть проведено;
- Индивидуальная подготовка участников: на этом этапе члены инспекционной группы индивидуально готовятся к инспекционной встрече, изучая материалы, предоставленные на более ранних этапах. Члены команды выявляют потенциальные ошибки или недочеты в продукте и записывают их в журнал. Журнал передается модератору. Затем модератор собирает все журналы, полученные от участников, и отправляет их автору. Инспектор - лицо, ответственное за проверку и выявление ошибок и несоответствий в документах или программах, проверяет продукт и записывает все обнаруженные в нем проблемы (как общие, так и специфические). Инспектор записывает проблемы или issues в журнал вместе со временем, затраченным на подготовку. Модератор просматривает логи, чтобы проверить, готова ли команда к инспекционной встрече или нет. Наконец, модератор отправляет автору все скомпилированные логи;
- Инспекционная встреча (Inspection Meeting): на этом этапе автор обсуждает вопросы, поднятые членами команды в скомпилированном журнале. Участники приходят к решению, является ли поднятый вопрос ошибкой или нет. Модератор завершает встречу и подводит итоги встречи - это список ошибок, обнаруженных в продукте, которые должен устранить автор.
- Переделка: доработка проводится автором согласно сводному списку, представленному модератором на предыдущем этапе. Автор исправляет все ошибки и сообщает модератору;
- Follow - up: модератор проверяет, все ли ошибки устранены или нет. Затем модератор готовит отчет. Если все ошибки исправлены и устранены, модератор выпускает документ. В противном случае в отчет добавляются нерешенные вопросы и назначается еще одно инспекционное собрание;
Источники:
Доп. материал: