Тестирование требований разработчиком

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

Как показывает практика, даже простая разработка вариантов тестирования без реального выполнения тестов может выявить множество проблем с требованиями. Если вы начнете разрабатывать варианты тестирования сразу после стабилизации некой части требований, вам удастся обнаружить проблемы, которые еще можно устранить с минимальными затратами.

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

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

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

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

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

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

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