Разбираемся, сколько бюджета закладывать на тестирование ПО и зачем нужен контроль качества при разработке сайтов
Синдром «Колумбии»
Сибирикс

Синдром «Колумбии»

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

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

Разработчик говорит клиенту, что столько-то бюджета пойдет на тестирование производимого софта. Клиент берет и вычеркивает пункт «тестирование» из сметы. Совсем.
Вы часто встречаете таких сусликов неадекватов? А они есть.

Суть проблемы

Клиент отказывается «дарить» часть бюджета на проверку качества, потому что считает, что за свою некомпетентность должен платить сам исполнитель.

Разработчик полагает, что выпускать недоделанный продукт — непрофессионально. И что в этом не заинтересован ни он сам, ни клиент. Если не вникать, то разумными можно назвать доводы обеих сторон. Но это только на первый взгляд.

Давайте разберемся, чем профессиональный подход (вверху) отличается от непрофессионального (внизу):
Дело не в желании разработчика срубить с вас максимум денег. Дело в процессах. Внутренний кодекс студии не позволяет сдавать неготовый продукт (а если он не прошел тест качества, то да, он не готов). И ведь вы выбирали исполнителя, ориентируясь не только на ценник — а то бы давно уже купили чудесный «магазин из коробки» или «корпоративник за пять минут» на распродаже ucoz-ов.

Стоимость тестирования напрямую зависит от времени, которое на него затрачивается. Объем которого, в свою очередь, задается уровнем качества проекта. А вот качество проекта и время на тесты — имеют уже нелинейную зависимость. Например, если вы хотите сделать свой проект на 5% качественнее, то можете готовиться к тому, что это потребует не на 5%, а, скажем, на 200% больше времени на отлов багов и улучшение юзабилити.
В нашей отрасли стоимость QA от общего ценника проекта будет находиться в пределах 8−12%. Такой буфер бюджета позволит добиться уровня качества «значительно выше среднего». Но даже затрачивая положенные 12% на тестирование, не стоит топать ногами, когда после релиза вы обнаружите еще баги. Это тоже общепринятый стандарт, от которого не спасает даже самая кропотливая проверка.

Пример из жизни

Был такой печально известный американский шаттл «Колумбия», преждевременный запуск которого привел к масштабной трагедии. А всё потому, что «специалисты NASA закрывали глаза на очевидные недостатки в конструкции шаттла, не думая о возможной катастрофе».

По факту руководство посчитало нормальным потратить миллиарды на космическую программу, сделать дорогой и эффектный аппарат, но — забить на отлаживание «мелочей». Факторы? Экономия денег, горящие сроки, невнимательность к деталям и обычная халатность. А в результате:
Источник apod.nasa.gov
Синдром «Колумбии» — явление, слава богу, вымирающее. По крайней мере, в веб-разработке. Но уникумы всегда находятся — не желающие понимать и отмахивающиеся от любых разумных доводов.

Что с ними делать?

Мы предпочитаем деликатно обходить стороной. Говорят, перевоспитание лучше всего происходит через горький опыт. Да и на одного уникума найдутся сотни «заурядных клиентов», готовых вкладываться в качественные и стабильные проекты.