Средства сокращения ошибок

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

- Доктор Дж. Ризон

Люди ошибаются. Если верить доктору Куку, то примерно 70-82% ошибок, связанных с анестезией, списывается на человеческий фактор. Примерно те же цифры показывает авиация и ядерная энергетика. Да и в целом подобные исследования в различных областях дают похожие результаты. Во многом из-за этого там и возникает ощущение "проблемы человеческого фактора", которую пытаются всячески урегулировать стандартами, правилами и автоматизацией. Увы, эти меры часто приводят к обратному эффекту - делают все еще хуже. Происходит это, в том числе, из-за серьезных изъянов в дизайне этих превентивных систем. Специалисты, исследовавшие подобные меры в здравоохранении и авииации, выделяют пять классов проблем, которые обычно приводят к увеличению количества ошибок: сложность, рабочая нагрузка, плохой дизайн, прерывания и культура. Возможно, их больше, но я остановлюсь на разборе тех, на которые указывают работы доктора Ризона.

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

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

1. Найти среднюю нагрузку не всегда легко
2. Бизнес обычно заинтересован в максимальной производительности

В принципе, вторую проблему частично решил еще дедушка Форд, понявший, что неполная загрузка работников помогает избежать затыков из-за колебаний в работе различных звеньев системы. Доктор Ризон же утверждает, что это ведет к снижению количества ошибок в системе.

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

Плохой дизайн

Лет десять назад в эфире практически отсутствовали такие слова как usability и user experience. Сейчас об этом говорят и пишут достаточно много. Отвратительный софт и сайты-лабиринты от этого не исчезли, но о проблеме хотя бы говорят. Увы говорят обычно про пользователя, зачастую подразумевая совсем не работника и не оператора. А стоило бы.

Потому что плохой дизайн рабочего места приводит к росту ошибок.

Потому что плохой дизайн рабочих инструментов приводит к росту ошибок.

Продолжать можно долго, но практически все это можно увидеть посетив какой-нибудь банк. Да и в разработке ПО у нас все еще есть множество языков программирования с сомнительным дизайном, аналогичного качества IDE и фреймворки. И это я еще от монитора глаза не отводил.

Прерывания и отвлекающие факторы
Врача скорой помощи в штатах отвлекают от работы в среднем 10 раз за час. Демаете от этого он начнет меньше ошибаться? Нет, у него от этого вылетают из головы важные мелкие детали.
У авиации все еще печальнее. По статистике примерно 50% ошибок в авиации (а они порой бывают очень ссмертельными) происходят потому, что пилотов отвлекали.
Думаете в разработке ПО все сильно лучше? Тогда придите как-нибудь на работу пораньше и поработайте пару часиков, когда никого в офисе нет, и в почту ничего не ломится. Если вам в одиночестве работается гораздо лучше, то у меня для вас плохие новости.
При этом понятно, что совсем без прерываний нельзя. Разработка ПО так или иначе связана с коммуникациями, т.е. нужно как минимум общаться друг с другом и с заказчиком. И совсем избавиться от этого никак нельзя, потому что тогда все встанет колом. Но сводить это общение к минимуму тоже непросто - слегка переборщил и все пошло наперекосяк.
Но даже не смотря на эти проблемы возьмите того же тестировщика. Если он у вас одним глазом смотрит в систему управления тестами, а другим в тестируемое приложение, то у него прерывания не просто периодически случаются - он в них живет.

Культура
Культура безопасности в ядерной энергетике появилась после аварии на Чернобыльской АЭС. По сути ее отсутствие и явилось причиной той аварии. Подробности по культуре безопасности можно прочитать, например, на сайте минатома.
Если вкратце, то это когда вся организация честно признает безопасность приоритетной целью и действует соответствующим образом. Т.е. методы управления, отношения в организации и подготовка персонала должны быть в первую очередь сосредоточены на безопасности, никак не снижать мотивации эту безопасность поддерживать и не подавлять коммуникаций. Звучит просто, но обычно в умах управляющего персонала "ответственность" подменяется "страхом перед ошибками", что чаще приводит к замалчиванию и педалированию проблем.
Только проблема тут в том, что культура безопасности или есть, или ее нет совсем. Никаких полумер тут быть не может, в отличие от остальных пунктов.


А что же тестирование?
А тестирование это отличный пример системы защиты от ошибок, которая частенько нарушает все пять пунктов. При этом, вместо того чтобы нормальным подходом к тестированию решать так называемую проблему "человеческого фактора", обычно делается то же, что и в других отраслях - накручивание стандартов, количественный рост различных правил и не очень осмысленное увлечение автоматизацией, которая провозглашается как средство борьбы с тем самым "человеческим фактором". Ядерную промышленость это не спасло ни в 1979-м году, ни в 1986-м.

И все же, при чем тут тестирование?

Сложность.
Можно взять, например, большущий талмуд под названием "предрелизные регрессионные тесты", заглянуть в него, и на этом вопросы об избыточной сложности должы сразу отпасть.
А можно пойти дальше и посмотреть, сколько у вас дополнительных полей накручено в вашей JIRA. Если на экран не помещается, то это просто плохо. А если на два, то... Нет, они все, безусловно, очень важные и полезные. И, возможно, у вас кто-то уже писал документ зачем нужен вон тот чекбокс, но их же действительно дохрена. Посмотрите на какой-нибудь девственно чистый FogBugz - там едва набирается десяток полей компактно упакованный на один экран. И где-то после первого десятка уже пора начинать кричать "горшочек не вари!".
А автоматические тесты с кучей ассертов? Ладно бы стоимость поддержки этих монстров, но это настоящее кладбище ложных срабатываний.

Рабочая нагрузка.
Примерно вот так в куче контор выглядит рабочая нагрузка тестировщика (иногда такое не стесняются показывать на конференциях):

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

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

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

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