Типы ревью

Lecture 04
5/2/2016 3:23:00 PM
Статическое тестирование
В этой лекции мы рассмотрим важную область тестирования – «технику статического тестирования». Статическое
тестирование подразумивает тестирование без исполнения кода/запуска приложения.
Несмотря на то что программа не проверяется в привычном нам понимании через проверку функциональности на
рабочем компоненте/продукте Статическое тестирование очень важно, потому что позволяет выявить ошибки до
выполнения кода, в более раних стадиях проекта делая исправление ошибок проще и дешевле, чем если бы ошибка
была выявлена во время тестирования самой программы.
Статическое тестирование нацелено на тестирование requirements и specifications, на проверку кода без его запуска.
Проверка requirements и specifications называется Review (ревью).
Проверка кода без его запуска – Static analysis (статический анализ).
 КАКАЯ ЦЕЛЬ ПРОВЕДЕНИЯ REVIEW (ДОКУМЕНТОВ И КОДА) ДО НЕПОСРЕДСТВЕНО ТЕСТИРОВАНИЯ?
Review
Review – это систематическое изучение документов одним или большим колчеством людей с основной целью - выявить
и устранить ошибки.
Review может быть применено к любому документу - requirements и specifications, описание дизайна системы, код, тест
планы или тест кейсы.
Review – первое тестирование, которому подвергается продукт и оно может проходить ещё до стадии разработки
программы, т.к. документация как правило анализируется задолго до того как пишется первый код.
Подход по анализу specifications и requirements на первом этапе разработки позволяет выявить ошибки до того как они
станут частью исполняемого кода. Если баг выявленый на стадии Review был бы обнаружен на стадии
разработки/тестирования, то это привело бы к дополнительным денежным и временым затратам по выявлению бага,
поиску первопричин, анализу кода и т.п.
Помимо анализа спецификаций проводится просмотр кода на соотвествие принятым стандартам, что также может
привести к сокращению ошибок появляющихся во время тестирования.
 КАКОВЫ ПОЛОЖИТЕЛЬНЫЕ СЛЕДСТВИЯ REVIEW ДОКУМЕНТАЦИИ?
Помимо самых очевидных приемуществ просмотра документации - сокращение расходов и количества ошибок в
продукте – есть другие приемущества Review:
 Скорость разработки кода может быть улучшена благодаря выявлению ошибок на уровне документации.
Review позволяет убедиться, что спецификации понятны и чётки, что в свою очередь позволяет девелоперу
быстрее выполнять непосредствено разработку/написание кода.
 Затраты на тестирование могут бы сокращены благодаря сокращению вероятности появления blocking bugs, в
случае которых тестер вынужден ждать исправления со стороны разработчика прежде чем продолжить работу.
 Во время ревью осуществляется разбор документов, что улучшает понимание содержимого ещё до начала
разработки.
Более всего во время Review выявляются ошибки следующего плана:
 Отклонение от стандартов определённых в команде или принятых в компании
 Ошибки в requirements. Например, не описаны какие-то элементы программы.
 Выявление ошибок в архитектуре продукта. Например, интерфейс принимающего и отправляющего
компонента программы не совпадает.
Каждое Review нацелено на выявление ошибок в документах, но надо понимать, что разные подход к ревью выявляет
специфичные для подхода ошибки.
Процесс Review
1
5/2/2016 3:23:00 PM
Lecture 04
Процесс Review может широко отличаться в зависимости от уровня формальности, где под формальностью
подразумивается уровень документированости процесса и подход к организации процесса.
Одни типы review абсолютно «неформальны», другие же наоборот очень. На примерах будет яснее.
Базовый процесс review
Оба типа ревью – неформальный и формальный – включают в себя следующие базовые элементы:
 Документ изучается участниками процесса
 Участники выявляют ошибки или проблемы и объясняют их автору документа в устной форме или в виде
документа (например, пометки в рассмариваемом документе или занесение багов)
 Автор принимает решение об обновлении/исправление документа, основываясь на полученых репортах
(устных или письменных)
Формальное ревью
Kick-off
Planning
Individual
preparation
Follow-up
Review
meeting
Rework
Planning (планирование)
 Выбор персонала (selecting personnel) – то есть определение людей, полезных для процесса. Нет смысла
выбирать людей, которые будут согласны с каждым пунктом в рассматриваемом документе. Как правило в
ревью вовлекаются люди из разных отделов организации. Соотвествено один и тот же документ будет
рассмотрен под разными углами.
 Назначение ролей (allocating roles) – каждому участнику даётся определённая роль, чтобы обозначить угол под
которым будет рассмотрен документ. Тестер может подходить к ревью с точки зрения возможностей
тестирования, другой участник может анализировать документ в свете простоты использования.
 Определение входного и выходного критерия процесса ревью.
 Определение частей документов необходимых для ревью. Зависит от размера документа.
Kick-off (начало)
На этой стадии выдаются документы, предназначеные для ревью, объясняются цели, процесс. Kick-off может
быть проведен ввиде митинга или через простую рассылку информации по почте – метод будет зависить от временых
рамок и объёма информации, которую необходимо передать.
Individual preparation (индивидуальная подготовка)
2
Lecture 04
5/2/2016 3:23:00 PM
Работа с документом проделываемая каждым участником самостоятельно. Необходимо прочтение документа,
выявление потенциальных ошибок, вопросов и комментариев.
Review meeting
На этом шаге проводиться обсуждение выявленых ошибок и документирование их. Также обсуждаются
рекомендации по исправлению ошибок. Подход (то есть детальное документирование ошибок или ограничение
письмеными замечаниями) определяется исходя из
 Доступного времени
 Требованиями автора документа
Rework
После review митинга у автора документа будет ряд ошибок для исправления. Rework – исправление выявленых
ошибок.
Follow-up
Производится замер количества выявленых ошибок и сколько времени было затрачено на ревью.
Рассматривается также совпадение с выходным критерием.
Роли и области отвественности
Manager
Определяет что будет проревьюено, определяет необходимое время и определяет если цели ревью были достигнуты.
Managers обычно не вовлекаются в сам процесс ревью.
Moderator
Также называется “review leader”.
В задачи модератора входит планирование и организация ревью, проведение самого ревью и занятиями задачами из
Follow up.
Author
Автор – создатель документа или человек отвечающий за создание документа. Автор также занимается исправлением
выявленных ошибок.
Reviewers
Люди со специальной подготовкой (технической или бизнесс подготовкой), которые после подготовительных работ
выявляют ошибки в документах.
Scribe (or recorder)
Посещает ревью митинги и документируют все выявленые ошибки.
3
5/2/2016 3:23:00 PM
Lecture 04
Типы ревью
Один и тот же документ может подвергаться разным типап ревью.
Существует четыре типа уровня ревью:
Low
Informal
Level of formality
Walkthrough
Technical review
Inspection
High
Каждый тип ревью имеет свои характеристики:
Informal review
 Результаты ревью не обязтельно будут документироваться
 У ревьюера не обязательно должны быть технические навыки, но он должен быть способен быстро убедиться,
что документ имеет смысл
 Основная цель найти ошибки
 Ревью может быть проведено программистами в паре (один программист просматривает код другого)
Walkthrough
 Ревью митинг проводится автором документа
 Формат проведения митингов свободный (от неформального до самого формального)
 Подготовка ревьюеров до митинга, создание репорта опционально
 Основная цель ознакомится и понять документ и найти ошибки
Technical review
 Хорошо документированы и используют чёткий подход по определению ошибок
 Митинг проводится модератором, но не автором документа
 Ревьюеры готовятся к митингу
 Митинг может проходить как в формальном формате и неформальном и ставить перед собой цели обсудить и
принять решение по поводу документа, выявить ошибки, проверить документ на соотвествие спецификациям и
стандартам.
Inspection – наиболее формальный тип ревью
 Ведуться обучеными модераторами (не авторами документа)
 Процесс Inspection формальный, основан на правилах, опирается на входной и выходной критерий.
 Подготовка к митингу основательная с детальным изучением документа
 По окончанию inspection создаётся репорт со списком выявленых замечаний и ошибок
4
Lecture 04


5/2/2016 3:23:00 PM
После митинга применяется регламентированый процесс по отслеживанию применения замечаний и
исправлений документа
Основная цель выявить ошибки
На практике грани между каждым типом стераются. В разных компаниях одни и те же шаги могут называть Technical
review или Inspection.






Факторы удачного проведения review
У каждого ревью должен быть чёткий заранее определённый список целей. К работе должны быть привлечены
люди, способные достигнуть поставленых целей
Любые обнаруженые ошибки и замечания конструктивно воспринимаются. Ошибки озвучиваются объективно
Применение одного из типов ревью (формальное или неформальное)
Среди участников распределяются роли (если необходимо) в целях улучшения эффективности
Необходима поддержка со стороны менеджмента
Статический анализ (Static Analysis)
Как ревью, статический анализ предполагает поиск ошибок без запуска самого кода программы. Однако, статический
анализ в отличие от ревью проводиться после того как код был написан.
Статический анализ может выявить баги, которые сложно обнаружить во время тестирования программы через
execution. Анализируется код, например, рисуются графики зваимодействия между модулями.
Цели статистического анализа:
 Ранее выявление багов
 Ранее выявление слабых моментов в архитектуре и коде
 Выявление ошибок относящихся к нарушению стандартов разработки, нарушению взаимодействия мужде
моделями, интерфейсами классов и т.п.
 Предотвращение появление багов – анализ первопричины имеющихся багов помогает исправлять подобне же
баги на уровне архитектуры программы или на раной стадии разработки
Типичные ошибки выявляемые статическим анализом:
 На уровне кода – обращение к переменной без определённого значения
 Перемаенные, которые никогда не используются.
 Недосягаемый код (dead code)
 Нарушение стандартов программирования (например, комментарии к коду написаны кода, но отсутствуют
коммаентарии на протяжении кода)
 Нарушения по безопасности (например, стуктуры для хранения паролей недостаточно защищены)
Tools for static analysis
Анализ кода и структур также осуществляется с помощью автоматических инструментов (tools). Программы исполняются
в автономном режиме и генерируют репорт своей работы. Анализируется код на наличие тех же проблемы, что были
описаны раньше – корректность взаимодействия компонентов, соблюдение стандартов кодирования и т.п.
5