Deadline VS Здравый смысл

Если вы работаете в более-менее организованной компании, то вам известно это стремное слово "DEADLINE". Я скажу с полной ответственностью, что каждый НОРМАЛЬНЫЙ человек, должен ставить себе цели и задавать себе сроки, в которые он планирует вложится, чтобы достичь желаемого. Кто как это реализует в своей жизни - личное дело каждого. Но случилось так, что недавно я услышал отличную мысль на этот счет.

Для достижении цели, короткие итерации эффективнее длинных.

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

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

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

"Всем начать тестирование по своим направлениям!"

Первая волна тестирования показывает "неожиданный" результат. Более 80% тестов свалилась, а другие 20% блокированы. Опытные бойцы тестеры показывают своим видом, что переживать не стоит, ведь это "первый блин", а дальше будет лучше.

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

Вторая волна тестирования началась. Новая версия продукта уже перед бравыми тестерами. Конечно же все баги, обнаруженные в первой волне уже не будут тревожить мирных граждан. Ну... Это... Как бы... НЕТ! Реальных фиксов произведено не более, чем N (N < 5). Вы представляете себе это? Людям (да, я говорю на тестеров ЛЮДИ!) приходится проходить тесты на продукте, который не готов даже для smoke тестов. Заводится множество багов, которые каким-то чудом не были обнаружены в прошлый раз. Но уже сейчас есть подозрения, что эти баги будут просто пылится на баг-трекере. Высшее командование присылает десятки писем, которые содержат информацию о том, что тест-кейсы можно было бы переписать иным образом: объединить несколько шагов в один, заменить пункты "1)" на "1."... Это конечно важно и безусловно поможет в будущем. Я мог бы описать третью волну, четвертую и т.д. Но зачем? Я имею ввиду ЗАЧЕМ переливать из пустого в порожнее? Чего ради прогонять ОБЯЗАТЕЛЬНОЕ количество тестов, которые опять рухнут? Почему нет оптимальности в процессе? Где у людей мозги? А мозги заняты другим. В них зависла мысль о DEADLINE. Ведь "генералам" сказали прогнать 800 тестов до завтра!!! И тут все проходит на уровне ударов головой о стену.

Приказ носит заведомо преступный характер.

А ведь можно было бы собраться "головам" и разбить тесты на узлы. А потом из узлов связать сеть. И если узел "А" прошел тестирование на 80% или более, то можно начинать тестирование тех узлов "Б", "В", "Г",... которые являются зависимыми от узла "А". Таким образом убиваем 2-ух зайцев:

1) Рациональная нагрузка на тестеров. За счет уменьшения числа тестов на 1-го человека, повышаем качество выполнения работы (в идеале).
2) Делаем КПД тестирования максимальным при наименьших затратах на контроль. Ведь проследить за тем, что происходит с 100-ей тестов легче, чем если бы тестов было бы 800.

Простите за кривой почерк, пишу вам из пылающего танка, на спине убитого товарища.