Not so critical

Свой велосипед

noreply@blogger.com (Pavel ) — Tue, 12 Nov 2019 10:03:00 +0000

Был на Highload++, слушал доклады.

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

* Здесь и далее буду называть "уникальные решения и разработки" велосипедами. Не потому, что в них есть что-то плохое (они, наоборот, как правило весьма достойны и хороши), а во-первых для краткости; во-вторых чтобы различать в тексте "решения", которые ментальное усилие выбора из нескольких вариантов, и "решения", которые программные системы и разработки; в-третьих сами докладчики их так называли.

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

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

Некоторые вообще никаких причин не упоминали, а просто рассказывали про свой велосипед.

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

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

Синдром not invented here
Люди недоразобрались с уже существующими велосипедами
Люди действительно столкнулись со специфической проблемой требующей своего специфического велосипеда

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

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

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

Нужно потратить время и силы (вообще говоря - без гарантии успеха).

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

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

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

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

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

XPath в картинках

noreply@blogger.com (Pavel ) — Sun, 23 Sep 2018 05:22:00 +0000

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

В целом XPath штука несложная, если разобраться с двумя основными концепциями: осями и предикатами.

XPath axes - оси XPath

Оси - это направления поиска относительно текущего элемента. Они помогают разбить документ на несколько множеств и указать, в каком из этих множеств искать нужный элемент.
Не все из существующих осей широко применяются в контексте веб-автотестов (например namespace:: не имеет особого смысла). Некоторые оси применяются постоянно, но не всегда это очевидно (self:: или descendant-or-self::).

Список существующих осей:

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

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

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

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

Ось self:: позволяет обратиться к текущему элементу, если это зачем-то нужно.

Краткая нотация этой оси - точка.

У элемента есть предки и потомки.

Предки - элементы, расположенные на пути от корня дерева до текущего элемента. Множество предков лежит на оси ancestor::.

Потомки - элементы, расположенные в дереве ниже текущего элемента. Они лежат на оси descendant::.

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

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

Кстати, все приведённые пути начинаются точки, то есть с оси self::, чтобы задать текущий элемент в качестве точки отсчёта. Без этой точки поиск начнётся от корня дерева.

Также стоит отметить правило нумерации: элементы оси всегда нумеруются относительно текущего элемента: ближайший элемент имеет номер 1, следующий 2 и так далее. Можно искать среди всех элементов лежащих на оси или указать имя тега, чтобы сузить пространство поиска. Соответствующим образом меняется нумерация: так, td11 - четвёртый среди всех потомков, но третий элемент td среди потомков. Поэтому запросы ./descendant::*[4] и ./descendant::td[3] в данном случае эквивалентны.

Следующие две оси - parent:: и child::, означающие, соответственно, родителя (он всегда ровно один, если речь не о корневом элементе) и детей текущего узла.

У этих осей есть краткие нотации.

Примеры поиска элементов на этих осях:

Идём далее.

Предшествующие (preceding::) и последующие (following::) элементы.

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

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

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

Ещё две интересные оси - preceding-sibling:: (предшествующие братья или старшие братья) и following-sibling:: (последующие или младшие братья).

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

Примеры XPath для этих осей:

Кроме перечисленных, есть ещё несколько осей, которые на этих картинках не видны.

Ось атрибутов attribute:: (или @ в краткой нотации) позволяет обратиться к атрибутам элементов: например, атрибуту href элемента а9.

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

node() - узловые элементы документа.

* - узловые и текстовые элементы.

Также есть оси ancestor-or-self:: и descendant-or-self::, смысл которых ясен из названия, и которые редко используются в явном виде.

Зато часто используется запрос /descendant-or-self::node()/ более известный виде краткой нотации //.

На этом про оси всё. Напоследок ещё раз список осей, с краткими нотациями:

Предикаты XPath

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

На самом деле в примерах выше постоянно использовался простейший предикат - указание позиции элемента.

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

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

Пример ниже показывает, какое множество элементов находит тот или иной запрос в HTML коде справа.

Также популярны предикаты работающие текстом внутри элемента: "text()" и ".".

На первый взгляд они выглядят похоже: оба запроса для span на картинке ниже возвращают одно и то же.

Однако если посмотреть на запросы для кнопок - возникают вопросы:

//button[text()="Click"] не находит ничего,
//button[.="Click"]] находит нужную кнопку, а
//button[.="Press"]] вновь ничего не находит.

Причина в том, что предикат text()="something" ищет элемент, у которого есть собственный текстовый узел с таким значением. А .="something" ищет элемент, текстовое представление которого совпадает с указанным значением. При этом текстовое представление элемента учитывает все текстовые узлы внутри элемента - как собственные, так и дочерних элементов. Иными словами, тестовое представление узла - это конкатенция всех текстовых узлов внутри элемента.

Поэтому

//button[text()="Click"] не находит ничего - ведь "Click" содержится не в собственном текстовом узле кнопки,
//button[.="Click"]] находит нужную кнопку: текстовое представление кнопки именно "Click"
//button[.="Press"]] вновь ничего не находит, так помимо "Press" текстовое представление кнопки содержит ещё и два переноса строки.

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

Хороший XPath

Напоследок некоторые мысли, что отличает "хороший" XPath-запрос от "плохого" в контексте веб-тестирования.

Хороший XPath должен быть

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

Все эти критерии ситуативны и требуют применения здравого смысла.

Обычно не возникает проблем с точностью и скоростью поиска.

С другими тремя пунктами сложнее.

Чтоб было понятнее, о чём речь, приведу примеры.

Не уникальный XPath: //span[contains(text(), 'already exists')] - сложно сказать сколько подобных элементов окажется на странице. Хотя, в контексте конкретного теста мы можем точно знать, что такой элемент ровно один.

Хрупкий XPath:

//span[text()='Open']/../../button[contains(@id, 'actions-button-%s')]
//span[contains(text(),'%s')]/..//div[@class='panel']/div/span/div/span[3]//span[1]

Лесенки вверх (../../), длинные списки элементов (/div/span/div/span[3]//span[1]) это те места, которые могут легко и неожиданно ломаться при изменении веб-страницы.

Лесенки в большинстве случаев можно устранить, используя вместо них предикаты и вложенные запросы
//button[span[text()='Open']][contains(@id, 'actions-button-%s')]

Не лаконично-описательный XPath:

//span[@aria-label='%s. Press the Enter key.']/../..
//p[text()='%s']/../../../td[1]/input
//td[text()='%s']/following-sibling::td[count(//div[@id='usage_stat']//th[text()='Amount']/preceding-sibling::th)-1]

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

Кстати, эти не лаконично-описательные XPath'ы одновременно ещё и хрупки. Есть ощущение, что часто эти свойства ходят парой: если сломано одно из них, до и другое скорее всего тоже.

Иногда полезно вообще попробовать использовать вместо XPath другой инструмент. Например, вместо построения сложного запроса ищущего что-то в таблице (&lttable&gt), может оказаться проще вычитать всю таблицу в хэш-таблицу (aka мапу, словарь) и потом вычитывать нужные данные оттуда.

Ссылки

Несколько полезных ссылок, помогающих разобраться с XPath:

https://msdn.microsoft.com/ru-ru/library/ms256086(v=vs.120).aspx

http://scraping.pro/5-best-xpath-cheat-sheets-and-quick-references/

http://pragmatictestlabs.com/2016/09/27/mastering-xpath-for-selenium-test-automation/

https://ru.wikipedia.org/wiki/XPath

На этом всё.
Хороших XPath'ов.

Качественный субъективизм

noreply@blogger.com (Pavel ) — Fri, 22 Apr 2016 11:08:00 +0000

Один из серьёзных нюансов с качеством ПО с точки зрения разработки: уровень этого самого качества в изрядной степени субъективен.

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

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

И да, отмечу, фраза "каждый легко найдёт оправдания и объяснит, почему налажал не он" не должна вводить в заблуждение. Злобные мудаки встречаются всё же не очень часто (ну или я избалован работой в продуктовой компании). Никто не стремится саботировать. Просто каждый работает так, как видит возможным. Через голову не перепрыгнешь. Если есть из критериев качества только и прежде всего соответствие требованиям, то от них и будет каждый отталкиваться. В меру своего формализма, бодрости, семейных радостей и физического здоровья.

Я как аналитик сделал всё возможное: проанализировал ожидания и возможности, проконсультировался с инженерами. Несколько раз скорректировал требования по мере проявления нюансов.

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

Я как... Ой, а всё, никого ж не осталось. Релиз.

Я как руководитель RnD недоволен, что мне на совете директоров рассказывают про баги в продукте. Каждый из инженеров видел проблему, и никто её не починил (а то и не заметил).
В этой войне авторитетов "рядовой тестировщик" равно как и "рядовой разработчик" с формальной точки зрения не всегда может показать что продукт - ну не готов к использованию. Есть те, кто более равны и есть формальные требования.

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

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

Всяко это лучше и полезней, чем пытаться понять, что таск-трекер может сказать о качестве продукта (QA квартирник Codefest'а, привет). Таки таск-трекер для задач, а качество для людей. Давайте у людей и спрашивать о качестве.

SUT с человеческим именем

noreply@blogger.com (Pavel ) — Thu, 10 Dec 2015 11:06:00 +0000

Допустим я тестирую продукт, который работает [в том числе] с "человеческими данными".

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

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

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

Например, вдруг оказалось, что в некоторых местах даже не очень длинные имена банально не влезают в отведённое пространство. Тут средней длины имя домена, тут фамилия пользователя, и вот емейл созданный по шаблону либо вылезает за границу поля, либо не виден полностью, либо появляется горизонтальная прокрутка на сайте, или ещё какое чудо случается. В первый раз очень удивляет: "обычный!"-то pb@pb1209.com нормально помещался, ничего не съезжало.

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

То же и при работе с названиями учреждений и компаний. Например, список ВУЗов города содержит много записей с одинаковым началом "Китежгородский государственный …" а до остального еще поди дотянись глазом. С выдуманными названиями можно и не обратить внимания, а с настоящими сразу приходит мысль, что хорошо бы указывать ещё и аббревиатуру на видном месте: тогда проще не спутать КГУ, КГИТ, КГМУ и т.п. То есть [почти] настоящие имена и названия помогают увидеть, обо что споткнётся пользователь - и вовремя улучшить эти коварные места.

Что до классов эквивалентности, то отчасти и их можно тестить с помощью настоящих имён. Так, по интернетам ходят слухи, что самое длинное имя содержит более 1000 символов. Как, обработает такое имя наш продукт? Или - имя не может быть длиннее 128 символов (БД ведь не резиновая)? А как насчёт имён, состоящих из нескольких слов и включающих в себя пробелы? Понятно, что индустрия таких людей не балует, они уже не ждут многого от IT и давно научились указывать краткое имя. С другой стороны - толика уважения, возможность указать полное имя, - такие вещи подкупают людей.

Так что теперь я использую имена и названия похожие на настоящие. Или - просто настоящие. Это привело к паре побочных эффектов. Первый из них: продукт тоже стал "более настоящим". Используя фейковые и тестовые имена я не мог отделаться от ощущения, что я не коммерческий продукт работаю, а играю в kind of компьютерной игры. Найди проблемы в продукте и добейся чтоб починили. Ачивку нарисуешь себе сам. А вот поверить, что продукт кто-то где-то по-настоящему использует - толком не получалось. То есть я знал, я видел проблемы утекшие к клиентам, обсуждал случившиеся на продакшенах фейлы, но ощущения что "всё по-настоящему" не было. С нормальными именами это ощущение стало появляться. Потому что в списках, формах и т.д. - не ерунда какая-то, не "абырвалг", а человеческие имена, адреса, телефоны, названия и прочая "ГлавРыба". К ним уважения и сочувствия больше.
Второй сайдэффект - для некоторых любимых имён потихоньку вырисовываются роли и профили. Что этот конкретный Имя Фамилия знает, любит, не любит, что хочет от продукта и как к нему относится. Всякая такая вот ерунда. Понятно, что эта Америка давно открыта, и подобные персонажи уже классика UX. Просто тут это само собой появляется, всего лишь оттого, что используются нормальные имена, которые сами навевают ассоциации. И да, нет необходимости формально определять и расписывать персонажей. Иногда они живут всего лишь одну-две тестовых сессии. Но успевают помочь по-разному глянуть на продукт.

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

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

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

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

Уважение к старшим

noreply@blogger.com (Pavel ) — Fri, 13 Nov 2015 11:03:00 +0000

С легаси кодом не просто.

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

Это такой код, который, с одной стороны, хочется радикально улучшить, а с другой - лучше к нему не прикасаться.

Так вот знаешь, что? Уважай его.

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

Он окончательно устарел и пришло-таки время всё исправить? ОК, не вопрос, давай исправлять. Но смотри внимательно: шрамы на старом коде - это следы древних багов. Будешь небрежен - и те же баги повторятся уже в новом коде.

Это легаси. Уважай его.

Сказка о неразобранных автотестах

noreply@blogger.com (Pavel ) — Thu, 29 Oct 2015 11:00:00 +0000

Жил был проект, а в проекте делали продукт, а у продукта была веб-морда, и нужно было ту веб-морду тестировать, и были автотесты ("Selenium" - подумал Штирлиц) для всех и всяческих сценариев. Автотесты регулярно запускали на свежих билдах, они достаточно быстро выполнялись и радовали всех "зелёными" результатами. "Красные" результаты быстро исследовали, чинили проблему, и каждый следующий запуск был "зеленее" предыдущего. Скоро сказка сказывается, да не скоро дело делается.

У меня есть друг, у которого есть друг, знакомый которого рассказывал про человека… На одном из местных TechTalk'ов зашла речь про автотесты, и выяснилось, что "в реальном мире это не работает". Тут нужен дисклеймер. Сам я на том техтолке не был, это мне коллега рассказал, как люди болью делились. Мол, продукты хорошие, автотесты тоже в целом есть, и запустить их не проблема. Проблема - разобрать результаты работы автотестов. Что выполнилось, что упало, где баг, где косяк автотеста - вот это всё. Не хотят люди результаты разбирать - неинтересно им как-то, что ли… И что с такими неразобранными результатами делать? Как заставить, нет "заставить" слово нехорошее, как мотивировать человека разобрать-таки результаты автотестов?

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

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

От результата

Нам ведь не нужны результаты автотестов. Нам нужно квалифицированное и обоснованное знание о состоянии продукта. Не хочешь возиться с автотестами, можешь не возиться. Главное - это самое знание предоставь. Как - дело десятое. Можешь "руками" всё пройти, можешь еще как-то. Лишь бы работало, было воспроизводимо и в разумные сроки. В общем, ты сам кузнец своей задачи.

От процесса

Ты за автотесты, но ведь нудятина же невозможная? Да, всё так, согласен. Но уйти от рутины совсем - не получалось никогда и ни у кого. Кроме Карлсона, но супергерои не в счёт. Рутина есть и будет, на каждом сколько-нибудь долгом проекте; это надо принять как неизбежность. Но можно варьировать количество рутины на каждую персональную душу населения.
Простой вариант: ротировать ответственность. Две недели я отвечаю за разбор автотестов, две недели ты, потом отдадим третьему. Всё честно, все страдают по очереди. Но отлынивать в свою очередь - нельзя, результат должен быть готов в срок.

Другой вариант - поделить весь большой сет автотестов на куски. Самые приоритетные выделить в отдельный пул и сперва выполнять только их, а остальные - пореже и только если Top-Priority тесты "зеленые" (вы слышали, он сказал "build verification test", он правда это сказал). Этих самых Top-Pri тестов не должно много получаться. Если какой-то из Top-Pri тестов, будучи "красным", не блочит 10% общей массы тестов, то может он и не Top-Pri.
Вообще, вариантов подобного перераспределения рутины можно придумать немало - лишь бы помогали работе.

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

От инструмента

А может, всё проще и достаточно допилить инструменты, чтоб они помогали разбору результатов АТ (о, вот она, Важная Задача, которой я буду отмазываться в следующий раз).
Как эти результаты выглядят? Легко ли отфильтровать из общей массы только "красные" тесты? Легко ли понять, что делал каждый "красный" тест и в каком месте свалился? Можно ли сгруппировать тесты, упавшие с похожими причинами? Можно ли указать для каждого теста соответствующий баг в трекере? Можно ли подтянуть для "красного" теста баг с прошлого запуска? Может ли разобраться в логике теста человек, не знакомый с внутренним устройством автотестов, - просто глядя на результаты выполнения?

Неказистый инструмент может серьёзно затруднить работу. Хороший и удобный инструмент не избавит от работы, но поможет её делать быстрее и качественней.

От проблем

Да нет, говоришь, это всё понятно, говоришь, но что толку, если половина падений тестов - это не баги продукта?

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

Ну что тут скажешь. Время исправлять грехи молодости: стабилизировать АТ, разбираться с настройками, учить роботов…

Или - придумать как получать всё-таки пользу от таких АТ.

От себя

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

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

Сказка ложь, да.

Разработка и Продажи

noreply@blogger.com (Pavel ) — Tue, 13 Oct 2015 10:57:00 +0000

Продажи (падают из-за кулис на сцену и смирно лежат).
Разработка (выходит, спотыкается об Продажи и падает): Вот черт! Никак об Продажи!
Продажи    (поднимаясь): Мерзопакость какая! Отдохнуть не дадут! (Идут, спотыкаются об Разработку и падают). Никак об Разработку спотыкнулися!
Разработка (поднимаясь): Ни минуты покоя! (Идет, спотыкается об Продажи и падает). Вот черт! Никак опять об Продажи!
Продажи    (поднимаясь): Вечно во всем помеха! (Идут, спотыкаются об Разработку и падают). Вот мерзопакость! Опять об Разработку!
Разработка (поднимаясь): Хулиганство! Сплошное хулиганство! (Идет, спотыкается об Продажи и падает). Вот черт! Опять об Продажи!
Продажи    (поднимаясь): Это издевательство сплошное! (Идут, спотыкаются об Разработку и падают). Опять об Разработку!
Разработка (поднимаясь): Вот черт! Истинно что черт! (Идет, спотыкается об Продажи и падает). Об Продажи!
Продажи    (поднимаясь): Мерзопакость! (Идут, спотыкаются об Разработку и падают). Об Разработку!
Разработка (поднимаясь): Вот черт! (Идет, спотыкается об Продажи и падает за кулисы). Об Продажи!
Продажи    (поднимаясь): Мерзопакость! (Уходит за кулисы).
За сценой слышен голос Продаж: "Об Разработку!"
Занавес

P.S. Основано на вымышленных событиях

Связанные многочисленными ниточками

noreply@blogger.com (Pavel ) — Sat, 25 Oct 2014 09:50:00 +0000

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

Ниже — перевод статьи «Dependency Management in a Large Agile Environment», опубликованной компанией Salesforce.com. В статье рассказано, как компания решала проблемы взаимодействия команд разработки на крупном проекте. Многие подходы выглядят очень полезными.

Стоит потратить пять минут на чтение.

Краткий обзор
Департамент разработки Salesforce.com включает в себя более 30 Scrum-команд, совместно работающих над общим кодом в одной и той же ветке системы контроля версий. Статья описывает методы, используемые salesforce.com для масштабирования Scrum-подхода и для управления межкомандными взаимосвязями.

1 Введение
В октябре 2006 года начался грандиозный переход отдела разработки (R&D) salesforce.com от модели водопада к гибким методологиям, основанных на Scrum. На тот момент прошло 10 месяцев с предыдущего мажорного релиза, а дата выпуска нового переносилась уже пять раз. Многих расстраивало, что продукт выпускается редко и с серьёзными опозданиями. Мы не стали дожидаться завершения релиза, реорганизовали существующие команды в Scrum-команды и с помощью процессов Scrum выпустили релиз в феврале 2007 года. С тех пор, используя наш новый гибкий подход, мы выпустили уже пять мажорных релизов (длительностью в 3-4 месяца) нашего набора SaaS приложений и платформы Force.com. Каждый из них состоялся точно в запланированный день.

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

2 Структура команды
Разработка продукта в salesforce.com состоит из трех подразделений: Applications, Platform и Core Infrastructure. Эти три подразделения суммарно содержат более 30 Scrum-команд. В каждой Scrum-команде есть разработчики, тестировщики и Product Owner, а также Scrum Master (обычно это руководитель разработчиков или тестировщиков либо Program Manager). Для сложных фич Scrum-команды также привлекают представителей других функциональных команд, например System Testing, Documentation, UI Design, Usability, Technology Operations, Release Engineering. Обычно все Scrum-команды работают над одним и тем же релизом в одной и той же ветке кода. Наши продукты связаны между собой, поэтому фичи разных команд могут очень тесно переплетаться — как функционально, так и технически. С точки зрения технической реализации многие команды используют общий код. С точки зрения функциональности команды, работающие над фичами для одного и того же конечного пользователя, должны тесно сотрудничать, чтоб создать гармоничный и согласованный user experience.

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

3.1 Сложность системы
Выявление зависимостей — первый шаг к управлению ими. Подобно многим зрелым продуктам, системы salesforce.com слишком сложны, чтобы один человек или команда были способны знать и помнить все взаимосвязи. Чтобы выявить и осознать зависимости, нам все чаще приходится полагаться на коллективные знания множества людей. Крайне важно объединять такие знания и связывать людей, обладающих информацией, с людьми, нуждающимися в ней. Ключевую роль в определении зависимостей и последствий предлагаемых изменений играют эксперты с широким пониманием системы. Однако по мере роста и усложнения системы трудно избежать специализации и дробления знаний. К тому же при текущем количестве изменений нецелесообразно просить экспертов проверять детали каждой новой фичи. Нужен способ выявлять изменения, с высокой вероятностью влияющие на (или зависящие от) работу других команд, чтобы уделить таким изменениям особое внимание. Конечно, сделать это не так просто, поскольку порой сравнительно небольшие изменения серьёзно влияют на всю систему.

3.2 Конфликт приоритетов
Зависимости могут приводить к конфликтам между командами. Если одна команда хочет, чтоб другая команда что-то сделала, то Product Owner’ы этих команд обсуждают и определяют приоритет этой работы. Если по итогам обсуждения удается договориться о сроках выполнения, то в дальнейшем управлять этой зависимостью довольно просто. Если внятное соглашение не достигнуто, или если приоритет работы все еще низок, то неопределённость и уровень рисков вокруг данной зависимости возрастают. Также конфликты возникают, когда одна команда вносит изменение, добавляющее работу другой команде. Например, когда одна команда изменяет архитектуру, так что остальным надо приспособиться к этим изменениям. Изменение не всегда приносит очевидную пользу другим командам, так что иногда люди обижаются и возмущаются появлением дополнительной работы, особенно когда она появляется внезапно. Мы стараемся выявлять такие зависимости на ранних этапах, но некоторые из них неизбежно появляются позже — вследствие уже внесенных изменений либо после пересмотра приоритетов.

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

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

4 Специальные подходы
В этом разделе мы обсудим конкретные подходы, которые мы используем, чтобы управлять зависимостями и справляться с вышеперечисленными проблемами. Общие стратегии, используемые в этих подходах:

Сделать общеизвестным — планы на релиз, взаимосвязи, проекты, статус билдов, и т.д.;
Организовать площадки для обсуждений и обмена знаниями между командами;
Поощрять самоорганизацию и децентрализованное управление взаимосвязями;
Автоматизация, автоматизация и еще раз автоматизация.

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

Кроме того, после собрания планы команды на релиз становятся общеизвестными. Мы стремимся добиться высокой осведомленности о том, чем занимаются все команды, поскольку верим, что это заставляет людей обдумывать и обсуждать взаимосвязи. В стартовом собрании участвуют все руководители R&D, что помогает привлечь людей и сосредоточить внимание на планировании релиза. Высокий уровень участия помогает согласовать ожидания и информировать правление о планах на релиз.

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

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

Сессия выявления взаимосвязей устроена довольно просто. Представители (чаще всего Scrum Master или Product Owner) всех Scrum-команд собираются в комнате с большой доской. В первой части сессии все участники одновременно рисуют на доске две диаграммы зависимостей между командами. Одна диаграмма изображает команды, которым нужно, чтоб другая команда сделала что-то для них. Вторая диаграмма изображает команды, делающие нечто, что повлияет на работу других команд. Мы используем несколько простых правил для этих диаграмм:

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

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

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

Рис.1. Пример диаграммы межкомандных зависимостей

4.3 Открытые обсуждения
С недавних пор в течение недели после стартового собрания мы проводим открытые встречи, главная цель которых — создать площадку для обсуждения вопросов и проблем, связанных с планами команды на релиз. Мы просим, чтоб на этих встречах был хотя бы один представитель от каждой Scrum-команды, в остальном они необязательны для посещения. Обычно в начале открытой встречи участники предлагают темы для обсуждения. Далее в течение 45 минут проходят обсуждения тем в группах, а затем группы рассказывают остальным о результатах обсуждения. Чаще всего участники хотят узнать детали новой и полезной функциональности, а также об изменениях, которых повлияют на другие команды. Участники открытых встреч отметили поучительность таких обсуждений, кроме того людям оказалось интересно общаться с коллегами из других команд, с которыми они не взаимодействуют в обычной работе. Открытые встречи пока что новый формат для нас, так что мы пробуем разные варианты, чтоб понять, что работает лучше, например:

Предлагать идеи тем до начала встречи;
Привлекать к участию высокое начальство;
Менять количество и длительность дискуссий.

4.4 Обзор дизайна
Основная цель собраний по обзору дизайна функциональности — повысить общий уровень качества и удобства наших продуктов, с помощью:

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

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

Существует два основных типа таких собраний. На ранних этапах релиз-цикла участники фокусируются на концепциях дизайна и стремятся достичь согласованности и эффективного взаимодействия между существующими и новыми фичами. На этой стадии в собраниях обычно участвуют Product Owner’ы и дизайнеры пользовательского интерфейса (UI), и изредка представители других функциональных команд, таких как разработка и QA. Примерно в середине релиз-цикла состав участников меняется: теперь это в основном представители QA и отчасти разработки, а обсуждения сосредоточены на деталях реализации. Эти встречи обеспечивают понимание и ясность относительно:

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

4.5 Виртуальная команда архитектуры
Виртуальная команда архитектуры (Virtual Architecture Team, VAT) — «виртуальна», поскольку включает в себя разработчиков из всех Scrum-команд. Члены команды работают в VAT без отрыва от основных обязанностей в рамках Scrum-команды из бизнес-подразделений Applications, Platform или Core Infrastructure.

VAT отвечает за поддержку и развитие архитектуры нашего ПО. Команда определяет дорожную карту (road map) развития архитектуры, проводит обзор серьезных изменений с точки зрения архитектуры, определяет стандарты кодирования, чтобы обеспечить совместимость и поддерживаемость кода.

VAT управляет бэклогом важных архитектурных проектов и необходимого рефакторинга. По мере развития продукта нам приходится перепроектировать фичи и избавляться от старого неоптимального кода. Порой разработчики не хотят менять уже работающие программы, даже когда они понимают, что код программы оставляет желать лучшего. Product Owner’ы предпочитают видеть, как разрабатываются новые фичи, а не как переделывается нечто уже работающее. Чтобы противостоять таким настроениям, каждое наше бизнес-подразделение обязано запланировать не меньше 20% времени в каждом релизе на изменения рекомендованные VAT.

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

4.6 Непрерывная интеграция
Наша веб-инфраструктура автоматизированной сборки, тестирования и сортировки (triage) обеспечивает непрерывную интеграцию билд-системы и позволяет отслеживать состояние каждой строчки кода. Эта инфраструктура — ключевой аспект, позволяющий всем разработчикам и QA инженерам работать с общей базой кода.

Главный набор тестов построенный на расширении JUnit дает возможность создавать функциональные тесты с помощью API Force.com. Кроме того, у нас есть фреймворк для тестирования пользовательского интерфейса, использующий Selenium для автоматизации тест кейсов, которые нужно выполнять через UI.

Вот несколько фундаментальных принципов, определяющих наш подход к автоматизации:

Давать разработчикам быструю обратную связь, чтобы они видели результаты своих изменений. Каждый коммит запускает сборку билда и выполнение набора тестов. В случае ошибки ответственные инженеры сразу же получают сообщение о сбое. Базовый набор тестов выполняется за полчаса, и разработчик получает результаты проверки внесенных им изменений. Периодически в течение дня выполняется расширенный набор тестов;
Быстро чинить сборку и сбои тестов. Для этого у нас есть роль «мастера сборки», меняющая владельцев каждую неделю. Обычно эту роль выполняют два тесно взаимодействующих человека — менеджер разработки и старший разработчик. Мастер сборки отвечает за проверку результатов сборки, отслеживание тестовой истории и сбоев на различных строчках кода, а также назначение багов конкретным разработчикам для починки. У нас есть специальная панель, отображающая различные метрики исходя из собранных в базе данных результатов тестов (доля успешных тестов, время сборки, количество сбоев и т.д.). Мастер сборки использует эти данные при подготовке отчета о состоянии сборки;
Поддерживать высокий уровень покрытия автоматизированными тестами. Обычно Scrum-команды стремятся покрыть автоматизированными тестами 70-80% кода. Один из наших важнейших активов — большой набор автотестов, играющий ключевую роль в поставке качественных релизов в срок каждые 3-4 месяца.

4.7 Scrum-of-Scrums
В каждом бизнес-подразделении еженедельно проводится собрание Scrum-of-Scrums, существует и » Scrum-of-Scrum-of-Scrums». Иногда мы организуем дополнительный Scrum-of-Scrums для группы команд, тесно взаимодействующих при работе над общей целью. Мы опробовали несколько различных форматов проведения Scrum-of-Scrums. Мы начали со стандартного формата «4 вопроса», когда команды сообщали, что они сделали, что собираются делать, что их блокирует, и делают ли они что-то влияющее на работу других команд. Поначалу это работало, но вскоре стало утомительным и скучным из-за большого количества команд. Тогда мы перешли к более открытому формату самоорганизации, когда участники предлагали темы для обсуждения, выписывая их на доске в начале собрания. Это заставило участников взять на себя ответственность за содержание митинга и привело к более продуктивным обсуждениям. Вопрос межкомандных зависимостей часто поднимается во время Scrum-of-Scrums, особенно на ранних стадиях разработки. Сессия распознавания взаимосвязей проводится во время Scrum-of-Scrums, и в последующие две-три недели на этом собрании часто обсуждаются изменения в межкомандных зависимостях.

4.8 Отчеты о состоянии
Когда команда переходит на Scrum, письменные отчеты часто становятся не нужны, поскольку ясность состояния теперь обеспечивается за счет других вещей (обзоры спринтов, burndown chart, ежедневные стендап-митинги). Когда мы перешли на Scrum, то решили сохранить облегченные еженедельные отчеты о статусе, которые готовит каждый Scrum мастер. Это выглядело избыточно пока мы использовали формат «4 вопроса» для Scrum-of-Scrums. Однако при нынешнем открытом формате Scrum-of-Scrums еженедельные отчеты стали важным дополнением к этому собранию. Мы не обсуждаем состояние каждой команды во время Scrum-of-Scrums, если только это не вынесено как отдельный вопрос, однако этот статус всегда доступен в еженедельном отчете. В отчете обозначены все зависимости, блокеры и риски. Конечно, такие отчеты требуют немного дополнительных усилий от Scrum мастеров, но ясность, которую они обеспечивают, оправдывает затраты на их создание.

5 Заключение
Salesforce.com доказала, что масштабирование Scrum осуществимо, и мы уверены, что сможем продолжать такое масштабирование по мере роста компании. По мере роста количества команд, управление взаимосвязями и межкомандная координация становятся непростой задачей. Критически необходима надежная инфраструктура сборки и автоматизированного тестирования. Очень помогает повышение осведомленности и синхронизация с помощью стартового собрания, сессии выявления взаимосвязей, Scrum-of-Scrums и облегченных отчетов о состоянии. В конечном итоге это приводит к эффективному общению, взаимодействию и обмену знаниями между командами. Такие подходы, как виртуальная команда архитектуры, открытые обсуждения и Scrum-of-Scrums призваны помочь общению и поддержать взаимодействие.

100500 конфигураций.

noreply@blogger.com (Pavel ) — Wed, 03 Oct 2012 02:55:00 +0000

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

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

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

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

Начнем с относительно простой ситуации, когда заказчик и покупатель у нас один. Этот случай проще, так как мы можем довольно точно узнать, как [будет] настроена его система, и отбросить остальные варианты. Даже в этом случае возможны проблемы: не всегда удается в тестовой лабе воспроизвести масштаб и сложность боевой системы. Ок, давайте тестировать в «похожем окружении».

Вот тут важный вопрос – что такое это «похожее окружение»? Чем оно похоже на боевое, а чем отличается? Если ответ неизвестен – то и результат тестирования не вполне понятен. Зная ответ – уже можно понять, что мы можем адекватно проверить, а что нет, в каких местах могут потом появиться проблемы; можно подумать, как все-таки проверить эти проблемные точки (возможно – за пределами тестовой лабы).

Если покупателей много, то они обычно используют продукт по-разному – в разных условиях, с разными настройками. Чаще всего проверить все условия/настройки в срок невозможно, зато мы можем как-то расставить приоритеты. Более популярные конфигурации тестировать тщательней, менее используемые – поверхностно. Цель в том, чтоб избавить от проблем основную массу пользователей. Да, мы что-то можем упустить для редко используемого случая, но это заметят сравнительно немногие.

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

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

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

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

Тут тоже, конечно, есть важный момент, и далеко не один. У крупного клиента могут случиться свои проблемы, и лабу он не предоставит. Или предоставит, но доступ туда будет такой заковыристый, что тестировать невозможно. Или пообещает сам протестировать, и не успеет вовремя дать фидбек. А в случае массовой беты – можно утонуть в непрофессиональных багрепортах, не разобраться в приоритетах найденных багов, пропустить «явно невероятную» проблему в релиз. В любом случае, запуская бету, подумайте, когда и какую обратную связь вы ожидаете, как вы собираетесь с нею работать, и как результат беты может повлиять на текущие планы по выпуску продукта.

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

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

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

4k+ знаков про ТО

noreply@blogger.com (Pavel ) — Mon, 10 Sep 2012 02:35:00 +0000

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

Тестовое окружение (ТО) может готовиться заранее, а может «возникать» прямо в момент выполнения теста. Разным проектам нужны разные ТО, что естественно. ТО меняется вместе с развитием продукта, требованиями к нему, бюджетом и пониманием роли тестирования. Короче, как водится, идеального-вообще ТО не бывает, бывает – адекватное здесь-и-сейчас, решающее текущие задачи при данных обстоятельствах (ну и желательно с каким-то заделом на обозримое будущее).

Говорят, хороший интерфейс ПО – тот, который пользователь «не замечает», а просто решает свои задачи, работая с программой. Про ТО можно сказать что-то подобное: чем проще подготовка и выполнение тестов, воспроизведение дефектов, работа с прочими артефактами, тем лучше ТО. Чем меньше мы спотыкаемся о разложенные нами же грабли, не относящиеся к тестируемому продукту, тем больше мы спотыкаемся о грабли в продукте, разбросанные разработчиками. А этого от нас и ждут, ага.

Создание такого ТО, понятно, требует труда. По сути, это такой сопутствующий проект – со своими требованиями, дедлайнами и потребителями. Скорее всего, этот проект будет длиться не меньше, чем собственно разработка system under test (SUT). От этого проекта серьёзно зависит успех производимого продукта.

Можно выделить несколько требований, актуальных для большинства ТО.

Применимость
ТО должно отвечать поставленным задачам. Железо должно соответствовать требованиям к SUT. Хорошо бы, чтоб конфигурации были подобны тем, что используются в боевом режиме (или мы хотя бы знали diff).
Конечно, ТО должно позволять выполнить необходимые тесты и прочие активности. Должна быть возможность проверить различные важные конфигурации (поддерживаемые ОС, БД, локализации, и т.д.). В общем, тестировщики должны иметь возможность тестировать, иначе зачем всё?

Изолированность
По-хорошему, SUT должна запускаться на отдельных серверах, реальных или виртуальных. Это не должны быть сервера разработчиков. Это не должны быть рабочие станции сотрудников. Это не должны быть сервера взятые на час взаймы у соседнего отдела.
Подобная изолированность защищает, с одной стороны, от особенностей конфигурации отдельных машин. С другой – от потери данных из-за нестабильности SUT. С третьей – упрощает контроль за состоянием SUT и конфигурациями, обеспечивает воспроизводимость тестов. Ладно, даёт шанс обеспечить воспроизводимость.
В более долгосрочной перспективе – позволяет настраивать нетривиальное окружение, варьировать настройки и подходы, проверять идеи и подозрения. Масса пользы в общем.

Доступность и простота
Если нет каких-то особых причин для обратного, ТО должно быть легко доступно для всех, кто с ним работает – тестировщиков, программистов, аналитиков и других интересующихся.
Не должно быть проблем с созданием нового экземпляра SUT в требуемой конфигурации.
Нам нужна возможность без особых затрат отслеживать состояние и использование ТО – что где находится и почему, кто использует тот или иной объект (например, копию SUT), где у нас есть свободные ресурсы, и т.д.
По возможности следует исключить конфликты использования общих ресурсов/объектов.
Если отдельные проверки требуют специфичных данных, имеет смысл их подготовить заранее и сложить в какое-то общее хранилище. Не в ущерб качеству тестов, конечно.

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

Стабильность
Пусть SUT сколь угодно нестабильна, ей можно, а ТО должно быть здоровым и непотопляемым. Тут стоит задействовать практики рекомендованные системным администраторам (кстати, невредно с ними проконсультироваться, если есть с кем) – мониторинг состояния железа, контроль нагрузки на сервера, регулярные бэкапы и подготовка сценариев на случай внезапной смерти Самого Важного Сервера…
В общем, все, что выглядит нужным и применимым.

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

Привет, Аноним в поисках вопросов

noreply@blogger.com (Pavel ) — Mon, 16 Apr 2012 02:08:00 +0000

Внезапно мне пришёл комментарий:

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

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

Добрый день, Аноним.

Краткость – сестра таланта, поэтому я никогда не умел излагать коротко (и с годами – всё хуже). Так что я даже и ответов дам несколько.

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

Совсем бессмысленный ответ (я испорчен массовой культурой, да): Перефразируя писателя Пелевина, можно сказать так: «Очень общее описание, что угодно может оказаться».

Пространный ответ.

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

1.
Итак, ты прочел Савина и пошёл устраиваться в тестировщики. Опыта, как я понимаю, пока нету. Знание техник тестирования – на уровне книги Савина.

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

2.
Ну ладно, так или иначе – ты устроился на работу и начал свой путь тестировщика. Чорный ящик + свободный поиск. Не очень понятно, в чём тут скука. Ты же не ожидал, что тебя сразу посадят работать с Самой Главной Фичей или анализировать архитектуру проекта. Или – что ящик сразу будет белый/прозрачный: это требует умения читать и анализировать код и еще некоторых специфических знаний, которые трудно ожидать от новичка с Савиным в рюкзаке.

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

Кроме того, есть такой нюанс, что при долгой работе с продуктом глаз «замыливается», и часть проблем просто не замечается. На этот случай новичок, не знакомый с продуктом, просто клад. Он же совсем ничего не знает пока про продукт. Он, конечно, задаст кучу «глупых» вопросов, но параллельно и пару-десяток багов на юзабилити, а то и логику приложения выявит.

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

Домашнее задание: Вспомни, что ты делал, когда становилось непонятно и скучно. Как ты знакомился с продуктом. Сколько вопросов задавал, как и кому. Разобрался ли с главной идеей продукта. Какой там основной сценарий использования. Можешь ответить внятно – хорошо. Нет – а может, ты не очень и интересовался? А работодатель-то больше любит активных ребят. Да и не могут окружающие понять без твоей помощи, что тебе понятно, а что нет.

3.
Так о чём же спрашивать работодателя, когда принимают на работу?

Ну, вообще – о чём угодно, точнее – обо всём, что интересно (и имеет отношение к работе, конечно). Сколько лет другим тестировщикам? На скольки проектах нужно будет работать? Сколько лет проекту? Каковы его перспективы? Что будет, когда он закончится? Есть ли в здании столовая? Давно ли образована команда тестирования? Во сколько люди приходят на работу? Какая ОС используется на рабочих машинах? Как уменьшить испытательный срок? В какой комнате я буду сидеть? Можно ли совмещать работу с учёбой? Что самое главное в моей работе? Какая методология разработки используется? А свою кружку можно принести на работу?

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

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

Не, ну с вопросами-то понятно. А что спрашивать, чтобы потом не было так скучно?

Ну что тебе сказать, я не знаю. Почему скучно-то было?

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

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

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

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

Короче, чтоб было интересно – интересуйся, что происходит вокруг и как всё устроено. Это поможет и не скучать, и работать эффективнее, и вообще поможет.

Сумбурно получилось, извини – давно я не брал в руки шашек. Надеюсь, хоть частично я тебе ответил.
Пойду работать, у меня там сегодня столько вкусного запланировано…

Новая версия доступна. Обновить?

noreply@blogger.com (Pavel ) — Fri, 20 May 2011 13:58:00 +0000

В жизни приложений, помимо "просто работы", есть масса интересных, пусть и относительно редких событий.
Приложение должно корректно устанавливаться – и нам нужно проверять это.
Приложение должно корректно удаляться (а вдруг!) – и нам нужно проверять это.
Приложение должно корректно обновляться до новой версии – и нам… подождите-подождите… нужно проверять это!
Об апгрейдах и пойдет речь.

Порой мне начинает казаться, что “забыть про апгрейд” – дело не то чтобы обычное, но и нередкое. Ну ладно, забыть – слишком сильно сказано, просто – отложить. Нет, конечно, процедуру апгрейда сделаем, но пока вот сосредоточимся на доведении функциональности до ума. А потом все разом прикрутим и протестируем.

Ну, мы знаем, сколько того "потом" обычно остается.

Отложить тестирование апгрейда "на потом", проводить такое тестирование на простейших сценариях означает создать проблемы своим клиентам. Хочу отдельно обратить внимание: не потенциальным клиентам, а людям, которые уже используют наш продукт и собирались использовать и дальше. А тут вдруг апгрейд сломался в середине и похоронил все данные за два года работы. Беда… Неудивительно, если клиенты разбегутся, когда что-то пойдет не так.

Ладно, будем считать, что все согласны: аккуратная проверка апгрейдов необходима. Будем проверять.

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

Disclaimer. Все "диалоги" выдуманы, совпадения случайны, слова перепутаны, буквы стоят не на своих местах.

Всего лишь набор файлов

Что может пойти не так при апгрейде, если все наше приложение это набор файлов, некоторые из которых – исполняемые?

Да вроде как и особо ничего, а? Берем новые файлы, копируем их на место старых – и готово. Ну для порядка можно "инструкцию апгрейда" написать, что-то вроде
1. Откройте папку, в которую установлено приложение (путь по умолчанию: ХХХ).
2. Скопируйте в нее файлы входящие в новую версию приложения
А лучше – использовать инсталлятор/скрипт, который все файлы сам по местам разложит.

Все так, пока программист проверяет апгрейд, выполняя "очевидные" действия, которые "и так сами собой разумеются". У пользователя же потом апгрейд может сломаться, потому что
- File is locked – Ой, мы не проверили, что приложение не запущено.
- Access is denied – Из под какого пользователя они запускают апгрейд?
- Диск полон – И это в век терабайтных дисков?

Или – апгрейд успешно отработал, но приложение не запускается, ведь
- Method not supported – Упс, а версия одной библиотеки старая. Забыли файл обновить.
- ОЙ, какая-то мистика – Эээ, какая у них древняя ОС. А мы-то писали-проверяли только с последними апдейтами. Хотя прежняя версия и без них работала…

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

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

Сервис/демон

С файлами разобрались, пойдем дальше.

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

- Апгрейд закончился, а сервис работает точно как раньше! – А рестартануть-то демона мы забыли!
- Все работает, все здорово, только сервис перестал запускаться после рестарта сервера. – Даа, а настройки запуска мы сбросили в "умолчальные" во время апгрейда…
- Эй, сервис не работал все время, пока шел апгрейд! Кто мне заплатит за простой бизнеса? – Хм, надо бы предупреждать, наверное, что сервис будет приостанавливаться во время апгрейда.
- Будет простой сервиса? Ну ладно, спасибо, что предупредили. А долгий простой-то? – Слушай, и правда надо измерять время даунтайма. И, кстати, попробовать как-то минимизировать его.
- Я апгрейд выполнил, и уехал по делам. А сервис после апгрейда не запустился оказывается! – Надо бы запоминать, в каком состоянии сервис был до апгрейда – и возвращать его в то же состояние после.

Да, стоит помнить, что клиенты не для развлечения наши сервисы разворачивают…

Клиент-Сервер

Отношения Клиент-Сервер – обычное дело в современных программах. Впрочем, и эти отношения бывают "разной степени усложненности".

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

- Не могу подключиться к серверу. Никогда такой ошибки не было! – Как мы забыли предупредить, что клиентскую часть тоже надо апгрейдить, а старая версия клиента не сможет работать с сервером???
- Мне что, запускать апгрейд на каждом хосте, где стоит какой-то модуль системы?? – Кстати да, мы могли бы и автоматически обновлять все хосты – параллельно или один за другим, надо подумать, как лучше. А то боком нам распределенность выходит.
- Что-то апгрейд упал на середине… – ОЙ, вот мы молодцы! Модуль Первый на хосте 01 проапгрейдился и пытается пнуть модуль Второй на хосте 02. А интерфейс общения-то другой после апгрейда! Где ты, обратная совместимость? Даа, на свежих инсталляциях таких проблем не возникает…

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

База Данных

Если приложение использует БД, то вкусного еще больше!

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

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

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

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

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

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

Другой аспект, на который могут влиять данные, – это время апгрейда. Чем больше в таблице записей, тем больше времени потребуется на изменение структуры этой таблицы и обновление данных в ней. А время потраченное на апгрейд – это время потерянное для бизнеса, и его надо минимизировать. Тут тоже в зависимости от ситуации, требований и ожиданий можно применять разные подходы, от выполнения низкоуровневых функций до использования отдельного сервера для апгрейда БД, пока приложение работает со старым.

Еще интересен случай, когда приложение умеет работать с разными движками БД. SQL, как известно, "немного свой" у каждого движка – MySQL, PgSQL, MSSQL… Всегда есть шанс, что запрос, работающий на PgSQL, окажется нерабочим на MSSQL. На этот случай вариантов немного – нужно проверять на всем, что поддерживается.

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

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

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

Инсталер

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

Все ли у него гладко с логикой? Что случится, если в середине апгрейда что-то произойдет, и мы перезапустим апгрейд заново? Пишет ли он логи, какие и куда? Все ли опции работают верно? В конце концов, нет ли орфографических ошибок в интерфейсе?

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

Пара общих соображений

Напоследок выскажу еще несколько соображений, не вошедших в предыдущие части.

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

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

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

На этом, пожалуй, хватит.

Удачи вам и быстрых беспроблемных апгрейдов.

Всего лишь пара изменений

noreply@blogger.com (Pavel ) — Thu, 07 Apr 2011 07:00:00 +0000

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

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

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

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

И вопрос - как эти изменения контролировать?

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

Сообщать об изменениях

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

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

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

Ок, нам сообщили, можно жить и радоваться. Тестировщику - наверное, да, можно. А его начальнику, возможно, пора задуматься, как

Сохранять историю тестирования изменений

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

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

Впрочем, история - это хорошо и полезно, но иногда стоит еще и

Планировать тестирование изменений

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

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

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

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

Удачи вам, внятных требований и контролируемых изменений.

Баг для лога

noreply@blogger.com (Pavel ) — Fri, 11 Mar 2011 07:03:00 +0000

В предыдущем посте речь шла о пользе чтения логов при исследовании и описании дефектов ПО. Сегодня я хочу зайти немного с другой стороны.

Логи, безусловно, помогают исследовать поведение приложения, но в то же время логи – часть тестируемого продукта. То есть – их тоже можно тестировать. И вокруг них тоже могут водиться баги, а как же.

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

Полнота

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

Настраиваемость

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

Безопасность

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

Производительность

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

Читабельность

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

Документация

Упомянуты ли логи в документации? Описаны ли возможные/рекомендуемые настройки, советы по работе с логами? Нужна ли вообще подобная информация в документации?

Автоматизация

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

Добавить свой вариант

Я уверен, мой список далеко не полон.

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

Удачи вам и интересных логов.

Лог для бага

noreply@blogger.com (Pavel ) — Wed, 09 Mar 2011 17:29:00 +0000

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

Логи в чём-то подобны скриншотам – это такое же документальное и объективное свидетельство о работе приложения, с которым нет смысла спорить. Его можно обсуждать, изучать, уточнять сопутствующие условия, но факт есть факт, и отмахнуться от него не получится.

Поскольку тестировщикам по роду деятельности приходится много сталкиваться с различными проблемами в работе приложения, то мы должны уметь грамотно работать с логами. Если смотреть «снаружи», то вся эта грамотность сводится к паре простых правил.

Загнал баг без лога – увеличил энтропию

Обнаруженный и зарегистрированный баг – один из основных результатов деятельности тестировщика. Чем точнее описана и локализована проблема, тем проще потом всем жить. Сохранённый и прикрепленный к багу лог помогает повысить точность описания, особенно в случае сложных систем, когда изменение одной настройки приводит к порой неочевидным переменам в поведении программы. Тестировщик может не вспомнить или даже не знать, что для некоторых параметров приложения заданы специфические значения. Соответственно, и в баге он это не упомянет. А лог поможет восстановить, как дело было.

Нашли проблему, что слоны с неба падают; написали, что автобус за углом стоит

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

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

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

А что вообще нужно знать, чтобы суметь выкусить адекватную "цитату" из лог-файла?

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

Второе, что потребуется узнать, – где хранятся логи.

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

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

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

Такие вот довольно очевидные и неоригинальные соображения и рекомендации.

Удачи вам, парящих слонов и логов без ошибок.

Калибан с зеркалом

noreply@blogger.com (Pavel ) — Tue, 01 Mar 2011 07:12:00 +0000

Уточняя цитату про Калибана, перечёл предисловие к "Портрету Дориана Грея". Не удержался и перетолмачил это предисловие в иных терминах. Получился своеобразный манифест о тестировании :)

Я рекомендую сперва прочитать оригинал, а потом уже мои вариации на тему. Впрочем, порядок чтения не так уж важен.

Итак.

Тестировщик - тот, кто предоставляет информацию [о качестве].

Раскрыть окружающим положение дел и скрыть [роль] тестировщика - вот к чему стремится тестирование.

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

Высшая, как и низшая, форма руководства - один из видов воспитания.

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

Те, кто способны узреть в результатах тестирования его высокую пользу, - люди культурные. Они не безнадежны.

Но избранник - тот, кто в результатах тестирования видит лишь одно: Информацию.

Нет продуктов изобилующих дефектами или избавленных от оных. Есть продукты хорошо протестированные или протестированные плохо. Вот и все.

Ненависть индустрии разработки ПО к Дефектам - это ярость Калибана, увидевшего себя в зеркале.

Ненависть индустрии разработки ПО к Требованиям - это ярость Калибана, не находящего в зеркале своего отражения.

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

Тестировщик не стремится что-то доказывать. Доказать можно даже даже неоспоримые истины.

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

Не приписывайте тестировщику нездоровых тенденций: ему дозволено сомневаться во всем.

Идеи и Навыки для тестировщика - средства тестирования.

Дефекты и Ценности - материал для его работы.

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

Во всяком виде тестирования есть то, что описано в книгах, и суть.

Кто пытается постичь больше, чем описано, тот идет на риск.

И кто раскрывает суть, идет на риск.

В сущности, Тестирование - зеркало, отражающее того, кто в него смотрится, а вовсе не продукт.

Если результаты тестирования вызывают споры - значит, в них есть нечто важное, сложное и значительное.

Пусть руководители расходятся во мнениях - тестировщик остаётся верен себе.

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

Всякое тестирование [само по себе] совершенно бесполезно.

Границы и края

noreply@blogger.com (Pavel ) — Wed, 16 Feb 2011 07:06:00 +0000

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

Так, приглядываясь к рискам, которые могут возникнуть в работе, проще всего сперва посмотреть на крайние значения. Кстати нередко вокруг таких крайних значений ломаются копья в различных спорах на тему тестирования (и вообще разработки ПО). Несколько примеров:

Все тесты должны быть описаны так, чтоб их мог выполнить человек с улицы

против

Мы тестируем, а не мараем бумажки

Просто дайте нам приложение, и мы его проверим
против
Чтобы начать тестирование, нам нужны следующие N артефактов: спецификация по стандарту XXX, …

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

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

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

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

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

Но это еще не все границы, с которыми приходится иметь дело, и, наверное, не самые интересные.

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

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

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

Удачи вам, четких границ и нестрашных проблем вокруг них.

40 и 90

noreply@blogger.com (Pavel ) — Wed, 02 Feb 2011 13:03:00 +0000

Как и многие до меня, однажды я задумался о звучании чисел 40 и 90 в русском языке. Почему они - "сорок" и "девяносто", а не "четыредесять" и "девятьдесять"? В том же английском языке все честно: forty и ninety. И у нас вроде бы должно быть так же, если сравнивать с другими числами: "пятьдесят", "семьдесят". Что не так с этими двумя?

Наверняка я не знаю, конечно; разные есть версии на этот счет. Приведу те, что мне самому кажутся интересными и правдоподобными.

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

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

Впрочем, речь не о числах, интересно другое. Замеченная "странность мира" (нелогичные названия чисел) позволила по-новому взглянуть на числа и связь их названий с историей страны. То есть, заметив странное и покопав в этом направлении, я узнал что-то новое.

Странности мира - отличный источник знаний о мире.

Дефекты продукта - отличный источник знаний о продукте.

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

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

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

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

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

Отчасти поэтому и нужны тестировщики - они смотрят на продукт по-своему.

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

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

Удачи вам, удивительных дефектов и интересных открытий.

Между роботом и обезьяной

noreply@blogger.com (Pavel ) — Thu, 27 Jan 2011 07:09:00 +0000

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

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

Коротко говоря - они не умеют думать. Роботы - совсем, Обезьянки - почти. И в этом смысле тестировщик круче и Обезьянки, и Робота в равной степени. Ну разве что Робот быстрее кликает. Зато тестировщик способен понять, что тут кликать вообще незачем.

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

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

Удачи вам, верных Роботов, смышленых Обезьянок и ясного взгляда.

О тестировании документации

noreply@blogger.com (Pavel ) — Mon, 17 Jan 2011 07:21:00 +0000

Documentation is like sex: when it is good,

it is very, very good; and when it is bad,

it is better than nothing.

Dick Brandon

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Ого, уже одиннадцать пунктов. А казалось бы, всего лишь тестирование документации, ничего сложного.

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

Удачи в тестировании!

М.Болтон: Оценка проекта и Черные Лебеди. Часть 5. Оценка тестирования.

noreply@blogger.com (Pavel ) — Thu, 13 Jan 2011 06:40:00 +0000

Вольный перевод статьи Майкла Болтона Project Estimation and Black Swans (Part 5): Test Estimation

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

Давайте действовать как тестировщики – будем задавать вопросы.

Существует ли вообще такая штука, как проект тестирования? В частности, может ли проект тестирования существовать независимо от проекта разработки?

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

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

Хотя тестирование может быть организовано в виде циклов, было бы странно считать его чем-то отдельным от остального проекта, так же как было бы странно думать о наблюдении (смотрении, seeing) как об отдельной части вашего дня. Люди говорят много странного, но едва ли вы слышали, чтобы кто-то сказал: "Мне нужно закончить работу, а потом я начну смотреть"; вы почти никогда не спрашиваете: "Когда вы планируете завершить наблюдение?" Бывают моменты, когда вы уделяете глазам и наблюдению больше внимания - когда вы управляете машиной или режете овощи или наблюдаете за ребенком, играющим в захламленной комнате. Но даже когда вы сконцентрированы на наблюдении, оно происходит в контексте какой-то иной деятельности (и обслуживает эту деятельность).

Имеет ли смысл термин "фаза тестирования"?

Многие организации (например, не использующие Agile) делят проект на две обособленных части: "фазу разработки" и "фазу тестирования". Мой коллега Джеймс Бах (James Bach) заметил интересное противоречие в таком подходе.

Что происходит в "фазе разработки"? Программисты программируют. Программирование может включать в себя массу активностей, таких как исследование, проектирование, экспериментирование, создание прототипов, написание кода, блочное тестирование (unit testing) (а в случае TDD тест для блока создается до написания кода, который будет проверяться), интеграционное тестирование, отладка, рефакторинг. А что делают тестировщики во время "фазы разработки"? Тестировщики тестируют. Говоря точнее, они занимаются обзором, планированием, проектированием тестов, созданием инструментов, генерированием данных, настройкой окружения, выполнением интеграционных тестов сравнительно низкого уровня и даже выполнением высокоуровневых системных тестов. Все эти действия можно включить в категорию "тестирование".

Что происходит в "фазе тестирования"? Программисты по-прежнему программируют, а тестировщики по-прежнему тестируют. Главное отличие между этими двумя фазами - в фокусе работы программистов: они прекращают добавлять новую функциональность, а вместо этого занимаются починкой найденных проблем. В первой фазе программисты уделяют больше внимания разработке новых функций; во второй - починке. Исходя из этого, Джеймс считает, что "фазу тестирования" правильнее называть "фазой починки" (fixing phase). Если мы всерьез рассмотрим это предложение, изменится суть некоторых часто возникающих вопросов. Замените слово "тестировать" словом "чинить": "Сколько времени вам нужно на починку этого продукта?", "Когда планируется завершить починку?", "А мы можем просто автоматизировать починку?", "Стоит ли начинать починку на ранних стадиях проекта?", "Почему клиент нашел сломанную функциональность? Вы что, не чинили ее?" И должны ли мы обращаться к тестировщикам с такими вопросами?

Как отмечает Джеймс, никто никогда не откладывал выпуск продукта просто потому, что еще было что потестировать. Продукты задерживаются из опасения, что разработчикам стоило бы сделать еще что-то до релиза. Тестирование можно остановить, как только владелец продукта (product owner) убедился, что имеет достаточно информации, чтобы разрешить поставку продукта. В таком случае, вопрос к тестировщикам "Когда вы собираетесь завершить тестирование?" превращается в вопрос к владельцу продукта: "Когда я поверю, что имею достаточно данных для принятия ответственного бизнес-решения?" В такой момент владельцу продукта стоит [в разумной степени] скептически смотреть на чьи-то заявления, что они завершили тестирование.

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

Некоторые верят, что могут спрогнозировать, когда завершится тестирование, разбивая тестирование на измеримые части, такие как варианты тестирования (test cases) или шаги тестирования. По-моему, это все равно, что использовать "варианты наблюдения" или "шаги наблюдения", что приводит нас к следующему вопросу:

Можно ли измерить длительность "проекта тестирования" подсчитав "варианты тестирования" или "шаги тестирования"?

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

Только одна проблемка: основа вычисления не была объяснена. Что такое шаг тестирования? Это физическое действие? Похоже, докладчица предполагала, что тестировщик переходит к следующему шагу, когда он начинает подавать новые входные данные (input action). Несомненно, не все входные данные одинаковы. Что считается подачей входных данных? Клик мышкой? Движение мышкой? Ввод каких-то данных в поле? В набор полей с последующим нажатием клавиши Enter? Включается ли наблюдение (несколько наблюдений) в шаг тестирования? А оценка результата (evaluation)? Что происходит, когда человек замечает странность и начинает размышлять? Что происходит, когда во время выполнения теста тестировщик замечает опасность и решает поискать соответствующие проблемы? Что происходит с единицей измерения, когда тестировщик находит проблему и начинает исследовать и описывать ее?

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

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

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

Если мы не можем полагаться на подсчет вариантов тестирования, как мы можем оценить время, необходимое для тестирования?

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

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

Мой начальник говорит, что я должен предоставить оценку, что мне делать?

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

Наша стратегия - это набор идей, на базе которых мы строим тесты. Эти идеи возникают из окружения проекта (контекста); из критерия качества, который могут оценить пользователи и другие лица; из тестового покрытия, которое мы хотим получить; из техник тестирования, которые мы выбираем. (В качестве примера основы для разработки стратегии можно рассмотреть эвристическую модель стратегии тестирования, Heuristic Test Strategy Model, которую мы используем в Rapid Testing). Логистика - это идеи, направляющие применение людей, оборудования, инструментов и других ресурсов для осуществления нашей стратегии. Сложите стратегию и логистику вместе - и получите план.

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

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

Но мое руководство любит оценки! Может, есть хоть что-то, что можно оценить?

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

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

и, опционально,

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

Ограничение по времени позволяет выполнить неточную, но достаточно верную оценку и подсчет. (В чем разница? Если я напишу, что текущее время и дата - 9:43:02.1872 утра 23 января 1953 года, то это очень точное, но абсолютно неверное вычисление времени).

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

десять дней * четыре тестировщика * три сессии = 120 сессий.

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

120 сессий - 120 * 1/3 пауз = 80 сессий

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

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

Желающие оценить длительность цикла тестирования или необходимое количество работников могут использовать и альтернативный подход: определите желаемый уровень покрытия, добавьте известные значения переменных и вычислите остальные. Разбейте продукт на области и сопоставьте каждой из них нужное число сессий в соответствии с рисками, сложностью или любой другой комбинацией параметров, которая вам важна. Отрегулируйте эффективность и число перерывов, отталкиваясь от предположений или предыдущего опыта. Если известно число тестировщиков, вы можете вычислить, сколько времени потребуется; если вы зададите длительность, то сможете определить необходимое количество тестировщиков. Это даст вам быструю оценку.

В которой, конечно, стоит сразу усомниться. Как опыт и умения тестировщика влияют на вашу оценку? На возможные события? Если вы подумываете увеличить число тестировщиков, сможете ли вы обойти закон Брукса? Меняются ли ваши представления о рисках? Верны ли эти представления? И так далее. Хорошо выполненная оценка должна порождать большое количество вопросов. Не беспокойтесь, подлинное тестирование даст ответы на эти вопросы.

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

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

М.Болтон: Оценка проекта и Черные Лебеди. Часть 4.

noreply@blogger.com (Pavel ) — Wed, 12 Jan 2011 08:16:00 +0000

Вольный перевод статьи Майкла Болтона Project Estimation and Black Swans (Part 4)

В нескольких последних статьях исследовательская автоматизация подсказала некоторые интересные идеи насчет динамики проектов и их оценки. Какую пользу можно извлечь из этих математических экспериментов?

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

Похоже, математика поддерживает идеи, расхваливаемые энтузиастами Agile, гуманистами и мыслителями: получайте обратную связь быстро и часто. Глядя на последнюю модель - меньше задач и более короткие проекты - мы можем предположить, что чем короче и управляемей проект, тем меньше шансов у Черного Лебедя нанести вред любому отдельно взятому проекту.

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

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

Кто-то может предложить нам устранить изменчивость, неизвестность и непредсказуемость. Какая отличная идея! По определению, неизвестность - это состояние незнания чего-либо; по определению, что-то непредсказуемое не может быть предсказано. Снежные бури случаются (даже в Британии!). Компьютеры ломаются. В Индии регулярно отключается электричество - когда я последний раз был в Индии, оно отключалось трижды во время занятий и еще трижды вечером за два дня пребывания в отеле бизнес-класса. В Северной Америке отключения электричества тоже случаются - и поскольку мы не привыкли к ним, мы не готовы действовать в такой ситуации. (Для нас это Черный Лебедь, хотя для живущих в Индии это - Серый Лебедь). Руководители назначают общие собрания, порой с печальными новостями. Сервера падают. Бэкапы портятся. Люди болеют, а если они здоровы, то болеют их дети. Поезда опаздывают. У велосипедов спускают колеса. И баги, по своей природе, непредсказаны.

Итак, мы не можем предсказать непредсказуемое. Однако есть жизнеспособная альтернатива: мы можем ожидать непредсказуемое, предвидеть его в некоторой степени, управлять им насколько это возможно и учитывать собственный опыт. Объятия непредсказуемости напоминают мне о парадоксе регулировщика из книги Джерри и Дэни Вайнбергов (Jerry and Dani Weinberg) "General Principles of System Design", который я упоминал ранее:

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

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

Когда я был на мастер-классе Джерри Вайнберга "Problem Solving Leadership" (PSL), одна из групп не смогла выполнить очередное упражнение по решению проблем. Во время опроса Джерри спросил: "Почему у вас возникли такие трудности? Вчера вы справлялись с гораздо более трудными задачами."

"Нас сразила сложность проблемы" - ответил кто-то

Джерри посмотрел поверх своих очков и ответил: "Вас сразила ваша реакция на сложность проблемы"

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

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

М.Болтон: Оценка проекта и Черные Лебеди. Часть 3.

noreply@blogger.com (Pavel ) — Tue, 11 Jan 2011 06:43:00 +0000

Вольный перевод статьи Майкла Болтона Project Estimation and Black Swans (Part 3)

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

Оставляйте проблемные задачи незавершенными; допускайте потерю функциональности

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

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

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

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

Оставляйте проблемные задачи незавершенными; допускайте потерю функциональности и багов

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

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

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

Расцепляйте задачи

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

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

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

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

Замечайте проблемы и управляйте ими

Что мы можем сделать, чтобы предупредить и обнаружить проблемы, чтобы управлять ими?

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

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

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

Заметьте, что получение обратной связи занимает какое-то время. Митинги могут занимать время, достаточное для выполнения задачи; постоянное общение - замедлять работу. В результате нам придется изменить некоторые наши задачи (или некоторую их часть) с «работы» на «проверку работы» или «обсуждение работы»; и возможно, что некоторые Ошеломительные Успехи превратятся в Нормальные Задачи. Это недостаток. Выгода в том, что мы, возможно, предотвратим некоторые Небольшие Сдвиги, Потраченные Утра, Потерянные Дни и Гадких Утят и превратим их в Нормальные Задачи или Ошеломительные Успехи.

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

Итак, если нам нужно управлять проектом, быстро реагировать на потенциально неконтролируемые задачи, сглаживать отклонения, используя те или иные из предложенных выше идей, то как мы можем это смоделировать, используя метод Монте-Карло? Если мы часто делаем проверки, то мы делаем меньше в рамках каждой задачи, поэтому давайте превратим Ошеломляющие Успехи (задачи, решенные за 50% запланированного времени) в Скромные Успехи (задачи, решенные за 75% отведенного времени). Мы неизбежно переоценим одни задачи и недооценим другие, так что давайте полагать, что в среднем 50 задач из ста завершаются на 25% раньше, 49 - на 25% позже. Каждого порой настигает неудача, поэтому мы оставим шанс появления одного Гадкого Утенка в проекте.

Число задач	Тип задачи	Длительность	Всего (часов)
50	Скромный успех	0.75	37.5
49	Крохотный сдвиг	1.25	61.25
1	Гадкий Утенок	16	16

И опять я выполнил 5000 смоделированных проектов.

Средний проект	114.67 часа
Минимальная длительность	92.0 часа
Максимальная длительность	204.25 часа
Проекты завершенные вовремя или раньше	1058 (21.2%)
Опоздавшие проекты	3942 (78.8%)
Опоздавшие на 50% и больше	96 (1.9%)
Опоздавшие на 100% и больше	1 (0.02%)

Вспомните, что в первом примере половина задач завершалась на 50% раньше. Сейчас половина задач завершается только на 25% раньше, но картина в целом выглядит лучше. Мы удвоили число проектов, завершившихся вовремя, а средняя длительность проекта снизилась со 124% до 114%. Отлов проблем до того, как он превратятся в Потраченные Утра или Потерянные Дни дает заметную разницу в результатах.

Замечайте проблемы и управляйте ими, плюс короткие итерации

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

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

Для распределения задача/длительность я использовал тот же подход, что и раньше

Число задач	Тип задачи	Длительность	Всего (часов)
50	Скромный успех	0.75	37.5
49	Небольшой сдвиг	1.25	61.25
1	Гадкий Утенок	16	16

Я уменьшил размер проекта до 20 задач. Далее, чтобы скомпенсировать уменьшение проекта, я выполнил 25000 смоделированных проектов.

Средний проект	22.94 часа
Минимальная длительность	16 часов
Максимальная длительность	66.75 часа
Проекты завершенные вовремя или раньше	12433 (49.7%)
Опоздавшие проекты	12567 (50.3%)
Опоздавшие на 50% и больше	4552 (18.2%)
Опоздавшие на 100% и больше	400 (1.6%)

Тут есть несколько интересных моментов. Мы, наконец, сумели завершить вовремя почти половину проектов! Кроме того, более 80% проектов (20443 из 25000 в моем запуске) находятся в пределах 15% от предсказанного времени - а поскольку полный проект занимает только 30 часов, отклонение этих проектов составляет только 3 часа. Это позволяет быстро корректировать курс; в модели сточасовых проектов средний проект задерживался на три дня.

Есть и еще один потрясающий результат: общее количество времени, затраченного на эти 25000 проектов (всего 500 000 задач), равно 573 410 часов. В исходной модели общее время равнялось 619 156,5 часов, что на 8% больше. В более реалистичном втором примере общее время равнялось 736 199,2 часа, что на 28% больше. Короткие итерации дают случайности меньше возможностей повлиять на каждый отдельный проект в нашей модели.

Итак, что все это означает? Чем это полезно? Давайте рассмотрим некоторые идеи в следующий раз.

М.Болтон: Оценка проекта и Черные Лебеди. Часть 2.

noreply@blogger.com (Pavel ) — Mon, 10 Jan 2011 07:44:00 +0000

Вольный перевод статьи Майкла Болтона Project Estimation and Black Swans (Part 2)

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

Линейная модель, которую я предлагал, не соответствует реальности в нескольких аспектах, но до сих пор я особо не говорил об этом. Вот лишь несколько недостатков этой модели.

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

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

Дополняйте оценки так, чтобы они были верны в половине случаев

Взгляните еще раз на график первого вчерашнего сценария:

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

Когда я взял данные метода Монте-Карло и упорядочил проекты по длительности, я обнаружил, что Проект 2500, тот, что находится ровно посередине, занял 122 часа. Таким образом, стоит добавить 22% к оценке, и в половине случаев мы завершим проект в отведенное время.

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

Дополняйте оценки так, чтобы они были верны почти всегда

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

Один из недостатков такой стратегии в том, что работа склонна занимать все отведенное время, а люди начинают работать в более низком темпе.

С другой стороны, если люди работают в постоянном темпе, 82% проектов завершатся как минимум на 10% раньше, а 42% - на 25% раньше! В этом случае мы можем столкнуться с "политическим" недовольством, и нас заставят быть менее осторожными в наших оценках. Математика показывает, что мы действительно не можем выиграть при данном наборе допущений.

Дополняйте команду

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

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

М.Болтон: Оценка проекта и Черные Лебеди. Часть 1.

noreply@blogger.com (Pavel ) — Sun, 09 Jan 2011 08:44:00 +0000

Вольный перевод статьи Майкла Болтона Project Estimation and Black Swans (Part 1)

В последние месяцы в сети активно обсуждалось оценивание:

Ward Cunningham написал в твиттере: "Оценивание - выдуманная проблема, на решение которой профан тратит десятки дней"
Pradeep Soundararajan опубликовал в блоге развернутую статью, посвященную оценке затрат на тестирование.
Некто, назвавшийся Nathaniel'ем, изложил интересную точку зрения на успешные оценки на сайте Terralien.
Jens Schauder опубликовал 8 причин, почему оценки слишком низки.
Andre Dhondt недавно подключился к спору со статьей “Оценки ведут к убыткам, резервы приносят пользу”. (Вообще-то я не согласен. Резервы не приносят пользу, а вносят некоторый вклад в создание благоприятных условий, позволяющих создать нечто полезное. Достаточное количество резервов позволяет снизить угрозы.)

Все это сподвигло меня опубликовать результаты некоторых численных экспериментов, начатых в ноябре 2009-го и основанных на мысленном эксперименте, придуманном Джеймсом Бахом (James Bach). Эта работа совпадает по времени с Лебединой Песней, колонкой для Better Software, в которой я обсуждал книгу Талеба (Nassim Nicholas Taleb) "Черный Лебедь".

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

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

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

В-третьих, после Черного Лебедя люди склонны говорить, что они предполагали его приход. Такие заявления звучат после события и обусловлены парой взаимосвязанных когнитивных ошибок (ошибок познания). Первую Талеб называет эпистемиологической самонадеянностью, преувеличенным представлением о том, что мы знаем. Вторая - это искажение нарратива, наша склонность рассказывать и воспринимать истории в соответствии с нашими представлениями о нашем знании, без проверки связей между причиной и результатом. Легко считать, что мы знаем важные факторы истории, когда нам известно, чем кончилось дело. Первая Мировая Война была Черным Лебедем; 11е сентября 2001го года было Черным Лебедем; землетрясения на Гаити, вулкан в Исландии, разрушение нефтяной платформы в Мексиканском заливе были Черными Лебедями. Взлет цены на акции Google после выхода этой компании на биржу тоже был Черным Лебедем. (Возможно, вы встречали людей, заявляющих, что они знали заранее о будущем резком росте акций. Если бы это было правдой, они бы купили акции и стали богаты. Если они не богаты, это проявление искажения нарратива)

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

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

Кроме того, предположим, что ваша оценка была очень осторожной, и половина задач (т.е. 50) были завершены за тридцать минут вместо часа. Назовем такие задачи Ошеломляющим Успехом. 35% задач выполнены за отведенное время; назовем их Нормальными Задачами.

В 15% случаев вам не везет.

Восемь задач занимают два часа вместо одного. Давайте назовем их Небольшой Сдвиг.
Четыре задачи (одна из 25ти) заканчиваются через 4 часа вместо одного, как вы предполагали. Проявился баг в какой-то чужой библиотеке, которую вы используете; вам нужен доступ на какой-то сервер, а IT департамент слишком занят и отвечает только после обеда. Такую задачу мы назовем Потраченное Утро.
Две задачи (одна из пятидесяти) занимают целый день вместо часа. Кто-то должен остаться дома с больным ребенком. Их мы назовем Потерянный День.
Одна задача из ста - только одна - занимает два дня вместо часа. Другая команда задерживает разработку библиотеки на пару дней; поломка жесткого диска обрушила систему, а резервная копия оказалась испорченной; одной из программисток удалили зуб мудрости (все эти вещи случались в проектах, где я работал). Эти события не обладают разрушительной силой Черных Лебедей; они больше похожи на детей Черного Лебедя, поэтому давайте звать их Гадкими Утятами.

Число задач	Тип задачи	Длительность	Всего (часов)
50	Ошеломляющий успех	0.5	25
35	Нормальная задача	1	35
8	Небольшой сдвиг	2	16
4	Потраченное утро	4	16
2	Потерянный день	8	16
1	Гадкий Утенок	16	16
100			124

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

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

Я создал небольшую программу на Ruby, генерирующую результаты таких сценариев. Скрипт выполняет N проектов (состоящих из M задач каждый), позволяет мне указать произвольное число вероятностей и длительностей для задач, сохраняет результаты в таблицу Excel и создает графики для этих результатов. (Естественно, пока я занимался этим проектом, я нашел и починил тонну багов в моем коде. Но помимо этого я нашел баги в Excel'е, включая обрушения, вследствие состояния гонки (race condition), проблемы с производительностью API и просто недостаточную документацию. Разве тестирование - это не интересно?) Для описанного выше сценария я выполнил 5000 проектов, каждый из которых состоял из 100 случайных задач. Я получил следующие результаты, основанные на указанных выше числах:

Средний проект	123.83 часа
Минимальная длительность	74.5 часа
Максимальная длительность	217 часов
Проекты завершенные вовремя или раньше	460 (9.2%)
Опоздавшие проекты	4540 (90.8%)
Опоздавшие на 50% и больше	469 (9.8%)
Опоздавшие на 100% и больше	2 (0.9%)

Несколько интересных вещей, которые я заметил:

Средний проект занимает 123.83 часов, почти на 25% больше, чем мы оценивали
460 проектов (или меньше 10%) завершились вовремя или раньше срока!
4540 проектов (или более 90%) завершились с опозданием!
Вам может повезти. В моем запуске три проекта завершились за 80 часов и меньше. Ни один из проектов не избежал какого-либо Потраченного Утра, Потерянного Дня или Гадкого Утенка. Ни один из пяти тысяч.
Кроме того, вам может не повезти. 469 проектов заняли, по меньшей мере, в полтора раза больше времени, чем планировалось. Два проекта заняли более чем вдвое больше времени. Наконец, один очень несчастливый проект содержал четыре Потраченных Утра, один Потерянный День и восемь Гадких Утят. Этот проект занял 217 часов.

Это может показаться парадоксальным результатом. Половина задач занимает только половину времени, отведенного для их выполнения. 85% задач завершается вовремя или раньше. Только 15% задерживаются. Имеется всего один шанс из сотни встретить Гадкого Утенка. Как вышло, что так мало проектов завершилось вовремя?

Ответ в асимметрии, еще одном элементе модели Черного Лебедя, созданной Талебом. Делая оценки, легко ошибиться, работая, скажем, с множителем 2. Так, деление длительности задачи на два имеет совершенно иное влияние, чем умножение длительности на два. Маленькая Победа сохраняет только половину Нормальной Задачи, в то время как Небольшой Сдвиг стоит две Нормальные Задачи.

Предположим, что вы очень хорошо делаете оценки, и что вы не так часто ошибаетесь. 20% задач завершаются на 10% раньше (назовем их Маленькими Победами). 65% задач выполняются точно вовремя (Нормальные Задачи). То есть, 85% ваших оценок точны или слишком осторожны. Как и раньше, вы имеете восемь Небольших Сдвигов, четыре Потраченных Утра, два Потерянных Дня и Гадкого Утенка.

Имея 20% задач, завершающихся раньше срока и 15% - позже, как бы вы оценили длительность среднего проекта?

Число задач	Тип задачи	Длительность	Всего (часов)
20	Небольшая победа	0.9	18
65	Нормальная задача	1	65
8	Небольшой сдвиг	2	16
4	Потраченное утро	4	16
2	Потерянный день	8	16
1	Гадкий Утенок	16	16
100			147

Хотя ваши оценки даже более точны, чем в первом примере, средний проект завершается на 47% позже. То есть вы полагаете, что он займет две с половиной недели, а на самом деле, судя по всему, потребуется более трех с половиной недель. Напомню, это в среднем, и вновь основано на вероятности. Как и ранее, не каждый проект столкнется с невезением, а некоторые проекты будут более невезучими, чем остальные. Я вновь выполнил 5000 проектов, состоящих из ста задач каждый.

Средний проект	147.24 часа
Минимальная длительность	105.2 часа
Максимальная длительность	232 часа
Проекты завершенные вовремя или раньше	0 (0.0%)
Опоздавшие проекты	5000 (100.0%)
Опоздавшие на 50% и больше	2022 (40.4%)
Опоздавшие на 100% и больше	30 (0.6%)

Ни один из 5000 проектов не завершился вовремя. Лучший из проектов опоздал на 5%. Он содержал 18 Маленьких Побед, 77 Нормальных Задач, 4 Небольших Сдвига и Потраченное Утро. Этот проект счастливо избежал Потерянных Дней и Гадких Утят. И, будучи близким к запланированному времени, он был чрезвычайно редким. На самом деле, только 16 проектов из 5000 задержались менее чем на 10%.

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

Заметьте, что в обоих примерах, по меньшей мере, 85% задач завершались вовремя или даже раньше. Не больше чем 15% задач опаздывали. Это асимметрия влияния запаздывающих задач, приводящая к задержке подавляющего большинства проектов. Задача, занимающая одну шестнадцатую запланированного времени сохраняет менее одной Нормальной Задачи, а стоимость Гадкого Утенка превышает пятнадцать Нормальных Задач. Комбинация математики и неожиданности безжалостна к вам. Чтобы обойти проблему, вам придется управлять чем-то. Какие стратегии возможны? Об этом поговорим завтра.