Много лет назад, в моей практике был по истине, вопиющий случай:
Разработчики, в соответствии с ТЗ, создали витрину, однако код, обращённый к ней, не выдавал ожидаемого результата. После часа собственных безуспешных попыток был созван консилиум аналитиков, который постановил: «Тёмное колдунство, не иначе».
Предметом всеобщего обсуждения стал тот факт, что поле (пусть City) содержит массу пустых значений, но запрос “where city is NULL” не выдаёт ни одной строки.
Оказалось, кто-то из разработчиков дословно принял указание в ТЗ «При отсутствии информации указывать (null)» и заполнил ячейки словом ‘(null)’. Выяснили случайно поставив курсор в центр ячейки и вместо полного выделения увидели его между букв.
Если до текущего момента тупиковая комичность ситуации не очевидна, поясню: Многие приложения, в интерфейсе, отображают пустые значения именно так и нам в голову не могло прийти, что кто-то додумается заполнить пустоту подставным текстом.
Теперь к выводам и рекомендациям:
1. Бизнес требования, должны писаться бизнес языком, максимум можно в приложения добавить свои наработки кода.
2. В техническом задании нужно либо описывать критерии выборки текстом, либо выдержкой из кода, если таковой уже есть, и не замешивать одно с другим
3. Разработчик и тестировщик НИКОГДА не должны быть в одном лице. Приёмочное тестирование обязательно должно проводиться или повторяться человеком, не участвовавшим в разработке кода.