Home

Источник: журнал BetterSoftware (October 2005)
Перевод: Артём Ваулин

Читайте предисловие и первую часть материала: Используй только то, что действительно необходимо

Случай потерянного «IF»

Lee Copeland

С более чем тридцатилетним опытом в области разработки и тестирования программного обеспечения, Ли Копеланд (Lee Copeland) работал программистом, руководителем разработки, руководителем направления по улучшению процессов и консультантом. Он является техническим редактором и постоянным ведущим колонки для журнала Better Software и StickyMinds. com, а также автором A Practitioner’ s Guide of Software Test Design (Практическое руководство проектирования тестирования ПО).

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

Когда спросили ее мать, она привела точно такое же объяснение, что ее мать всегда делала точно также. На очереди оказался звонок бабушке, и этот звонок решил загадку.

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

Давайте рассмотрим примеры феномена потери «IF»:

• «IF собирать, понимать и модифицировать требования очень сложно и дорого, THEN мы должны установить формальные договоренности относительно требований с нашими стейкхолдерами» становится «Мы должны установить формальные договоренности относительно требований с нашими стейкхолдерами». Поскольку увеличивается взаимодействие наших стейкхолдеров с системой, которая разрабатывается для них, это может не быть обязательным — или даже полезным — для того, чтобы пытаться более точно определить, что мы будем строить. Но как много организаций продолжает настаивать на формальных требованиях, даже когда они не особенно полезны.
• «IF однажды написанное программное обеспечение, трудно поддается изменениям, THEN мы должны установить детальную документацию, точно описывающую системные требования со всеми мельчайшими подробностями» становится «Мы должны установить детальную документацию, точно описывающую системные требования со всеми мельчайшими подробностями». Поскольку сегодня средства проектирования и языки программирования для нашего программного обеспечения более «продвинутые», оно (программное обеспечение) может быть легко и быстро модифицировано. Но как много организаций продолжает требовать детальную системную документацию, даже когда она не особенно полезна.
• «IF подавляющее большинство наших тестировщиков программного обеспечения очень неопытные, THEN мы должны документировать каждый тест — кейс в «мучительных» деталях» становится «Мы должны документировать каждый тест — кейс в «мучительных» деталях». Другая версии этого процесса — «IF мы заинтересованы в том, чтобы не забывать тест-кейсы из-за их количества и сложности, THEN…».
• «IF мы заинтересованы в возможности взаимодействия между компонентами системы, THEN мы должны тестировать все комбинации всех компонентов» становится «Мы должны тестировать все комбинации всех компонентов». Возможно, существуют неважные взаимодействия, но мы все равно создаем массивные наборы тестов.

В недавнем разговоре с Джемсом Бахом (James Bach) на конференции посвященной тестированию STAREAST Джеймс предложил мета пример: «IF ты знаешь, что собираешься делать, THEN делай это» становится «Делай это» — несомненно очень опасное правило. Как много из нас попадаются на это в своей профессиональной деятельности и личной жизни.