Методы предотвращения дефектов

Методы поиска дефектов

Методы поиска дефектов можно разбить на 4 категории:

· Ручной анализ (обзор) разрабатываемых артефактов:

o Персональные проверки (personal review) [1, стр. 231-269], [4, стр. 163-201];

o Формальные инспекции [1, стр. 232], [3, стр. 335-357];

o Групповые обзоры (walkthrough) [1, стр. 232];

o Парное программирование [11, стр. 84-85, 93, 131-133], групповое проектирование [5, стр. 76-77, 158-162];

o и т.п.;

· Автоматическая статическая проверка:

o Компиляция (помимо явных дефектов компилятор умеет находить неявные (warnings) – их не следует оставлять без внимания);

o Автоматический статический анализ кода с помощью специальных анализаторов;

o Автоматическая проверка на соблюдение принятого код-стандарта и стиля;

· Автоматизированное тестирование:

o Модульное или блочное тестирование (unit testing) [10, стр. 101-115], [11, стр. 147-152], [12];

o Автоматизированное функциональное (комплексное) тестирование;

o Автоматизированное тестирование графического интерфейса пользователя;

o Тестирование производительности; стресс-тестирование;

o Использование утверждений (asserts) [9, стр. 109-111];

o и т.д.;

· Ручное тестирование:

o Ручное интеграционное тестирование;

o Ручное системное тестирование;

o Сравнительное тестирование;

o Верификация требований;

o Пошаговая трассировка [9, стр. 82-83];

o и т.д.

У каждого из перечисленных методов есть свои плюсы и минусы. Какие-то виды дефектов лучше ловятся одними методами, какие-то другими. Поэтому, эффективная стратегия поиска дефектов будет состоять в применении комбинации нескольких разнородных методов [2, стр. 463-465]. Каждый метод поиска в зависимости от того, насколько хорошо он реализован и применяется в конкретных условиях, будет иметь свой собственный уровень эффективности, выраженный в процентах. В книге С. Макконнелл «Совершенный код» можно найти таблицу примерных значений эффективностей поиска дефектов для разных методов [2, стр. 463]. Обратите внимание, что согласно этим данным тестирование имеет сравнительно низкую эффективность поиска дефектов (30%-40%), а для того, чтобы сделать её высокой, необходимо увеличить стоимость процесса тестирования в разы (эффективность бета-тестирования при количестве тестеров >1000 около 75%).

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

· Прототипирование [9, стр. 44-48] – создание и опробование дешёвой модели разрабатываемой системы с целью проверить её характеристики и выявить неверные предположения и решения, которые могли бы привести к серьёзным дефектам (и переделкам) при разработке.

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

· Применение компонентного (или модульного) подхода [14, стр. 33, 65, 247]. Грамотное применение компонентного подхода при построении программных систем уменьшает их сложность [9, стр. 126-129], а, следовательно, сужает пространство возможных дефектов.

· Использование готовых проверенных решений и компонентов (собственных или купленных), в высоком качестве которых мы уверены. Чем меньше нам приходится разрабатывать новых собственных решений, тем меньше ошибок мы делаем.

· Рефакторинг кода [10] – приведение кода в надлежащий вид есть хороший способ профилактики будущих дефектов сопровождения, которые очень любят появляться при модификации непонятных, плохо спроектированных участков кода.

· Предварительная разработка тест-кейсов (до этапа кодирования) позволяет глубже понять требования к разрабатываемой системе и лучше спроектировать её. Частный случай этого подхода – Test-Driven Development, при котором модульные тесты разрабатываются не после, а до кодирования.

· Регулярный анализ причин появления наиболее серьёзных дефектов и поиск путей устранения этих причин. Это может происходить на периодических собраниях команды разработчиков [3, стр. 185-196], или можно проводить такой анализ для каждого серьёзного дефекта, найденного на этапах системного тестирования или после внедрения. Результатом такого анализа должны быть модификации процесса разработки [3, стр. 186-187], направленные на устранение причин появления дефектов или, как минимум, способствующие более раннему обнаружению подобных дефектов [1, стр. 301-304].

· Ваши идеи?

Здесь также стоит упомянуть человеческий фактор. Никакие методы не заменят профессионализм и опыт разработчиков и менеджеров. Настоящие опытные профессионалы, как правило, делают меньше ошибок, и использование их опыта даёт хороший задел для качественной разработки. Если же коллектив состоит преимущественно из молодых неопытных разработчиков, то следует рассмотреть возможность проведения специальных тренингов для них.

Дата добавления: 2015-04-29