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

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

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

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

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

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

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

  • и т.п.;

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

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

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

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

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

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

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

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

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

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

  • и т.д.;

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

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

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

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

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

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

  • и т.д.

У каждого из перечисленных методов есть свои плюсы и минусы. Какие-то виды дефектов лучше ловятся одними методами, какие-то другими. Поэтому, эффективная стратегия поиска дефектов будет состоять в применении комбинации нескольких разнородных методов [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].

• Ваши идеи?

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