Качество умерло, да здравствует качество

Качество умерло.

Собственно оно никогда и не являлось самоцелью для бизнеса. Конкурентным преимуществом? Да. Самоцелью? Маловероятно.

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

• Тестирование требований
• Тестирование после разработки
• Тестирование по сути является лакмусовой бумажкой по которой определлялось выпускать продукт или нет

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

Уже тогда для ряда софта было выгоднее исправлять проблемы по мере обнаружения их клиентами, а не стараться найти все и сразу.

Сейчас со всеми ниндзя-апдейтами (мы не замечаем, а софт апейтится сам даже на телефонах) и облачными сервисами стало проще. Фейсбук не проводит нагрузочного тестирования, а просто раскатывает новый код для небольшой части пользователей и смотрит что происходит. Аналогично поступают Твиттеры, Гугли и прочие Фликры с функциональными тестами. При этом критично не то, чтобы факапа вообще не случилось (это слишком сложно для таких сервисов), а чтобы можно было это все быстро исправить. Как это обеспечить?

TDD, мониторинг, хорошая обработка ошибок, атомарные функциональные проверки, местами избыточные, где функционал критичен. То, что Julian Harthy называет Productivity Tests - все это работает на то, чтобы разработчикам просто было сложнее чекинить плохой код и чтобы было легко обнаружить и локализировать (testability в экстремуме, практически). Если нет плохого кода и основная функциональность более или менее работает, то при возможности выкатывать на все свои сервера исправления чуть ли не каждые 10 минут реагировать на проблемы пользователя становится сильно проще. И потери от ошибок резко падают.

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

Виттакер и Ко. предлагают в связи с этим совсем избавиться от тестировщика в виде человека выполняющего black box тесты дни и ночи напролет. С их точки зрения имеет смысл или зарываться в глубокую специализацию (UX, производительность, Productivity тесты), или заниматься тестированием фактически на уровне требований, когда критично понять правильной ли мы дорогой идем, и что же тут делать. При этом часть специализаций вроде нагрузочных тестов и функциональщину они хоронят за крауддсорсингом и облаками. Спорно, но Google такой Google... как всегда, в общем-то.

Правда они не так громко говорят, что такая модель работает далеко не для всего софта, и что процессы ОК от силы у 10% команд. Более того - по тем же Productivity тестам есть куча софта и фреймворков в открытом доступе, но практически нигде не написано как писать, что искать, и насколько те или иные подходы оправданы.

У них качество умерло.

Кто пользовался гуглосервисами - поймет. Кто не понимает - можно вспомнить случившиуюся в начале этого года потерю гмейлом почты у 150 тысяч пользователей, или потрахаться с blogger.com (про рекламу пива на детских каналах в ютубе мы умолчим). Или факапы с биллингом у МТС. Или регулярные проблеммы фэйсбука с приватностью (тысячи их). Или то, что твиттер это довольно поганенький в плане качества сервис, который регулярно падает и если бы он был IM, то умер бы в агонии давным давно. Но он не IM, и его фиговую способность справляться с бешенно растущими нагрузками нам компенсируют тем, что все это очень быстро чинится.

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

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

Но есть сферы применения тестирования, в которых оно приносит, или может приносить вполне очевидную, реальную пользу:

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

Добавим немного из примеров очевидно полезного тестирования от Виттакера:

• Productivity тесты и прочая работа "на процесс".
• Специализация а-ля UX, производительность.
• Тестирование документации (хардкорная такая аналитика)

При этом старый, архаичный процесс с тяжелой бюрократией и размытыми объяснениями отдающими параноидальным бредом вызывает вопросы насчет своей пользы для бизнеса уже сейчас. Кто-то жалуется, что не понимает что вообще там в их тестировании происходит, кто-то говорит, что оно пустая трата денег и очень тормозит процесс. Ему грозит стать таким же рудиментом, как IE6 в корпоративных стандартах (нет, этот рудимент все еще приносит деньги, но он где-то далеко в пятой точке технологического прогресса).

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

И еще раз процитирую Вейнберга: "Тестирование - это поиск информации с целью обеспечить ею принимаемые решения".

Очень сложно принимать какие-то своевременные решения, когда тебе создают 100500 багов, которые толком не объясняют где проблема, в чем проблема, а просто сообщают, что проблемма есть и сеют панику. Очень сложно принимать решения на основе тонн документации (и где они нашли на это время?) сомнительной полезности и нулевой прозрачности для Менеджера (нет, ну тестировщик-то написал и сам разберется, да... а нафига?).

Вейнберг дает такое определение качеству: "Качество - это то, что важно для кого-то". Надо знать этого кого-то. Надо понимать, что важно.

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