Мобильные интернеты

Спасибо гуглу и его enterprise-like бенчмаркам за то, что у меня таки дошли руки написать эту статью.

Если вкратце, то ребята по ссылке выше для своих маркетинговых целей по продвижению SPDY решили не париться с мобильной сеткой (она же совсем нестабильная) и тупо пошейпили себе траффик (пожали канал до одного мегабита и сделали задержку в 150 ms). Покет лосс убрали нафиг, видимо вокруг их офиса с мобильными интернетами проблем нет. Счастливчики.

Про то, почему сам этот эксперимент является обычным enterprise-like бенчмарком, и почему радужные статьи ребят из гугла про SPDY на данный момент несколько не соответствуют реальности я писать не буду. По этому за последний год только ленивый не топтался. А вот то, что из себя представляет мобильный интернет вообще (и в моем ареале обитания в частности) я постараюсь расписать достаточно подробно (тот еще секрет полишинеля, но что-то с раздражением делать надо).

"Хвосты"
Начнем с простого эксперимента - сидя на месте попингуем что-нибудь, что находится в том же городе что и я, скажем, тыщенкой пакетиков. Должно быть достаточно шустро и без адского расколбаса, который обычно видно при попытке попинговать тот же Google, ближайшие сервера которого, судя по всему, находятся далеко за Уралом, где-то возле Москвы.

С моего домашнего компьютера получается 1-22ms, со средним очень устремленным к 1ms. Т.е. есть какой-то "хвост", но очень маленький. Когда до местячковых сайтов начинают появляться "хвосты" до 200ms у меня, обычно, начинают возникать нехорошие слова в адрес моего провайдера. С не местячковыми чуть хуже - ирландский датацентр амазона со своими вечными 120+ уже убил желание пользоваться услугами ряда милых стартапчиков.

Ок, давайте произведем такую же операцию, подключив компьютер через телефон к WiFi и к 3G поочередно. Проверять, понятное дело, не из кафешек, где можно вдоволь налюбоваться гавеным хипстерским интернетом, а из офиса/дома, где с интернетами дела обстоят сильно лучше.
WiFi: 2-249ms, со средним где-то в районе 9ms. Первый подвернувшийся ноут показал ровно те же результаты. Ура мобильной железке отвечающей за WiFi!
3G: 37-1366ms, со средним где-то в районе 130ms.

Т.е. вроде бы почти те же самые 150ms, которые использовались ребятами из гугла для имитации мобильной сети, только временами у нас запросы начинают залипать на секунду с лишним. Но попытка открыть какой-нибудь современный сайт это сильно больше чем один запрос. Та же m.lenta.ru это почти три десятка запросов, где практически любой запрос, залипнув на полторы секунды, может заставить пользователя в два раза дольше пялиться на пустой экран. И это, поверьте мне, далеко не самое страшное, что может случиться с вами при попытке просмотреть "мобильную" версию сайта. Что уж говорить про "не мобильные" сайты или ваше любимое приложение, которые открывает пяток соединений и начинает туда отсылать все подряд с завидной регулярностью.

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

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

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

Вот вам и разница между небольшим офисным зданием на отшибе посреди леса и здоровым бизнес центром на пересечении кучи транспортных магистралей. Как ни парадоксально - мобильные интернеты в центре города сильно хуже, чем в небольшом жилмассиве посреди леса.

Происходит это безобразие во многом потому, что воздух, по которому мы передаем сигналы 3G и прочего WiFi - это не только слегка сопротивляющаяся среда доставки (как в случае проводов, например), но еще и открытое пространство для всевозможных вмешательств. Радиоволны, стены, микроволновое излучение, электромагнитное излучение и тросионные поля магических единорожков - это все лишь небольшой перечень возможных преград, увеличивающих latency пока сигнал с вашего телефона прорывается к вышке и обратно. Даже обычная открытая микроволновка может здорово подпортить опыт пользования беспроводными интернетами. И в центре города этих препятствий сильно больше, чем посреди леса. Пара тысяч городских жителей с карманами, забитыми гаджетами, мешает вам сильнее, чем полторы голодные белки, бегающие от дерева к дереву.

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

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

Этот таинственный мобильный роутинг
Ок, я стою в чистом поле, сигнал отличный, но пинги все еще конские. ЧЯДНТ?

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

Дело в том, что GGSN стоят не у каждого подъезда, а где-нибудь, где удобно мобильному оператору. Так, например, несколько лет назад траффик TELE2 роутился через швецию. Т.е. сидите вы попивая чай где-нибудь в Екатеринбурге, а ваш прогноз погоды для мобильного телефона несется в швецию, оттуда на сайт, скажем, гисметео, и обратно. И дело не в раздолбайстве отечественных операторов - американцы спокойно заруливают траффик из Вегаса в Сан-Франциско.

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

Итого
Дальше можно было бы затянуть шарманку про слабое мобильное железо и толщину канала, но будем честными - мобилки по железу уже потихоньку перестают отставать от персональных компьютеров большинства обывателей, а толщина канала от EDGE к 3G и далее в LTE растет весьма внушающими темпами. Но избавления от мобильного latency, которое на пустом месте норовит стать из плохого просто чудовищным, пока не видно. Скорее наоборот - от WAP отказались, других альтернатив под беспроводные сети не придумали и при этом все кому не лень стараются использовать HTTP и другую привычную TCP-машинерию, весьма чувствительную к высокому latency и потерям пакетов. Да, разработчикам стало жить проще, но  мы с вами платим за это своим собственным временем.

Перезапуск тестов

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

У автоматического теста есть всего один полезный выхлоп - падение теста. Все остальное время автоматические тесты просто греют воздух укрепляя в нас уверенность в нашем продукте (не всегда обоснованную, но это другая история). Это нагревание воздуха, безусловно, полезно для процесса и так далее, но большую часть времени никакой полезной информации не несет. Примерно как ребята в аэропортах, которые могут каждый год рапортовать, что в 100500 проверенных за год пар обуви ни одной бомбы не обнаружено. Работа, безусловно, полезная, но самое крутое что они могут сделать - это, как ни странно, исполнить свое предназначение и найти уже наконец эту чертову бомбу в этих чертовых ботинках. И перезапуск теста это примерно как "ой, кажется у вас в ботинках бомба, пройдите, пожалуйста, повторный досмотр - вдруг мы ошиблись?".

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

И что же означает это падение тестов? Обычно причины две:

1. Баги в продукте
2. Нестабильные тесты/Баги в тестах/Нестабильное тестовое окружение

Второе в одной группе, т.к. это, как правило, и является основным объяснением перезапуска тестов. И если мы начинаем перекладывать падение наших тестов на второй пункт, то мы попадаем в страну, где хреновые тесты - это норма, и где-то прячутся баги, которые мы могли бы найти раньше (и мы их, возможно, нашли, но успешно проигнорировали).

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

Да, я понимаю, что у всех своя специфика, уникальный внутренний мир проекта, сроки горят, начальство негодует и KPI не выполняется. Все это может заставить вас игнорировать какие-то упавшие тесты. Как правило это просто пустые отмазки. Как правило, но далеко не всегда.  Но тем не менее не позволяйте нестабильным, хреново написанным тестам становиться нормой. Не делайте нормой нестабильное тестовое окружение. Это все инженерные задачи - они решаются (не всегда легко, но тем не менее решаются). Если, конечно, суть вашей работы не заключается в том, чтобы демонстрировать пару тысяч зеленых квадратиков on commit.

Самоорганизующиеся высоконадежные организации (revised edition)

Тут недавно cartmendum вспомнил одну замечательную статью: "The Self-Designing High-Reliability Organization: Aircraft Carrier Flight Operations at Sea"

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

Можно долго спорить с тем, что ближе к разработке ПО этот наш авианосец или производство машин в недрах toyota. На мой взгляд и то и то достаточно далеко, но не в этом суть. Суть в том, что и там и там есть проблемы, которые в разработке и сопровождении ПО встречаются регулярно. А есть проблемы, которые нашему менеджменту только в страшном сне снятся. И при этом и там и там с ними справляются несколько лучше, чем в разработке ПО. Так что вместо того, чтобы примерять к IT авианосец просто выделю несколько ключевых, на мой взгляд, моментов, которые авторы статьи упоминают как средства сокращения факапов на авианосце:

• Тесные взаимозависимости между различными групами
• Тесная взаимная координация и обмен информацией, как результат частично дублирующихся знаний
• Высокая операционная избыточность - много разных людей наблюдают за одними и теми же событиями и обмениваются наблюдаемой информацией
• Широкое толкование того, кто принадлежит к команде
• Сокомандники включаются в коммуникационные цепочки, а не исключаются из них
• Регулярная работа над ошибками
• Высокий уровень понимания текущей ситуации - поддерживается постоянное понимание того, что сейчас происходит и какова вероятность тех или иных факапов
• Высокий уровень навыков межличностного общения
• Хранение детальных данных о прошлых факапах, которые внимательно пересматриваются с целью обучения
• Командная цепочка изменяется для того, чтобы отвечать текущей ситуации - высокая организационная гибкость
• Сообщения о просчетах и ошибках вознаграждаются, а не наказываются

Посмотрите на этот список. Посмотрите на организацию, в которой вы работаете. И крепко задумайтесь.

В agile даже просматриваются какие-то зачатки этого списка (кроссфункциональность, стендапы, доски...). Увы только зачатки. Увы зачастую идолизируются артефакты и полностью забывается главная цель, которой, в данном случае, является снижение факапов на производстве.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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


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

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

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

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

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

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

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

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

Ложь в картинках

 "А график для менеджера - как клипарт для дизайнера, постоянно для совещаний надо"

- @cartmendum

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

Почему так? Да потому, что картинки многим из нас воспринимать проще чем здоровенные портянки табличных или, что еще хуже, многомерных данных. Еще нам нравятся красивые картинки. Зачастую они нам нравятся куда больше чем картинки правильные. Практически любая современная инфографика тому отличное подтверждение - мусор с точки зрения мыслящего аналитика и красота с точки зрения восторженного гражданина.

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

И подобно тому как юный американец начинает освоение статистики с книжки "Как врать при помощи статистики?" любой, кому показывают графики, должен отказываться на них смотреть не прочитав пару книжек Тафти.

Если же вам читать Тафти лень, то попробую дать краткую выжимку.

0. Мешайте читать информацию

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

Если работать с данными не умеете - засоряйте чем угодно. Если умеете - не мне вам объяснять.

У Тафти есть простая формула Data-Ink Ratio - пропорция чернил затраченных на полезную информацию к всем чернилам затраченным на картинку. Чем дальше эта цифра от 100% тем сложнее зрителю будет понять что вы нарисовали.

У Тафти это выглядит примерно так:

Хорошо

Плохо

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

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

Вот парочка отличных примеров:

Красоты наведены, читать невозможно и простой ранжированный по местам список был бы куда информативнее и проще для восприятия

Шикарная работа с дробными значениями, веселые картинки вместо колонок и еще табличка сбоку для создания в головах ложной корелляции

На этом, в принципе, можно закончить, так как остальное это просто частные случаи.

1. Уберите к чертям весь контекст

Это уже практически мастерство лжи. Можно делать как Fox News. Например у вас есть вот такой график:

А вы не палитесь и сделайте вот так:

Цифры на месте - вы просто слегка поиграли со шкалой. Зато какой эффект! Сразу виден весь драматизм 4,6%!

Или можно сделать вот так круто:

Тут, правда нужны пояснения. На самом деле ребята просто склеили два этих графика:

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

При этом менеджеру даже не нужно напрягаться - он работает в условиях недостатка информации и тотальной неопределенности. Поэтому он будет рисовать тренды исходя из недостатка и принимать их как истину. Например вот так:

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

2. Больше цветов, хороших и разных

Тут вам может помочь художественное образование - там иногда рассказывают про работу с цветом.

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

Правильной работой с цветом можно внести порядочно хаоса в разум смотрящего на график.

Во-вторых всегда можно поработать с контрастом:

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

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

Мыло цветов, да? Надо занять мозг читателя попытками поиска разницы в совершенно однородных данных:

3. Пироги!

Менеджеры любят пироги. Не знаю почему, но чую все от того, что у Pie Chart'а есть одна фундаментальная проблема - человек еще может сравнить две линии по длине, а вот углы секторов круга различает очень плохо.

Это, наверное, самый честный pie chart  в истории. Но даже для него кто-нибудь может мне сказать какой процент пирога съеден?

Можно усложнить задачу и добавить кучу полей. Например простой топ100 в виде колонок это отвратная идея, а в случае пирогов она начинает играть новыми цветами:

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

Что тут меньше - Word 2000, Word 2002 или Word 2003? Как нужно повернуть пирог, чтобы Word 2002 выглядел поменьше? Большой простор для творчества, бесспорно.

В конце концов - комбинируйте с предыдущими пунктами.

Попробуйте не сломав мозг осмыслить то, что нарисовано тут:

4. Отупляйте!

Человек занятой всегда одержим мечтой идиота - упрощением. Он хочет получить упрощенную картинку и принять решение. Он не хочет думать над данными внутри, вокруг и уж тем более не хочет думать над математикой. Поэтому упрощайте. Убирайте контекст, усложняйте восприятие. Им не нужно уметь сомневаться в прочитанном. Им нужно быстро посмотреть и быстро принять решение. А вам нужно премию.

Не стоит показывать исполнительным директорам шедевры вроде работ Минарда:

В этой картинке слишком много концентрированных данных. Надо много осмыслять и думать. Читать. И не важно что соотношение полученных данных к затраченному времени тут эффективно как никогда. График не дает главного для менеджера - не говорит что ему делать. И при этом съедает кучу времени. Так что в идеале надо слушать дядюшку Година и упрощать этот график до такого:

Тупой Конец, Острый Конец и Ошибка Ретроспекции

Как и обещал - вторая модель факапов. Придумана давно Дэвидом Вудсом и Ричардом Куком.

Выглядит она примерно так:

Для того чтобы понять как оно работает представьте себе производственный процесс - стремительный и неумолимый, как перевернутый треугольник на рисунке. 

На "остром конце" процесса сидит непосредственный исполнитель, который что-то делает своими руками. Т.е. всякие программисты, администраторы и далее по списку.

На "тупом конце" сидят прочие участники процесса ничего непосредственно руками не делающие, но всяческие его обеспечивающие и направляющие. Для "тупого конца" отлично подходят менеджеры всех мастей.

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

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

Традиционный анализ факапов обычно фокусируется на "остром конце", но Вудс и Кук указывают, что в большинстве случаев исполнитель просто варит отраву из ингридиентов, которые ему выдали с "тупого конца". Варить он может хорошо или плохо, но то, что получается именно отрава от него никак не зависит.

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

Бесчеловечные американские психологи изучая эту особенность мышления как обычно проводили эксперименты на людях. Один из них выглядел примерно так - брали две группы людей, которым следовало оценить производительность человека или команды. Одной группе оценщиков сообщали что выхлоп от работы человека/команды был плохой, а другой группе сообщали что он был хороший или нормальный. При этом всем давали одни и те же показатели показывали одно и то же поведение команд/людей. Группа, которой сообщали о плохом выхлопе была склонна занижать оценку (и даже находила сотни обоснований), а группа, которой сообщили, что все было ок была склонна оценивать несколько лучше. И картина не менялась даже если подопытным сообщали что знание результата может повлиять на беспристрастность их оценки.

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

С трейдерами эксперименты были еще злее.

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

Дырка от бублика

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

Для начала возьмем довольно старую и популярную модель, успользуемую для анализа рисков и управления ими - модель "швейцарского сыра". У нее (как и у любого обобщения) есть ряд недостатков, но она очень крутая в педагогическом плане. Про недостатки можно будет побеседовать потом, пока просто опишу что она из себя представляет.

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

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

Дырки в сыре так же принято классифицировать как латентные и активные ошибки.

Чтобы было понятнее - разберем на примере.

Допусим у нас есть четыре слоя сыра:

• Планирование
• Код
• Обучение
• Сервера

На каких-то серверах не мониторится I/O. Это типичная латентная ошибка, т.к. сама по себе она проблему вызвать не может, но если что-то внезапно случится, то мы просто не сможем на этой стадии предотвратить проблему и все жахнет. И, скорее всего, пока не жахнет - эта ошибка будет существовать. Последнее, кстати, является крайне неприятным свойством латентных ошибок, но умный менеджер знает как с такими штуками бороться. Запишем эту ошибку:

• Планирование
• Код
• Обучение
• Сервера (не мониторим I/O - латентная ошибка)

Продолжим разбор гипотетического инциндента дальше.

Допустим группа умных людей немного ошиблась на стадии планирования емкостей и завизировала кривые расчеты у начальства. Получаем еще одну латентную дырку:

• Планирование (ошиблись в расчетах емкостей - латентная ошибка)
• Код
• Обучение
• Сервера (не мониторим I/O - латентная ошибка)

Все еще мало для катастрофы. Давайте добавим еще немного.

Пусть у нас тотальный непрерывный деплой и парочка unit-test'ов из тех, что прогоняются перед выкладкой кода на сервер ближайшие 20 минут не прогонятеся, т.к. рефакторится или находится в еще каком переходном состоянии. Ну бывает. Это непонятная ошибка, пусть будет латентная.

Еще кто-то взял и немножко нарушил стандарты кодирования. Наговнокодил, другими словами. Тоже бывает. Латентная ошибка.

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

И чтобы жизнь медом не казалась кто-то намудил с фиче свичами перед выкладкой и открыл наружу вызовы той самой волшебной API и по ней автоматом обновилась дока. Опять активная ошибка.

Суммируем:

• Планирование (ошиблись в расчетах емкостей - латентная ошибка)
• Код (бага - активная ошибка, говнокод -  латентная  ошибка)
• Обучение (открыли API наружу когда неположено - активная ошибка)
• Сервера (не мониторим I/O - латентная ошибка, тесты мигрируют -  латентная  ошибка)

Если мы попытаемся сложить все вместе, то катастрофа случилась примерно так: 

1. Запланировали емкостей явно меньше чем безопасно
2. Случайно нашлась бага, которая абьюзит I/O
3. Функцию с багой оказалось возможным вызвать через API снаружи
4. Тесты не нашли внешний вызов и багу, т.к. мигрировали на юга

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

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

Вот такая вот гимнатиска. Какие меры стоит принимать для того чтобы такого больше не повторилось - думайте сами.
Явных козла отпущения у нас тут два - по числу активных ошибок. Еще пачка по остальным ошибкам. Но "сырная" модель сообщает, что поиск козлов отпущения не для правильных ребят.

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

ЗЫ: Думаю какой-нибудь надмозг советской закалки уже снимает ремень чтобы выпороть того кто ему меньше всего понравился (примерно по этой причине планировать емкости безопаснее чем писать тесты - перед вами море материала для перевода стрелок). Т.е. хочет чисто гипотетически и совсем уж постфактум зыкрыть всего одну сырную дырку не обеспечив того что она никогда не повторится. Ну ок, сам себе злобный идиот раз создает такую корпоративную культуру.

ЗЗЫ: Еще раз повторюсь - модель говно и есть лучше. Но оно все так сложно...

(милли)метрики

(При написании этой статьи ни один Талеб не пострадал)

"Менеджеры не способные измерить то, что они хотят обречены хотеть только то, что они могут измерить" - Рассел Л. Экофф 

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

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

Почему мы хотим что-то мерить?

Есть старая, и не совсем корректная, цитата из Деминга:

"Вы не можете управлять тем, что не можете измерить"

Может из-за нежелания копаться в первоисточниках, а может еще по какой причине многие менджеры (да и не только менеджеры, чего уж там) свято верят в то, что управлять без измерений невозможно. В клинических случаях мы видим людей которые пытаются измерить все и делать далеко идущие выводы из этих измерений. Это явление можно встретить везде, так что на вермя можете забыть об исключительности и мессианстве IT отрасли.

Но тут есть ряд проблем.

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

Вторая - то, что многие очень важные вещи, которыми очень нужно управлять, совершенно невозможно нормально померить. Деминг приводит пример с обучением - персонал нужно и можно обучать, это стоит денег, процессом обучения нужно управлять, но корректно оцифровать это практически невозможно. Аналогично с поддержанием дома в порядке и воспитанием детей (это уже примеры из Экоффа). И если вы уже придумали как измерять воспитания детей, обучение или поддержание в порядке дома - лучше дочитайте до конца и подумайте раз двадцать.

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

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

Но из песни слов не выкинуть - менеджер измеряет чтобы управлять.

Что мы можем мерить?

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

Для наглядности возьмем метрику с богатой историей ректального применения - Defect Escape Ratio (мутационное тестирование страдает от подобного, но это отдельная история).

Дальше начинается тяжелейший сарказм, так что людям без чувства юмора читать крайне не рекомендуется.

Допустим мы хотим измерить качество тестирования (уже идея достойная Эйнштейна).

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

У меня даже крутая формула есть - берем все баги обнаруженные пользователями, вычитаем из них те баги которые были зарепорчены тестировщиками (такое бывает, мы все знаем), делим на общее количество багов. Чтобы отсеить совсем уж ерунду - считаем только блокерокритикалы.

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

Круто?

Нет.

У всего этого добра есть пара ньюансов:

1. Приоритеты багов имеют свойство со временем меняться, так что ваш волшеный график в один прекрасный день может изменить все свое прошлое.
2. Поток багов от юзеров подвержен все тем же проблемам что и поток багов от бетатестеров.

На втором пункте немного остановимся. Какие же это могут быть проблемы?

• Ваш продукт настолько отстойный что никто не хочет даже баги репортить
• Вам очень сложно зарепортить баг
• Вам очень сложно понять что за ерунду зарепортил вам пользователь
• Ваш продукт настолько интуитивно непонятен, что пользователю очень сложно добраться до самых бажных областей, а тестировщики там уже пару раз были

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

Вместо послесловия

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

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

Так что когда вам в следующий раз захочется покататься на велосипеде в ночном лесу руководствуясь одним только дорогущим барометром - удачи.

Системы управления Тест-кейсами. Часть вторая. Про ненависть

"essentially, all models are wrong, but some are useful"

- George E. P. Box

В продолжение вот этого поста.

Так уж сложилось, что софт для тестирования в большинстве своем отвратителен со множества сторон. Причем по большей части отвратителен именно как софт. Т.е. как нечто, что призвано решать какие-то проблемы тестирования. TCMS в большинстве своем не исключение.

Почему мне не нравится сама идея TCMS?

Что такое TCMS по своей сути? Это система электронного документооборота. Со своей спецификой документов, со своими workflow и прочая прочая. Хорошо если вы сможете настроить формат документтов и/или workflow, хотя с этим в большинстве TCMS все очень плохо.

Сколько у вас в вашей работе систем документооборота? Скорее всего есть багтрекер (да, он именно такой системой в какой-то мере и является). Может есть еще и какая-нибудь вики. Может еще что-нибудь. Т.е. как только у нас в голове оформляется проблема в тестировании/процессе/ватэва мы просто берем и фигачим в эту проблему системой документооборота. Нужно отслеживать какие есть баги и что с ними творится? Держите багтрекер. Нужно средство для совместной работы над спеками?  Ну возьмите вики. Запутались в том какие у вас есть тесты и не понимаете что происходит в тестировании? Держите TCMS.

Больше систем хороших и разных. С довольно поганой интеграцией друг с другом. И чтобы каждый работник в каждой из систем исправно и регулярно работал. Здорово? Не думаю.

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

Почему TCMS это трата времени?

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

1. Вносить изменения по ходу работы. Т.е. это или будет постоянная сверка с чеклистом по ходу работы, или человек будет делать дампы небольшими кусками.
2. Вносить изменения постфактум. Это тоже кушает время, но не требует переключать контекст во время работы.

Есть способы сделать жизнь легче. Вот такой, или вот такой, например. Только почему-то, AFAIK, в TCMS пока ничего подобного нет. А пока нет - ваше тестирование будет сродни пилоту, который вынес нафиг все показания датчиков на спинку своего кресла и должен постоянно оборачиваться чтобы понять что происходит и куда дальше.

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

При этом сами TCMS как правило ограничивают ваши тесты как формой так и форматом. Вам нужен бинарный результат. Вам скорее всего придется потратить время на такую вредную штуку как сведение всех ваших тестов до одного уровня атомарности. Делаете очень много маленьких тестов - получаете почти полную невозможность делать хорошие, сложные тесты. Много больших - получается обратная проблема. Много разных - ваши метрики вроде pass/fail ratio начинают трещать по швам от своей бесполезности.

Ну и конечно же "счастье" в виде поддержки тысяч кейсов для динамически развивающихся продуктов. Хотите? Считаете что оно стоит того? Есть компании, где существовали специально выделенные люди для актуализации тесткейсов. Вам к ним.

Почему сомнительные бонусы?

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

Ведь если нам нужно понять в каком состоянии находится проект, то можно работать над такими штуками как Low Tech Testing Dashboard. Вот хороший пример. Это быстро, нет никакого мусора. Можно делать хоть на вашей доске прямо в кабинете.

Если вам нужно понять какие тесты у вас уже есть, а каких нет - рисуйте MindMap'ы, оформляйте используемые модели каким-нибудь более удобным способом чем стена текста всунутая в таблицу. Есть много отличных способов работать с многомерными моделями/данными.

История прогона тестов сама по себе ценности не несет. Есть ценность в материале для post mortem анализа, которым может являться история тестов. Но после данного анализа этот материал практически не нужен.

Ну и, конечно же, метрики вписанные в TCMS.
Хотите из результатов прошлых тестов получить за сколько будет выполнен следующий прогон? Тогда, наверное, вы не очень хорошо понимаете почему тестирование кушает больше или меньше времени. Сюда же можно записать отслеживание прогресса.
Хотите использовать их для pass/fail ratio? Тогда вы наверное забыли что такое "один единственный баг из-за которого ничего в продакшен не пойдет". К тому же если ваш тест начинает падать, то надо проблему чинить. Ну или выкидывать тест, если эта проблема всех устраивает.

Вместо "итого"
TCMS отлично подходят для:

1. Тестов на примерно одном уровне абстракции
2. Тестов не сильно отличающихся по вариативности
3. Тестов с бинарным результатом
4. Когда мы можем легко отслеживать выполнение тестов и логировать его
5. ...
6. Ну вы понели

Это все отлично подходит для большинства автоматических тестов, вписывающихся в Productivity модель. Т.е. сравнительно несложных, атомарных проверок, которые (так уж исторически сложилось) принято называть тестами. Для постобработки такого материала хорошая работа с табличными данными более чем пригодна. Увы она есть не во всех TCMS, но даже с этим можно что-то сделать.

Для ручных тестов получается три варианта:

1. Вы осознанно отказываетесь от различной тестовой активности, которую нельзя уложить в шаблоны использования TCMS и которые приводят к уплыванию встроенных туда метрик. Можете еще попробовать отрубить себе ногу.
2. Вы пытаетесь впихнуть в TCMS невпихуемое. Получается уродливо, неудобно, да к тому же большую часть бонусов от работы с TCMS вы потеряете.
3. Вы честно признаетесь что в TCMS будут не все ваши замечательные тесты и не вся тестовая активность. И скорее всего там будут только автоматические тесты. Если вообще будут.

ЗЫ: Откровенный фашизм с визированием и разделением тестировщиков на "читателей" и "писателей" я не вижу смысла обсуждать. Оно имеет смысл в случае когда к вам пришло FDA, но даже там это не единственная возможная/нужная активность.

Системы управления Тест-кейсами. Часть первая. Про любовь.

В этот раз хочется обсудить кошмар под названием Test Case Management Systems.

Для тех кто не в курсе что это такое - поясню:

Жили были тестировщики. И писали они тесты. Иногда тесты получались гениальные или очень сложные, и тогда они их записывали куда-нибудь. Как только тестов становилось много, их начинали упорядочивать в аккуратненькие документики (мы ведь знаем, что тестировщик в душе своей тот еще бюрократ). Отделы росли, поколения тестировщиков сменяли друг-друга, и примерно через годик-другой ведения таких аккуратных документиков в любой мало-мальски большой конторе со средней паршивости текучкой кадров обычно образуется завал этих аккуратных документиков, которые можно смело назвать "интелектуальное наследие прошлого", aka "помойка".
На этой стадии морального разложения у команд тестирования, как правило, есть куча "очень важных" документов. Обычно это куча экселевских (или еще чего похуже) файликов в которых есть аккуратные таблички, где можно ставить классные галочки или крестики или что вам удобно для того чтобы отмечать прогресс. У протестированной версии продукта должны быть все копии этих ддокументиков завизированные кровью самого старшего тестировщика с отметкой "PASSED" или "ПРОЙДЕНО" (в особо клиническом случае - "БАГОВ НЕТ!!!"). Ну и, конечно же, все должно быть пройдено ручками с точностью до запятой. Эдакое "cover your ass" тестирование, не имеющие ничего общего с качеством, но логично вытекающие из роли тестировщика как козла отпущения. Козел умирать не хочет, потому как может, так и прикрывает свои филейные части.
Иногда есть еще и сакральный документ под названием "план тестирования", который в лучшем случае представляет из себя что-то отличное от сборника всех-всех документиков с тест-кейсами. Но это отдельная, не менее печальная история.
Расово верный тестировщик может годами обсуждать правильные формы для заполнения таких документиков, обмениваться такими формами с коллегами, думать о выделениях разными размерами шрифта и запятыми, и предаваться другим околографоманским забавам.

Но!

У этого вороха документиков есть ряд недостатков:

1. С ним чертовски неудобно работать. Вообще. Надо создавать копии документиков, держать их открытыми у себя на мониторе, сверяться все ли заполнено. И там даже не стройные ряды чекбоксиков, а частные spreadsheet-like поля. Тысячи их.
2. Все хорошо пока в отдельно взятой команде тестировщиков есть непрерывная линия устно-фолклорной передачи сакрального знания о пользовании данными документиками. Как только цепочка нарушается - разобраться в этом кошмаре становится очень сложно (тестировщик хоть и бюрократ и гарфоман, но не враг себе, и старается устроить все поудобнее). Иногда трудно понять, что же за кошмар творится в соседнем отделе. Иногда благославенным перстом какого-нибудь корпоративного фюрера вводится "удобная для всех форма", и все работают с ней.
3. Чтобы понять, "что же эти тестировщики делают", в ряде случаев нужно собрать большой такой ворох документиков и долго, при помощи Microsoft Office'XX и такой-то матери понимать. Иногда это еще называется "в каком состоянии находится вверенный тестировщикам софт".

В общем радужный такой, пост-водопадный бюрократический северный пушной лис.

Для того чтобы избежать всего этого кошмара не придумали ничего лучше, чем:

TEST CASE MANAGEMENT SYSTEMS

Сначала были коммерческие, потом стали и не очень коммерческие. Горячо любимые нами вендоры тестерского софта вобрали в такие системы все лучшие практики индустрии:

1. Вся прелесть пользовательских интерфейсов в лучших традициях Enterprise-решений
2. Возможность задавать права соответствующие пищевой цепочке ваших тестировщиков (например "самый умный пишет - остальные выполняют") вместе с гибкими настройками рабочего процесса, когда вы можете наслаждаться тем, что изменение одной формочки - это будет не просто коммит, но еще и правко-визирование от N просвещенных тестировщиков
3. Возможность наслаждаться наиполезнейшими метриками вроде pass/fail ratio и предсказывать сроки! Вам не придется самим считать это темными менеджерскими ночами! Теперь все будет сделано за вас любящей и знающей машиной!
4. Возможность структурировать все в так горячо любимые тестировщиками таблички. Сотни! Тысячи табличек! Все с блестящей иерархией!
5. Возможность отслеживать время выполнения. Да-да! Вам не хватает мест куда бы ваши сотрудники могли бы писать сколько минут и на что они потратили? Заведите себе еще и TCMS! Ведь учтенное время это время, потряченное не зря!
6. Одни и те же тесты можно запускать в разной среде, от чего в обычных экселевских табличках многомерные данные просто не укладываются. Теперь вы можете привязывать конфигурации, и вообще все прямо на месте!
7. Завизированные тесты теперь будут доступны всем важным лицам для ретроспективного анализа, и никто и никогда не сможет туда добавить что-то задним числом!
8. Ну и конечно же вы сможете дружить эту волшебную систему со всем подряд, начиная от вашего багтрекера и заканчивая ковриком в кабинете генерального директора

Далее в комментариях я предлагаю обсудить все прелести и недостатки такого монументального решения. 

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

Baby steps for pussies

В современной разработке ПО сложился ряд практик сильно завязанных на то, чтобы всем было удобно маленькими шажками развивать свой продукт. Agile во многом об этом, TDD/ATDD/BDD об этом, continuous delivery об этом, A/B тесты об этом. Большая часть интернет-гигантов в том или ином виде их практикует. Многие высокотехнологичные стартапы выпустив свой мегапродукт и выжив после этого плавно переходят к управлению рисками через вышеозначенные практики. Ведь это позволяет постоянно совершенствоваться, позволяет сделать так, чтобы от вас были без ума 80% пользователей.

И их всех можно понять - эти практики позволяют довольно быстро и интерактивно дотачивать продукт. Если у вас есть много пользователей, то вы раскатываете на 1% аудитории небольшие правки. Новую анимацию, пяток разных оттенков зеленого для заднего фона, несколько разных текстов для одной и той же кнопки, маленькую новую фичу. А дальше можно просто смотреть что делают пользователи и считать что происходит. Тот вариант, которые приводит к более желательному для вас поведению остается, остальные пропадают и никто о них не вспомнит. Даже те, кто им пользовался - многие просто решат что им показалось. Если вы маленькая контора - просто выкатываете всем и смотрите что происходит. Если все плохо - быстро откатываетесь назад и делаете вид что ничего не случилось. Так дотачивали и дотачивают Facebook, большую часть сервисов Google, Twitter, Etsy, предвыборный сайт Обамы, и еще кучу всего.

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

Но у этого всего есть пара недостатков.

Первое - все эти практики в большинстве своем приводят к тому, что вчерашние стартапы приходят к жизни, в которой нет места большим, революционным изменениям. Сначала вы их боитесь, потом вся ваша инфраструктура, сложившиеся вокруг нее процессы и выросшая из этого всего культура просто не могут позволить себе большие, революционные изменения. Вы подсаживаетесь на эти маленькие экспериментики, ведь это так круто! И вы уже не думаете о больших свершениях. которые нельзя разглядеть через тысячи маленьких коммитов. Мы получаем "более быструю лошадь" вместо автомобиля. Лучшие инженеры мира при поддержке кучи денег работают над тем, чтобы помочь бизнесу решить на сколько пикселей и в какую сторону подвинуть поле ввода, чтобы вся обезличенная ими же масса принесла на 0.1% больше денег. Не обязательно даже понимать почему, достаточно видеть, что да, так будет на 0.1% больше. Маленькие шажки, которые становятся маленькими, но очень тяжелыми кандалами.

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

Школы тестирования. Открытое будущее

В прошлом году James Whittaker и Alberto Savoia породили интересуню дискуссию на тему смерти тестирования вообще или в конкретных его проявлениях.

Янезнаючтоэтозначит, но оба, кстати, недавно покинули Google.

Еще не успела улечься эта волна дискуссий, как на прошлой неделе свет наш Cem Kaner заявил, что:

Даже если когда-то и существовала контекстная школа тестирования, то отныне ее нет.

Для того, чтобы разобраться в том, что случилось стоит вспомнить что вообще представляют из себя школы тестирования и какие они бывают.

Школы? Что это?
Эксперты в тестировании ПО очень часто не соглашаются друг с другом, спорят и вообще ведут себя странно в силу ряда причин, которые во многом кроются в сильно разных, зачастую противоречивых теоретических базах, подходах, разном определении одних и тех же терминов и еще сотне-тысяче других причин.
До 2003-го года общение на почве тестирования было затруднено, но ясно солнышко Bret Pettichord (дальше местами будет вольный пересказ его тезисов) сотоварищи постарался и ввел такое понятие как Школы Тестирование ПО. Эти школы это не "Средняя школа №17", а скорее что-то сродни школам мышления, научным школам.
Bred Pettichord это один из основателей контекстной школы, так что это разделение на школы в основном дело рук именно этих граждан.

На данный момент принято считать, что школ пять: Аналитическая, Стандартная, Обеспечения Качества, Контекстная и Школа Гибкого (Agile) Тестирования.

Школа не определяется какими-то специфичными техниками - все школы в той или иной мере используют все известные техники.
У школы нет своей доктрины.

Как правило школа это набор общих целей, ценностей, терминологии и, возможно, каких-нибудь организационных институтов (ISTQB, например).

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

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

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

ПО для Аналитической школы это целиком и полностью логический артефакт.
Тестирование - ветка Cumputes Science/Математики (т.е. объективный, понятный, регулируемый процесс)
Любые техники тестирования должны давать один правильный ответ, т.е. принимают четкую логико-математическую форму.

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

Pettichord в качестве примера авторов этой школы приводит Бориса Бейзера.

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

Матрица покрытия требований хороший пример данной школы. Ее основной принцип - все требования и тесты для них (или наборы тестовых случаев) должны быть перечислены и когда все тесты прошли успешно - продукт можно выпускать. Это очень интересный артефакт, который как правило не работает в полной мере, т.к. требования меняются или могут быть просто неточными, а тесты так же не всегда показывают то, что мы считаем они должны показывать (см. предвзятость подтверждения). Т.е. в итоге можно получить софт сомнительного качества, но зато все клеточки зелененькие.

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

Это вносит ряд сложностей, т.к. это практически ничем неприкрытый Тейлоризм, требующий четких границ между тестированием и любой другой активностью, т.е. четких критериев начала/остановки работы.
Так же с такими подходами очень сложно вносить изменения в уже имеющиеся планы.
Зато последователи этой школы очень много сделали на поприще генерации бесчисленных стандартов, "лучших практик" и сертификаций. В частности они породили мой любимый  IEEE Standard Classification for Software Anomalies.

Рекс Блэк отличный представитель данной школы, даже в последнем интервью для uTest сообщивший что основной проблемой тестирования является сложность подбора хороших, годных метрик.

Школа Контроля (Качества)
Школа Контроля Качества больше фокусируется на стандартах и процессах. Согласно их утверждениям тестирование является своего рода хранителем продукта.

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

Подобный подход требует чтобы помимо ответственности у контролирующего были и возможности остановить выпуск продукта, если он считает, что продукт слишком низкого качества чтобы его выпускать. Я видел случаи, когда компании пытались применять подобные стратегии, но в итоге когда менеджменту действительно хотелось чтобы продукт увидел свет, ответственного QA лида просто отодвигали в сторонку и выпускали продукт несмотря на его качество. Очень неприятные ощущения, надо сказать. Ведь если у вас есть ответственность и обязанность говорить что продукт выпускать нельзя, но нет никакой возможности приостановить выпуск, то, возможно, скоро на вам станут смотреть как на того мальчика, который кричал про волков. Есть и другой вариант - "идеальное качество у того продукта, который так никогда и не был зарелизен".

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

Контекстная Школа
Контексттная школа это своего рода Agile Manifesto для тестировщиков. Оно базируется на следующих принципах:

1. Ценность любой практики зависит от контекста ее применения
2. Есть хорошие практики для определенного контекста, но нет лучших практик
3. Люди работающие вместе это самая важная часть контекста проекта
4. Проекты со временем могут развиваться совершенно непредсказуемымо
5. Продукт это решение. Если проблема не решена, то продукт не работает
6. Хорошее тестирование ПО это сложный интеллектуальный процесс
7. Только через суждения и навыки используемые совместно по всему проекту могут привести к выполнению правильных вещей в правильное время для того чтобы эффективно протестировать ваш продукт

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

Как и Agile Manifesto пообный подход для многих показался слишком открытым и абстрактным, к тому же он не дает серебряной пули на все случаи жизни, не дает лучших практик, которые всегда спасут. К тому же у ряда кампаний/проектов есть определенные, жесткие жизненные циклы, вокруг которых выстроены избыточные процессы, которым обязательно нужно следовать. В такой среде контекстное тестирование не очень часто приживается.

Школа Гибкого Тестирования

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

Эта школа концентрируется вокруг массовой автоматизации всего. TDD, unit тесты и так далее. Все это аттрибуты этой школы (нет, другие школы тоже их могут использовать, но гибкого тестирования без этого просто быть не может). Кто-то из тестировщиков может сказать что это все дела разработчиков, но ему стоит задуматься хотя бы над тем, что такие компании как Microsoft или Google отказались от концепции тестировщика, который занимается только тестированием и нанимают SDET - разработчиков, которые занимаются тестированием.

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

Весьма примечательно, что в истоках этой школы стоят очень хорошо подкованные технически представители Контекстной Школы и люди, которые никогда не называли себя тестировщиками и/или QA/QC.

Промежуточное Итого

Bret Pettichord фактически является автором этого разделения, которое основатели Контекстной Школы подхватили и начали использовать как базис для дискуссий. Представители остальных школ со временем тоже взяли это деление на вооружение, хотя тот же Борис Бейзер первое время утверждал что знать не знает ничего ни о каких школах и не желает в этом принимать участие. Но со временем и они втянулись.

Это привело к определенной поляризации сообества и, местами, к более жесткой риторике, поскольку теперь неприятель был снабжен соответствующим ярлыком.

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

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

Вместо Послесловия

У Контекстной Школы, породившей это разделение, было четыре основателя.

Brian Marick тихо ушел в сторону.

Bret Pettichord заявил, что Контекстное Тестирование это Гибкое Тестировние и тихонько ушел в ряды Гибкой Школы.

Cem Kaner написал, что школы нет, даже если она когда-нибудь была и всячески отрицает концепцию школ.

Остался James Bach, который агрессивно (что для него вполне нормально) отстаивает концепцию школ.

И, как я уже заметил в начале статьи - James Whittaker и Alberto Savoia практически сразу после своих замечательных выступлений на тему "Test is Dead" покинули Google, где занимали руководящие посты в тестировании.

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