[@McConnell2004]

• Каждому ли требованию, относящемуся к классу или методу, соответствует отдельный тест?
• Каждому ли аспекту проектирования, относящемуся к классу или методу, соответствует отдельный тест?
• Каждая ли строка кода протестирована хотя бы одним тестом? Проверили ли вы это, подсчитав минимальное число тестов, нужное для выполнения каждой строки кода?
• Каждый ли путь “определение — использование” в потоке данных протестирован хотя бы одним тестом?
• Проверили ли вы код на наличие в потоке данных путей, которые обычно ошибочны, таких как “определение — определение”, “определение — выход” и “определение — уничтожение”?
• Использовали ли вы список частых ошибок для написания тестов, направленных на обнаружение ошибок, которые часто встречались в прошлом?
• Протестировали ли вы все простые граничные условия: максимальные, минимальные и граничные условия с завышением или занижением на 1?
• Протестировали ли вы сложные граничные условия, т. е. комбинации входных данных, которые могут приводить к слишком малому или большому значению вычисляемой переменной?
• Тестируете ли вы код на предмет неверных видов данных, таких как отрицательное число сотрудников в программе расчета заработной платы?
• Тестируете ли вы код с использованием типичных средних значений?
• Тестируете ли вы минимальные нормальные конфигурации?
• Тестируете ли вы максимальные нормальные конфигурации?
• Тестируете ли вы совместимость со старыми данными? Тестируете ли вы код, работающий со старым оборудованием и старыми версиями операционной системы, а также интерфейсы со старыми версиями других программ?
• Позволяют ли тесты легко проверить результаты вручную?

Ключевые моменты

• Тестирование, выполняемое разработчиками, — один из важнейших элементов полной стратегии тестирования. Независимое тестирование не менее важно, но оно не является предметом этой книги.
• Написание тестов до написания кода требует примерно того же времени и тех же усилий, что и создание тестов после кода, но сокращает циклы регистрации — отладки — исправления дефектов.
• Даже если учесть, что тестирование имеет массу разновидностей, его все равно следует считать лишь одним из элементов хорошей программы контроля качества. Высококачественные методики разработки, позволяющие свести к минимуму число дефектов в требованиях и проектах, играют не менее, а то и более важную роль. Методики совместной разработки характеризуются не меньшей эффективностью обнаружения ошибок, чем тестирование, к тому же они позволяют находить другие ошибки.
• Опираясь на базисное тестирование, анализ потоков данных, анализ граничных условий, классы плохих и классы хороших данных, вы можете создать много тестов детерминированным образом. Методика угадывания ошибок укажет вам на некоторые дополнительные тесты.
• Обычно ошибки концентрируются в нескольких наиболее дефектных классах и методах. Найдите такой код, перепроектируйте его и перепишите.
• Для тестовых данных обычно характерна более высокая плотность ошибок, чем для тестируемого кода. Так как поиск ошибок в тестовых данных требует времени, не приводя к какому бы то ни было улучшению кода, эти ошибки более досадны, чем ошибки программирования. Избегайте их, разрабатывая тесты столь же тщательно, что и код.
• Автоматизация тестирования полезна вообще и практически необходима в случае регрессивного тестирования.
• Чтобы процесс тестирования был максимально эффективным, сделайте его регулярным, выполняйте его оценку и используйте получаемую информацию для его улучшения.