Что пишут в блогах

Подписаться

Что пишут в блогах (EN)

Разделы портала

Онлайн-тренинги

.
Случай потерянного «IF»
30.09.2008 09:59

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

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

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


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

Lee Copeland

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

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

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

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

  Есть ли в вашей организации процессы, похожие на этот случай? Будучи впервые определенными, многие организационные процессы имеют форму «IF…, THEN…». Однако, время идет, и процессы становятся наделенными особым статусом, часть «IF» забывается, оставляя нас только с частью «THEN» — процесс без контекста, правило без причины.

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

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

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

Есть ли в вашей организации процессы, для которых условие «IF» потерялось и условие «THEN» стало «правилом без причины»? Дайте мне знать. Мой электронный адрес Этот e-mail адрес защищен от спам-ботов, для его просмотра у Вас должен быть включен Javascript . IF я получу хорошие примеры, THEN мы опубликуем их в будущих выпусках.