Борьба с жучиными гнездами

… В этом коде не просто живут баги. Здесь их гнездо. Это гнездо постоянно воспроизводит себя при помощи любимой китайской технологии реиспользования кода - copy/paste. Отсюда баги расползаются в разные стороны посредством статических переменных и переменных, переданных по ссылке ...

Из года в год на форуме тестировщиков задается примерно один и тот же вопрос: “Тестирую один и тот же кусок уже в двадцатый раз, и конца края тестированию не видно. Что делать? Помогите!”
Вот один из последних примеров:

Но увы… первое же тестирование выявило ошибки: каждый мой тест-кейс закончился неудачей.
Разработчик исправлял свои ошибки 2 дня. При этом он “протестировал” сам…
Наступило второе тестирование. Результат ничем не отличался от первого - столько же ошибок (старых и новых).
И теперь решили, что разработчик исправляет найденные ошибки прямо в тесте. Но вот беда: если он исправляет что-то в одном месте, то парочка ошибок возникает в других местах функционала.
Я уже не помню, что работает, а что нет.
Складывается впечатление, что мы собираем конструктор. Причем после каждой сборки постоянно несколько деталей остаются лишними, а некоторые прикручены совсем не в тех местах.
Я уже не верю, что когда-нибудь функционал заработает
.

Пришла пора вынести этот вопрос в ЧаВо.

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

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

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

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

Паттерн: “Дефекты нужно править до написания кода, а не после него”. По статистике Макконнелла 30% багов вносится в продукт на этапе создания спецификаций требований. И 25% на этапе проектирования. И зачем эти баги в код тащить?

Антипаттерн: “Автоматизация тестирования”. Имеется ввиду автоматизация через GUI после того как исполняемый код отдан в тестирование. Денег и времени сьест море, а польза очень сомнительна.Скорее, это просто выкидывание денег плюс поднятие ЧСВ у человека, который будет внедрять автоматизацию.

Оставьте комментарий

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