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

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

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

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

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

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

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

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

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

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

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

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

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

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

Пост Мортемы Без Упреков и Культура Справедливости

В продолжение предыдущего поста:

Перевод статьи Джона Оллспоу "Blamelless PostMortems and a Just Culture"

На прошлой неделе Оуэн Томас написал лестную статью на Buiseness Insider о том, как мы в Etsy работаем с ошибками. Я думаю, что могу немного уточнить, как мы в действительности это делаем, и почему.

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

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

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

Это традиционный взгляд на "человеческие ошибки", сосредоточенный на особенностях вовлеченных в происшествие людей. Это то, что Сидни Деккер называет "Теорией Испорченного Яблока" - избавьтесь от испорченных яблок, и вы избавитесь от человеческих ошибок. Выглядит просто, не так ли?

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


Пост-Мортем Без Упреков

Что значит проводить Пост-Мортемы Без Упреков?
Значит ли это, что все могут делать ошибки и им это сойдет с рук? Нет.

Ну, может быть. Это зависит от того, что для вас значит "сойдет с рук". Позвольте мне объяснить.

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

Процесс Пост-Мортемов "без упреков" означает, что инженеры, чьи действия способствовали появлению катастрофы, могут детально описать:

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

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

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

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

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

Цикл "назови-упрекни-пристыди" выглядит примерно так:

1. Инженер что-то делает, и в результате становится соучастником сбоя или инцидента
2. Инженера наказывают, пристыжают, всячески упрекают, или отправляют на переобучение
3. Уменьшается доверие между инженерами "у сохи" ("острый конец") и менеджментом ("тупой конец"), занятым поиском козлов отпущения
4. Инженеры начинают замалчивать детали касательно действий/обстановки/наблюдений, что приводит к работе в стиле "Прикрой Свою Заницу" (из-за страха перед наказаниями)
5. Из-за молчания, упомянутого в предыдущем пункте, менеджеры получают меньше информации о том, как идет повседневная работа, а инженеры хуже информированы на счет спящих или скрытых обстоятельств, которые могут стать причиной катастрофы
6. Шансы ошибиться растут, скрытые обстоятельства невозможно определить из-за п.5
7. Переходим к п.1

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

Основной принцип здесь - это сказанное Эриком Холлнагелем:

Мы должны понимать, что катастрофа произошла не потому, что кто-то играл и проиграл.  

Катастрофы случаются потому, что кто-то верил что:  

...то, что только что случилось невозможно 

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

...или что вероятная выгода от сделанного стоит любых потенциальных рисков

Второй Уровень Понимания

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

Исходя из "За Человеческой Ошибкой" получается следующая разница между пониманием человеческой ошибки "первого уровня" и "второго уровня":

Первый Уровень Понимания	Второй Уровень Понимания
Человеческая ошибка стала причиной сбоя	Человеческая ошибка - это следствие системных уязвимостей в самой организации
Сказать, что  именно люди должны были сделать - это подходящий способ описать произошедший сбой	Рассказы о том, что люди должны были сделать, не объясняют, почему то, что они сделали, казалось для них разумным
Если мы скажем, что в следующий раз  надо быть более аккуратными, мы решим проблему раз и навсегда	Только постоянный поиск уязвимостей поможет организации улучшить безопасность

Позволяя Инженерам Владеть Своими Историями

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

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

Так что же мы делаем чтобы "Культура Справедливости" работала в Etsy?

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

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

С одной стороны, мы можем решить, что единственной причиной может быть только некомпетентность, и орать на инженеров "будьте внимательнее!" или "будьте аккуратнее!".

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

Вот почему мы в Etsy практикуем Пост-Мортемы Без Упреков, и по той же причине мы стараемся создать у себя Культуру Справедливости.

_______________________________________________________________

Примечания переводчика:

1. "Тупой/острый конец" это отсылка к модели причин несчастных случаев (модель "швейцарского сыра" это одна из них, да) Ричарда Кука и Дэвида Вудса. Я позже постараюсь о ней написать.

Спасибы rovena antary за то что обычный русский язык победил мой собственный русский язык

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Суммируем:

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

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

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

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

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

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

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

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

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

Грешки Автоматизатора. Часть 4. Выбор языка

Я как-то давно обещал написать по этому поводу пару строк - исполняю.

Еще ни один стартап не умирал из-за того, что выбрал неправильный дистрибутив Linux - Пол Хаммонд

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

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

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

Собственно главный критерий один - как хорошо лично вы знаете тот или иной язык. Все.

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

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

Вы не знаете никаких языков? Учите то, что проще учить - Ruby, Python (это просто пара примеров). Учить Java или еще какие C++ - это путь самурая, но не тот случай когда вам нужно как можно быстрее выучить необходимый минимум (а автоматизация - довольно узкая область, там нужен довольно ограниченный набор) для написания автоматических тестов и тестовой инфраструктуры. Да, какие-то языки было бы неплохо подучить, чтобы набить себе резюме, но это вообще не имеет отношения к выполнению задачи.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Круто?

Нет.

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

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

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

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

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

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

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

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

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

Роботу роботово

Without changing our pattern of thought, we will not be able to solve the problems we created with our current patterns of thought

А. Эйнштейн

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

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

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

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

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

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

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

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

Короче говоря - тест этот говно полное, а не тест.

Что мы можем сделать чтобы он перестал быть говном?

• Убрать лишние телодвижения
• Никаких сетапов в браузере (мелкий кусок API или хелпер на "создать псто" и мы уже сэкономили кучу сил и энергии)
• Никакой лишней навигации (хелперы/API на логин и переход к псто... да хоть директ линком в псто)
• Никаких тестов с сотнями проверок (в идеале один тест - один ассерт)
• Никаких трешевых тестов
• CRUD - ок
• Дешевые проверки на безопасность - ок
• Основной функционал - ок
• Выдирание алайнов элементов страницы и их стилей - в другой набор тестов пожалуйста
• И т.д.

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

Есть и другие причины почему мы можем писать плохие тесты. В них тоже никакой катастрофы нет, пока вы понимаете почему именно, и какие именно тесты плохие.

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

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

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

Более того - можно писать полу-автоматические тесты или всякие BVT. Там тоже свои критерии корректности влияющие на дизайн, но это уже другая история...

Микропост: Линкоблог

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

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

http://www.delicious.com/goblingame/

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

"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% больше. Маленькие шажки, которые становятся маленькими, но очень тяжелыми кандалами.

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