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

1. Требования

2. Тест-кейсы

3. Управление ошибками

4. Документирование

5. Взаимодействие

Внутри каждой категории я обозначу и постараюсь объяснить каждую пометку из тех, которые я набросал в своем блокноте во время подготовки.

Требования

1. Требования необходимо тестировать

Речь здесь идет о тестировании требований всех уровней и видов: бизнес-требования, пользовательские требования, системные требования, функциональные требования, нефункциональные требования, требований производительности, требования удобства использования и т.д.

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

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

Последствиями либо отсутствия тестирования требований вообще, либо откладывания тестирования требований до лучших времен или тезиса «все их недостатки выявятся в процессе разработки и тестирования» являются:

• выявление серьезных ошибок проектирования непосредственно перед выпуском релиза, что приводит к необходимости серьезных доработок, как требований, так и кода (я уже не говорю о доработке тест-кейсов, тестовых данных и повторном тестировании). Естественно, все это приводит к срыву сроков, авральной работе (по ночам и/или выходным) и прочим негативным вещам, которых можно было бы избежать своевременным тестированием требований;

• перекладывание всей ответственности и вины за случившееся на создателей требований, что по меньшей мере, не оздоровляет отношения между участниками разработки. Наверное, многие сталкивались с позицией программистов, аналогичной этим: «Не было написано, поэтому и не сделал», «Как написано, так и сделал», «Писать надо лучше» и т.п.

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

В заключении заметки о тестировании требований еще раз осмелюсь повторить критерии качества требований к программному обеспечению:

• Корректность

• Недвусмысленность (однозначность)

• Полнота

• Непротиворечивость (совместимость)

• Упорядоченность (ранжированность по важности и стабильности)

• Проверяемость (тестируемость или тестопригодность)

• Модифицируемость

• Трассируемость (прослеживаемость)

• Понятность