Home

Автор: Брендан Коннолли (Brendan Connolly)

Оригинал статьи: http://www.brendanconnolly.net/keep-it-simple-theres-more-to-it/

Перевод: Ольга Алифанова.

KISS, бритва Оккама... Все мы слышали мудрый совет быть проще и не усложнять ничего без нужды. Совет этот мог касаться пользовательского опыта по работе с вашим ПО, а мог относиться к вашему подходу к тестированию. Однако всегда ли этот совет полезен?

Иногда он может означать следующее:

Не нарушай статус-кво

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

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

Нас не интересуют проблемы, обнаруженные в этой области.

Например, вы хотите провести несколько тестов производительности, потому что подозреваете, что где-то в этой области скрывается "бутылочное горло". В ответ вы слышите "Ой, да не надо усложнять, а? Разработчики учитывают моменты, связанные с производительностью, вот когда появится проблема - тогда будем разбираться".

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

Мы не знаем, что можно по-другому

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

"Будь проще" в этом случае может означать, что мы не готовы к переменам. К хорошим или плохим - неважно! Есть три способа что-то делать - правильный, неправильный, и наш. За любой практикой, за любым ритуалом обычно стоит какое-то обоснование или история возникновения.

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

Мы не понимаем риски

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

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

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

Мы плохо понимаем свои издержки

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

Если вы ограничены - временем ли, другими ли причинами, - вы вполне можете выпустить ПО, которое недружелюбно к пользователю или в принципе еле дышит. Вы можете забить на регресс, потому что "изменения не затронули другие области". На вас давят, чтобы вы выпустили приложение как можно быстрее, а цена, которую вы заплатите, обрисуется когда-нибудь потом.

Что же делать?

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

Обсудить в форуме