За время своей работы в IT я сталкивался с очень разным отношением к тестированию ПО. Хочу поделиться своими наблюдениями по этой теме.

Цена ошибки

Я встречал два подхода к тестированию: must have и «разработчики все сделают как надо и сами проверят». Почему-то среднего не наблюдалось.
Первый подход я наблюдал в двух компаниях, работающих в сфере телекоммуникаций, только одна разрабатывала собственно пользовательские мобильные устройства, а другая – сети для этих устройств. Тестовый процесс в них так же серьезен, как и разработческий: контроль того, что все требования покрыты тестами, несколько фаз тестирования – проверка работоспособности старых функций после интеграции нового кода (LegacyRegression/Sanity/Integration Test), проверка новой функциональности (System/Function Test), стресс-тестирование и так далее. Такой подход обусловлен следующими причинами:

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

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

Хороший тестер, плохой тестер

Не по процессу, а по совести.
Тестовый фольклор

Есть заблуждение, что разработчики могут хорошо тестировать свой код сами и вообще у них такой специальный мозг, что они сразу умеют писать программы без ошибок, главное их как следует стимулировать кнутом и/или пряником. За мою карьеру в тестировании (3,5 года) я сделал ряд наблюдений и утверждаю: тестовый инженер – это совершенно другая конфигурация сознания, нежели разработчик:

• программист нацелен на решение проблем, тестер – на их создание. Тестеры циничны, патологически недоверчивы, безжалостны и изобретательны. Как может создатель взять в одну руку крюк, в другую – молоток и начать методически крушить свое творение на предмет выяснения, не является ли оно летательным мутантом? Программисты трепетно относятся к своим программам, и это правильно: если человек равнодушен к результату своего труда, то тут что-то не так;
• программист знает, как все устроено. Тестер не омрачен лишним знанием, у него всё под подозрением и ничего не очевидно. Это тоже правильно, потому что, если система сложнее калькулятора, ошибка может быть на любом ровном (как кажется программисту) месте;
• но самое главное – в тестировании, так же как и в разработке, приобретается свой уникальный опыт. Матерый тестер знает, за какие нежные места можно ущипнуть систему, чтобы она повернее впала в ступор.

Кое-что о методе

В новую версию – с новыми багами!
Тестовый фольклор

Помню один из своих первых проектов: многократно обсужденные, детальнейшие требования. Сотни тестов, обеспечивающих тотальное их покрытие. Несколько раундов полного тестирования системы. И тут один тестер, мой хороший друг, решил уйти в сторону с проторенной дороги и стал запускать не готовые тесты, а изобретать свои на разные смежные случаи – видимо, природа все-таки взяла свое. Ошибки полились рекой. Уже потом, читая одну из брошюр по тестированию, я обратил внимание, что для этого есть даже специальная формулировка – error guessing, то есть тестирование как раз исходя из опыта и понимания, где копать, чтобы уж наверняка. И этот метод является наиболее эффективным для поиска ошибок.
Правда, этот метод возможен только при ручном тестировании, которое большинство знакомых мне тестеров не слишком любит. И за которое программисты смотрят на тестеров свысока. С одной стороны, так проще – все делать руками, но это достаточно скучно, если приходится повторяться, плюс большие расходы. Лучший подход, который мне довелось наблюдать, – обязательная автоматизация регрессионного тестирования: вышла новая версия, набор тестов запущен на ночь или на выходные, потом уже ручное тестирование новой функциональности или особо хитрых сценариев. Очень удобна автоматизация unit-тестирования, это как раз может делать и программист, там знание кода – вовсе не грех.

Выбирай, но осторожно

ТЕСТИРОВАТЬ!!!
Боевой рев знакомого тестового лидера

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