Flexible — гибкий.

Agile — проворный, подвижный, верткий, живчик.

Тестирования ради, усядьтесь голым попом на горячую сковородку — вы моментально станете agile.

Впрочем, кое-что я знаю — Асхат Уразбаев первым мощно предложил опечатался про слоган внедрения agile в 2014-ом году.

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

А ещё я знаю следующее: agile не методология и не процесс. Это надстройка над уже существующей методологией и уже существующими процессами. И если их нет, то внедрять agile не на что.

То есть, у вас может не быть скрама и доски на стене, а agile может быть. У вас процесс производства может не меняться, а agile над ним — работает.

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

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

Не бывает так, что «вот раньше у нас был ватерфлоу, а сегодня аджайл», одно другое не заменяет. Waterflow навсегда.

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

Психиатрия человеческая выражается в том, что вы не умеете ни экспериментировать, ни думать. Вы умеете лихо исполнять ограниченный набор действий, за которые «вчера» вас хвалили. Отклонение от этого всего страшит, оно требует взрослости и большого commitment (в русском переводе это звучит очень глупо и травматично, поэтому оставим оригинал без перевода). Поэтому вам нужен однозначный менеджер, который скажет «Делать так и эдак», и дальше он только покусывает пряник, постёгивая плёткой тех, кто отклоняется от предписанного.

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

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

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

Поэтому agile и приходится в вас внедрять, по заветам Асхата.

Доклад на онлайн-конференции для специалистов по тестированию и управлению качеством серии «TEST Labs«. Читано в субботу, 28 июня 2014.

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

Сам доклад — 40 минут.С вопросами — час.

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

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

* * *

* * *

Ну, а теперь я хз, о чём ещё можно рассказать о тестировании в agile 🙂

Без картинок, но с линками и отступлениями.

Думал и писал долго.

Дочитал книгу «Secrets of a Buccaneer-Scholar» (How Self-Education and the Pursuit af Passion Can Lead to a Lifetime of Success) by JAMES BACH.

Книга не о тестировании as is, она о корнях и истоках того, что называется «исследовательское тестирование». ИссТест.

Уместный анекдот, в котором заключается вся суть исследовательского тестирования:

— Бэрримор, что это хлюпает у меня в ботинке?

— Овсянка, сэр!

— Но что она там делает?

— Хлюпает, сэр.

Что такое Исследовательское тестирование по SWEBOK

it4business.ru

Это одновременное обучение, проектирование теста и его исполнение.

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

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

wikipedia.org

Cem Kaner, who coined the term in 1983, now defines exploratory testing as «a style of software testing that emphasizes the personal freedom and responsibility of the individual tester to continually optimize the quality of his/her work by treating test-related learning, test design, test execution, and test result interpretation as mutually supportive activities that run in parallel throughout the project.»

Exploratory testing is often thought of as a black box testing technique. Instead, those who have studied it consider it a test approach that can be applied to any test technique, at any stage in the development process. The key is not the test technique nor the item being tested or reviewed; the key is the cognitive engagement of the tester, and the tester’s responsibility for managing his or her time.

Давно-давным, при первом знакомстве с этим термином, я подумал, что речь идет о разновидности dumb monkey testing (открой сайт и бессистемно кликай, авось, найдешь ошибку), подходом, который я не люблю, но в котором в какое-то время даже преуспел.

Случайно я нашел однозначный способ резко и безапелляционно закрэшить какую-то из версий «Reuters Xtra 3000»*, и достиг этого именно потому, что внимательно, но достаточно бестолково переходил по линкам и заполнял поля каким-то подходящим по смыслу бредом. Нечем гордиться.

* Гигантская софтина для трейдеров международных товарных бирж.

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

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

Потом понял, что (настоящих тестировщиков неоднозначность и разное толкование профессиональной терминологии уже не удивляет!) это даже не вид тестирования, а вообще ПОДХОД. А подход подразумевает шиииииирокое поле самостоятельной деятельности. И что этот подход — дитя agile…

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

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

Знаю, не знаю — делов-то… Надо — изучу. Не надо — ну и не надо.

Я очень люблю Error guessing. Искать «слабые места» в софте я предпочитаю более логически, нежели интуитивно. Уметь «вычленять» проявление багов в определенных, труднодоступных местах, умение предупреждать места их нахождения, а затем действительно суметь их найти, обосновать, указать на точную причину проблемы — это круто. Очень круто. Это круче и ценнее, нежели «Вот вам скриншот, вот подробные шаги — разберитесь сами». Хоть и дольше и затратнее.

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

Поэтому — микс органичен!

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

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

В agile я поначалу не понял, что именно следует делать мануальному тестировщику — кругом все носятся с автоматизацией…

Потом понял, что если программа предназначена для использования людьми — без мануального тестирования не обойтись. Проблема только в организации такой работы — привыкшим к последовательным этапам и подробным тест-кейсам бывает сложно переориентироваться. Но именно тут и работает это самое «исследовательское»! Ну, оно же и родилось в agile и для agile.

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

Собственно, какая там теория, если это просто подход, а не методология…

Учеба «по-блогам» — это круто (я сам ее продукт), но в принципе у такой учебы есть большие проблемы.

Учеба по-блогам

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

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

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

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

Он думает о том, как расположить и структурировать информацию… Он думает о том, что «вот сделаем каталог, и это, вероятно, будет способствовать продажам.

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

Куда там…

К чему приводит такая учеба: когда-нибудь ученик все равно захочет увидеть стройную систему в своих знаниях. Захочет «силлабус». Если найти систему сложно — придется строить ее самостоятельно. Придется делать обобщения и выводы, а они могут существенно отличаться от реального положения дел.

Примеры пагубного воздействия учебы «по-блогам»

Девчонки, я мыла лицо мылом с яблочным ароматом. И у меня исчезли прыщи. Мой вам совет — чтобы прыщи сошли, используйте «яблочное» мыло!

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

Я сто раз ходил «на дело», и попался только потому, что меня сдали подельники. Мой вам совет — на дело надо ходить только в одиночку.

Ученик не знал о том, что «если воровал, значит — сел» при любом раскладе, и что подельники — просто совпадение. Но вывод уже сделан, и возведен в степень системы.

Я второй год бился над рейтингом моего интернет-магазина, и смог его поднять только после того, как поменял домен. Мой вам совет — заранее выбирайте подходящий домен для сайта.

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

Еще раз: учеба «по-блогам» хороша для прояснения деталей, но с системой профильных знаний надо знакомиться по книгам и людям, которые с этой системой УЖЕ знакомы. Ищи первоисточник, а не его пересказ

«Ваш Карузо ужасно фальшивит! Я его лично не слышал, но Рабинович мне кое-что напел».

Моя проблема с исследовательским тестированием была в том, что я знакомился с ним по-блогам. Впечатление получилось неполное, неточное, неясное. И каждая новая статья приносила путаницу в стиле Алисы в стране чудес («Чтобы стоять на месте — надо быстро бежать!»)

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

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

Я рад, что смог полностью прочитать «Secrets of a Buccaneer-Scholar». Оказывается, этот подход ИссТест — серьезная, фундаментальная система жизнеобразования. Exploratory — это не столько стиль тестирования, сколько стиль жизни отдельно взятого Джеймса Баха. И подход «исследовательское тестирование» — следствие его рутинной жизнедеятельности.

После знакомства с его подходом к жизни и к обучению вообще, термин «исследовательское тестирование» становится весьма простым, понятным, недвусмысленным, доходчивым. Он органичен для его автора. Это, грубо говоря, сам Джеймс Бах. Ни добавить, ни отнять — бери, как есть.

(Не) бросай на фиг школу!

Способ учебы, который использует Бах, для «среднего» человека немыслим. Если судить о нем по первому впечатлению, и попытаться следовать его жизненному примеру, то картинка такая:

«Бросай нафиг школу!

Не ходи в университеты!

Учись самостоятельно!

Это может сделать каждый!»

Ничего подобного.

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

Самообучение сродни мастерам в agile – для того, чтобы быть «Гибким», надо сперва стать крайне собранным, огранизованным, самостоятельным, сильным духом. Иначе тебе будет нужен постоянный менеджер, который будет давать тебе работу, зарплату, пинок под зад, затем ты начнешь искать себе следующего менеджера… А дракона нужно убивать в себе.

Типам вроде Баха можно завидовать. Я, например, в свое время очень хотел бросить школу. Не посмел, отчисление из школы считалось очень серьезным наказанием. Хотя по-молодости несколько раз был на грани 🙂

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

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

Может быть, мне просто повезло?

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

И скатиться очень легко. Начнем хотя бы с «Надо бросить школу».

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

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

Бах считает, что пойти «его путем» может каждый. Точнее, он призывает попробовать. В самом начале книги есть знаковый диалог между ним и типичной учительницей:

«Mr, Bach, I want you to know that I will recommend against you speaking at our school again,» she said. «Your message is dangerous for children to hear.»

She was almost right. It was dangerous, what I said — dangerous for her. To maintain a docile herd of students, her school needs them to accept certain truths:

* You must study what we tell you. What we say is the only thing that matters.

* You must pass our tests. Our tests measure the only important things about you,

* You must attend school. Only through schooling can you hope to enjoy a good life.

This is what I call schoolism — the belief that schooling is the necessary and exclusive way to get a good education. Musf and only!

«I told them about myself,» I said, «and how I came to be here, I told them the truth.»

«It may be true for you,» she replied. But these kids aren’t super smart like you. They don’t come from well-off families. They’re barely staying in school, and you just told them that they don’t need to be here. They do need to be here!»

«Yes they could be successful if they put in the work,» she conceded. «But I don’t think they heard that part of your message. I’m barely holding on to some of these kids as it is. I’m afraid you’ve made my job much harder, Mr. Bach. Some of them are going to take a ‘what the hell’ attitude instead of applying themselves.»

«So what if they do?» I replied. «This is America. They probably won’t starve. They probably won’t be eaten by wolves. If they don’t care about education, they may be forced to 14 work at low-skilied jobs they won’t enjoy, such as fast food or house cleaning. However bad those fates may sound, they are neither fatal nor permanent. Or perhaps they will accidentally educate themselves by starting a new business, building things, or doing theatre, music, or sports. Are you worried they’ll turn to crime? Then show them more options, not fewer. They will learn and grow from anything that happens, unless they believe there is no hope. Your job is not to make them huddle quietly in a corral, but to help them get out there and seek their fortunes. Show them a way!»

Ближе к концу книги он вообще говорит:

A typical public school in the United States is all about honoring the herd. The students are supposed to be sheep, but too many of the teachers are just older and fatter sheep. Schoolism is a herd mentality.

Прошу учесть, что фраза высказана в определенном контексте. Вырывать ее не следует.

Итак, Бах считает, что пойти «его путем» может каждый. Логично предсказать, что заниматься исследовательским тестированием может каждый?

Не может.

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

Нужно уметь учиться «на ходу» НЕ ТОЛЬКО в процессе тестирования. Это должно быть нормой жизни. И умение это заключается не только в постоянном чтении блогов, it4business форума или статей с Software-Testing.ru.

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

Вот как Джеймс учит историю:

Roman Empire fell on some date. What was it? 476? That is not interesting history to me. I care about why Rome fell, not whether it fell on a Tuesday.

What authentic problem motivated my questions? My need to make sense of the world. I wanted to understand human events on a millennial global scale, as well as a household daily scale. At the time, I thought that having the ability to analyze society and history in terms of the questions on my syllabus would help me be more comfortable even within the confines of my own life experience.

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

По плану у нас записано «Причины падения Римской империи».

Знаете причины?

Ну, рабов у них было слишком много, и вот, ослабли…

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

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

Однако умение учиться самостоятельно доступно многим.

Вот как Джеймс учится «для работы»:

One day a lawyer called me with a proposal: «We’d like to hire you to find if a software product infringes our patent. Is that the kind of testing you do?»

I said, «Yeah!» (I had never tested a product for patent infringement before. But I could test for anything.)

She asked, «Do you know the technology behind network switching in Windows?» I said, «Yeah!» (I didn’t know what she was talking about. But I could learn it.)

Then she asked me to read the patent and examine the product. Look at the first claim in that patent:

«1. A method for dynamically routing data over multiple dissimilar parallel wireless networks that are each monitored for status information, the method comprising: maintaining a priority of each wireless network, the priorities indicating a most preferred path; determining availability of each wireless network based upon status information associated with each wireless network; indicating a current most preferred network from the wireless networks determined to be available, the indication being based upon the network priorities; switching from a current network, which is dissimilar from the current most preferred network, to the current most preferred network during a transmission, at least one of the current network and current most preferred network being time continuous; and remaining connected to the current network for a period of time after switching to the current most preferred network.«

Did you read it through? If not, you’re in good company: me. According to the Flesch-Kincaid Index, which measures reading difficulty, that text is written at a sixtieth grade level. I found it terribly confusing, at first.

This was a high-pressure learning challenge.

How do you think I felt when I finally forced myself to read all those words? I was being paid three hundred dollars per hour. My client expected me to read the patent and understand it. I didn’t understand it. Was I intimidated?

No. By the time you finish this book, you won’t feel intimidated by complex and obscure text, either.

Complexity and obscurity are illusions. They are figments of mind-shock. For a buccaneer mind-shock is no cause for alarm. It is a temporary condition, a big wave coming over the bow. There’s a splash. I get wet. But steady on the helm, there. She’ll pull through.

On first reading, I wasn’t sure I was qualified to do the project. The expert on the other side of the case, a professor at a well-respected university, was taken aback to discover his intellectual opponent was a high school dropout.

Guess who won the case.

By the time we went to trial, I had become a wizard of the patent. I wrote a program to separate and index each sentence, clause, and word. I memorized most of the three patents involved, analyzing them over hundreds of hours. I absorbed a dozen books on networking technology. I constructed a dedicated test lab. I studied the underlying instructions that comprised the product, and used a variety of hacking tools to analyze its operation. I was better prepared than the professor. He spent two or three days testing it. I devoted nearly four hundred hours to testing it. I brought in a video crew to film me testing it. I tested it inside out and sideways.

The jury noticed.

The facts were on our side, of course. That helps when you need to win a lawsuit. But here’s my point: the reason I plunged into this project, even though I didn’t know whether I was smart enough to complete it, was because I knew I was smart enough to start. Starting is what matters. I’ll be smarter by the finish.

That’s one of the benefits of being a buccaneer-scholar. With a nonstop education you are in a position to attack opportunities that sail your way, instead of steering clear with «Sorry, I’m not qualified.»

When the lawyer first called me, I was in the midst of writing the key elements of my buccaneering method for this book. That case became a fifteen-month interruption.

Круто.

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

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

Computer science

1. Опишите различия между нитью и процессом.
2. Опишите основные принципы работы Virtual Memory. Какой максимальный объем виртуальной памяти доступен процессу на 32х битных системах?
3. Что такое функции высшего порядка? Опишите алгоритм работы функций высшего порядка — map и fold (также встречается под названием reduce).
4. Какая сложность у процедуры вставки в простое бинарное дерево поиска в среднем случае? Какой сложностью обладает алгоритм, проходящий по одному простому бинарному дереву из n элементов, и вставляющий эти элементы в другое простое бинарное дерево из m элементов?
5. P=NP? Перечислите самые известные NP задачи.
6. Опишите различия static и dynamic typing. А что такое слабая типизация?

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

Это Джеймс, понимаете, Бах лениво встанет, спросит «What a feeglee-meeglee?», и убежит обратно в США. А большинство пойдут неспешно домой, утрут слезки, и будут зубрить, чтобы на следующем интервью не «опозориться». Зубрить, а не учить алгоритмы…

Тема скользкая, но…

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

А уж каким ужасающим было мое первое интервью в тестировании… 🙁

В GlobalLogic, поскольку компания большая, есть особые, ежегодные митинги оценки знаний каждого работника в отдельности. На одном таком митинге-оценке меня спросили «Какие виды тестирования ты знаешь? Давай, перечисли как из пушки…» Но вместо «пушки» я сделал паузу, затем меня пробило на странное «хи-хи», и ответ не получился. Скомкался.

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

Я получил оценку «as expected» и пошел продолжать тестировать нашу сложную, многомиллионно стоящую софтину. И выпил изрядно квасу, бо вспотел. Ведь если бы оценка в итоге получилась бы ниже «as expected», и я не потдвердил бы свой высокий статус software engineer…

Если кто не знает, квас в GlobalLogic — БЕСПЛАТНЫЙ и вкусный.

Забивай себе «чердак» лично

Если смотреть на учение Баха поверхностно (первое впечатление), то получится, что чему-то специально учиться не стоит. Учиться надо только тогда, когда есть необходимость. И только тому, чем нужно оперировать прямо сегодня и сейчас.

Неверный вывод.

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

На эту тему вспомнилась сцена знакомства Холмса с Ватсоном в «том самом» сериале. В самом начале есть такой диалог:

Сыщик берет в руки увесистый фолиант.

— Мистер Ватсон!

— Да!

— Это роман?

— Да!

Холмс обескуражен.

— Вы что, читаете романы?!

— А вы хотите сказать, что не читаете?.. Это Диккенс.

— Не читал, не читаю и не собираюсь читать… Я вообще не читаю беллетристику.

— А история, философия?

— История, философия – в руки не беру!

— Ну, а как же Аристотель, Жанна д’Арк… Коперник?!

— «Коперник»? Знакомая фамилия… Что он сделал?

Ватсон фалломорфирует.

— Боже мой!.. Так ведь это же он открыл, что Земля вращается вокруг Солнца! Или этот факт вам тоже не известен?

— Нну-у… мои глаза говорят мне, что, скорее… солнце вращается вокруг земли… Впрочем, может, он и прав ваш этот… как его? Коперник!

— Простите меня, Холмс. Вы человек острого ума, это сразу видно. Вы превосходно знаете химию… Как же вы не знаете вещей, которые известны каждому школьнику?!

— Ну, когда я был школьником, я это знал, а потом основательно забыл!

— Так вы что – хвастаетесь своим невежеством?!

— А вы, Ватсон!? Вы можете отличить грязь на Риджин-стрит от грязи на Пикадилли?.. Или пепел гаванской сигары от пепла манильской? Или можете мне сказать – что написано в третьем параграфе уложения о наказаниях Британской Империи? Можете?!

— Но ведь… я говорю… об элементарных вещах, которые знает каждый!..

— Но я ведь – не каждый!! Ватсон, поймите… Человеческий мозг – это пустой чердак, куда можно набить всё, что угодно. Дурак так и делает – тащит туда нужное и ненужное. И, наконец, наступает момент, когда самую необходимую вещь туда уже не запихнёшь. Или она запрятана так далеко, что её не достанешь… Я делаю по-другому. В моём чердаке только необходимые мне инструменты! Их много. Но они в идеальном порядке и – всегда под рукой! А лишнего хлама мне не нужно.

— Учение Коперника… по-вашему, хлам?

— Хорошо. Допустим, земля вращается вокруг солнца.

— То… то есть как, допустим?!

— Земля! Вращается вокруг солнца… Но мне! В моём деле! Это не пригодится.

Ватсон окончательно фалломорфирует.

— Как ужасно было бы жить в мире, где не с кем было бы поговорить о поэзии… о живописи… о политике… Где каждый знает только то, что ему нужно для дела…

— Мистер Ватсон, я могу вас утешить. Дело в том, что таких людей, как я, в мире очень немного… Может быть, даже я такой один.

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

Ватсон знает и ценит ВСЕОБЩЕСТЬ образования. Знать, кто такой Коперник, знать философские разности — это круто.

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

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

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

За необычность следует благодарить Ватсона, который ВИДИТ то же, что и Холмс, но не НАБЛЮДАЕТ (пример с количеством ступенек к его двери — Ватсон видит их ежедневно, но ни разу не утрудился их сосчитать).

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

Кстати, подсчет количества ступенек — лишняя информация в чердаке Холмса 🙂

Подход Ватсона тоже слишком всеобщий — он ценит ВСЕОБЩЕСТЬ знаний выше, чем их специализацию. Но, например, лично меня кормит именно специализация, которая построена на большой пласте знаний, не связанных с тестированием. В детстве под одеялом с фонариком я читал отнюдь не Майерса и Бейзера… 🙂

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

Умным делает нас не возможность цитирования, а способность обобщать и делать выводы.

Догадайся по капле воды о существовании океана…

Способность решать возникающие проблемы (неважно — в тестировании или в приготовлении суши).

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

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

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

Но как вы догадались, что я не «Холмс», мистер Холмс?

Стать таким, как Холмс, сможет не каждый. Им не стать — им надо быть. К Баху это относится в той же мере.

Холмс или ЛСЭ (логико-сенсорный экстраверт)

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

Один из наиболее выдающихся изобретателей (Томас Эдисон).

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

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

Выполняя работу, ЛСЭ иногда опасается, что делает её несвоевременно, поэтому старается опередить события.

Лично я интроверт, да еще и инуитивно-логический. Я не Холмс. Я не Бах. Мне не стать настоящим буканиром?

Стать.

Просто мне не стать лично Джеймсом Бахом.

Кем Канер, по определеннию Баха, тот еще буканир. Но одновременно — еще и один из самых «систематически образованных» людей:

Cem has a doctorate in psychology and a law degree, as well. He’s one of the most systematically educated people I know, and yet one of the most humble about what he knows. His studies are deep and his papers are heavily footnoted. Cem inspired me to study the philosophy and ethics of science.

Я могу сделать микс… И если мне суждено не подавиться собственным изобретением, то дела идут отлично.

Хотя, есть определенная прелесть в том, что ему мною тоже никогда не стать, и я могу подумать о самостоятельном методе самообучения 🙂

Я нашел в книге Джеймса много того, что сам хотел бы сформулировать, но еще не дорос до этого. Мне такие книги ценны.

Избранные цитаты из книги «Secrets of a Buccaneer-Scholar»

1

If I can find the one person in a hundred who value what I am and pay for it, the other ninety-nine won’t matter.

2

I don’t know how to talk about things that don’t matter.

3

My public status comes from

— my reputation,

— Reputation is the story other people tell about me.

— my portfolio,

— My portfolio is the part of my work available for review.

— and how I do on life’s tests.

— A test is any opportunity to demonstrate my knowledge and skill.

For instance, I’m attracted to software testing as a job because testing problems have no fixed solution. Every testing problem is a learning challenge. Testing always seems fresh to me, and it rewards ingenuity. It’s a game where the rules are sometimes murky and mysterious, and for me, that’s part of its charm. Perhaps the secret to happiness is finding the games we love to play, instead of learning how to win at games we hate.

4

Of course I read every testing book I could find. I discovered software testing standards and studied those, too. I studied most evenings and weekends.

At first I thought I would learn a lot from the other testers. There were more than four hundred of them in my building. But talking to them revealed a startling truth: nobody cared.

Almost nobody. In the first six months I worked at Apple, out of all the testers in the software testing division, I met maybe ten who were also reading testing books. The rest muddled through without much ambition to master their craft. It was clear that catching the college kids would not be difficult, after all.

GREAT SECRET

Most people, most of the time, don’t try very hard.

5

The pattern I experienced at Apple would be confirmed almost everywhere I travelled in the computer industry: most people have put themselves on intellectual autopilot. Most don’t study on their own initiative, but only when they are forced to do so. Even when they study, they choose to study the obvious and conventional subjects. This has the effect of making them more alike instead of more unique. It’s an educational herd mentality.

6

What this means for success is simple. Knowledge workers succeed, not based on what they know, but rather how they learn. It’s the difference between a pantry and a supermarket. I don’t stock my pantry with a year’s supply of every kind of food. Even if I did, the food wouldn’t be fresh. Instead, I go to the supermarket when I need something. The market has an amazing variety of anything I could want, whenever I want it. I keep myself from starving by living near a system that provides me with food, and by knowing how to use that system.

The supermarket of learning is online, a Google away. Or it’s embodied in the minds of my colleagues, whom I email when I need emergency tutoring. It’s in my personal pantry of books}1& two thousand of them, most of which I haven’t read—they are standing by in case I need them.

Узнаем подход Холмса с его «чердаком»? Еще бы…

7

At first he (его брат Джон Бах, впоследствии работал тестировщиком в Microsoft) didn’t believe he could be a tester, because he had no training in computers. Like most people, lack of self-confidence is the first barrier to get over.

«You don’t need computer training, Jonny, but you do need to start learning,» I told him. «That’s under your control. You can learn anything you want about computers, starting now.»

I lectured him and I drilled him in the ways of examining technology to uncover its deficiencies. I stood him in front of a whiteboard and made him practice explaining his methods and results. Slowly he lost his fear.

[vodpod id=Groupvideo.3369521&w=425&h=350&fv=id%3DgFupCdM3pqaO%26linktarget%3D_self]

• Асхат Уразбаев – учредитель ScrumTrek
• Илья Гаврилов – начальник отдела тестирования, Exigen
• Алексей Лупан – testitquickly.com

О чем говорили

• Как вы стали тестировщиком?
• Чем программист отличается от тестировщика?
• Какой процент кода покрывать авто-тестами?
• Есть ли вред от TDD?
• Кто пишет и кто запускает тесты?
• Имеет ли смысл иметь выделенного тестировщика-автоматизатора и в каких случаях?
• Как проходит планирование итерации с точки зрения тестировщика?
• Где хранить тесткейсы?
• Как автоматизировать тестирование GUI и что такое архитектура тестирования?
• Рост продуктов – как успевать все протестировать за итерацию?

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

главный редактор портала Software-Testing.Ru ©

Перевел: Алексей Лупан,

худший друг программистов, TestItQuickly.com ©

Момент истины

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

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

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

А если нет – посмотрите видеозапись…

Алексей Баранцев

[vimeo=https://vimeo.com/5521072]

Уважаемые коллеги!

Я думаю, вы уже поняли, что в agile нет никаких других проблем, кроме как с тестированием. Всё остальное в agile хорошо (кроме вопросов о рефакторинге), а проблемы, так или иначе, связаны с тестированием. Я в первую очередь буду говорить о приёмочном тестировании, но также и о другом тестировании, которое… Впрочем, об этом «которое» мы как раз и поговорим.

Часть I, Психологическая, а местами даже геополитическая

Начнём с основ.

Наверняка в детстве вы видели мультик «Великая битва слона с китом»? Мультик потрясающий.

Там в течение семи минут реально слон бьётся с китом самыми разнообразными способами. Колбасит их там по-страшному, они сплетаются, расплетаются, поглощают друг друга, подавляют, что угодно делают… Сейчас примерно такая же ситуация происходит с двумя парадигмами в разработке программного обеспечения — с agile-направлением и не-agile-направлением. Я даже не знаю, как этот «не-agile» назвать.

Голос из зала: Процессное!

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

Вы знаете, в чём главное отличие agile от не-agile?

Голос из зала: А вы расскажите.

А вдруг кто-нибудь знает?

Голос из зала: Бизнес-ориентированность разработки.

Ну, бизнес-ориентированные тут все…

Голос из зала: Способ организации процесса другой.

А в чём же разница?

Голос из зала: Ну, что там у нас? Итерации и инкрементальность…

Итерации и инкрементальность впервые ввёл RUP, который настолько мощно-процессный, что хуже уже некуда. В чем разница?

Голос из зала: Agile позволяет установить тотальный контроль над разработкой (хохот в зале)

Это новость для меня, если честно 🙂

Из зала — Александр Александров: Моё мнение может быть кому-то не понравится. Agile это религия, в него надо либо верить, либо нет, а вот в процессы верить не нужно.

Да, очень верное замечание и оно очень близко к тому, что я собираюсь рассказать. Если вы посмотрите на RUP и на SCRUM, то вы увидите, что там довольно много похожих элементов. Там есть итерации, они достаточно короткие (в RUP типичная итерация, как и в agile-процессах – это две недели, иногда меньше), и в этих итерациях точно так же происходит всё — дизайн, разработка, тестирование, выпуск готового продукта. То же самое происходит в agile. Разница между ними по-внешнему виду, если посмотреть на схемы и на то, что за чем происходит, не очень заметна. Разница в чём-то другом. Разница не на уровне буквы, а на уровне духа присутствует.

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

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

Stand up meetings. Вот вам типичные stand up митинги в стиле RUP — «Встали! Так, сегодня ты делаешь это, ты — это».

Все получили наряды, все пошли работать. Stand up митинги вполне уместны и в RUP, и в любом другом подходе. Нормальная инженерная практика — не делать длинные совещания. Очень хорошая практика.

Но, конечно, по сути от этого ничего не изменится, если мы все эти инженерные практики затолкаем в RUP – он останется RUP’ом, agile’ом от этого не станет. Дух у него от этого не изменится.

И я собираюсь этот дух продемонстрировать на некоем культурологическом феномене…

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

Да, кстати, обратное тоже верно. Смотрите, есть все эти артефакты, все эти деятельности, ведь их можно же в agile выполнять? Никто же не запрещает в agile генерировать test-ideas list. Берем wiki и записываем туда наши идеи по тестированию.

Тест-скрипты делаются? Делаются.

Описание тестовой стратегии? Да, на white-board записали, что тестируем, а что нет — вот вам и тестовая стратегия. Выбор инструмента — это тоже часть тестовой стратегии.

Test environment configuration – а куда от него денешься?

Test automation architecture – когда у вас десяток тестов, то у вас все в порядке. А когда у вас их сотни и тысячи, вам уже приходится аккуратно разрабатывать архитектуру, и будете ли вы ее документировать аккуратно или не будете — так или иначе она существует. То есть, все эти артефакты так или иначе у вас появляются.

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

В чем же этот самый дух?

Есть в литературе и в живописи такое течение — стим-панк. Или дизель-панк. Его эстетика базируется на некоторой романтизации викторианской эпохи, когда были первые попытки все механизировать, картина мира представлялась полностью механистической. Были попытки сделать механического человека, появились первые паровые механизмы — паровозы, паровые машины, которые вызывали у людей очень большой энтузиазм. Люди поняли — «О, сейчас мы автоматизируем всё! Всё будут делать механизмы, а люди будут их обслуживать».

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

Так вот, классические подходы устроены примерно так же.

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

Какая от этого выгода?

Сейчас я вам буду рассказывать про отличие процессных подходов в agile и не-agile. В чём между ними самое главное по сути отличие?

Мы пытаемся построить работающую систему, которая должна что-то выдавать на выходе, а именно — программный продукт. У нас есть люди, из которых мы вот эту систему строим. Люди по своей сути элементы ненадежные, они болеют, они умирают, ругаются между собой, увольняются, им надоедает работа, они ленятся, они прогуливают иногда. Что нужно сделать, чтобы система из ненадежных элементов работала? Нужно её сделать с огромной избыточностью.

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

Мы тут недавно ездили в Израиль на конференцию, посвященную разработке и тестированию микропроцессоров, и там услышали совершенно потрясающее заявление одного из гуру в этой области: он сказал, что в микропроцессоре очень много ошибок, огромное количество ошибок. Почему же микропроцессоры при этом работают? Да потому, что 90% всех сбойных сигналов, которые происходят внутри микропроцессора, вообще не доходят никак до выходов, до «ножек», они не оказывают совершенно никакого влияния. Это он сказал про ошибочные сигналы. А какой отсюда ещё следует вывод? Те же 90% процентов полезных сигналов тоже не доходят до выхода. Вот какая избыточность у этой системы, вот какой низкий у неё в результате КПД (коэффициент полезного действия). Но за счёт этого мы можем построить из ненадёжных элементов вполне надёжную систему. За счёт понижения КПД отдельно взятого человека.

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

А в agile-процессах — нет.

Если вы читали книги Демарко, Листера или даже Брукса, вы, наверное, знаете, что они советуют делать, когда у вас остается мало времени и вам надо ускорить разработку. Что надо сделать? Надо уменьшить размер команды. Почему? За счет этого вы повышаете КПД её отдельных элементов, вы позволяете им оказывать большее влияние на общий результат работы системы за счет уменьшения количества связей, которые как раз всё это КПД гасят.

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

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

Голос из зала: У вас в команде все хорошие?

Стараемся…

Голос из зала: Нет, вы скажите — «да» или «нет».

Если я скажу «да» — вы поверите? (смех в зале)

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

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

Если у вас процесс agile, то вы говорите, людям – «вам будет работаться хорошо». Да, в проекте с agile работать хорошо потому, что там много fun’а. Все эти инженерные практики нацелены на то, чтобы добавить в работу какой-то интерес.

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

Так вот… Что же делать, откуда брать таких людей? Был такой писатель, учитель Филиппа Дика — Теодор Старджон, и как-то его спросили, как он относится к научной фантастике. Это были пятидесятые годы, он писал социальную фантастику, а спросили его о научной. Он сказал, что «по моему убеждению, 80% научной фантастики, которая сейчас пишется, это дерьмо». Потом подумал и сказал: «Но если хорошенько подумать, то вообще 80% того, что делается — это дерьмо».

Да, хороших программистов, в общем-то, мало. Поэтому, если вы сейчас посмотрите в англоязычной литературе, то увидите очень много статей на тему «Почему agile-процессы проваливаются?» Не должны они проваливаться. Вот я, Кент Бек, сделал все по agile, и все классно, все работает. Вот я, Майкл Болтон, тестирую, у меня agile, и все круто тестируется, а вот другие люди делают по agile, и у них не получается. Почему? Потому, что они, когда строят, берут ненадежные элементы. Кент Бек надёжный элемент, Майкл Болтон тоже. Но не все такие гении, к сожалению.

Что делать?

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

И тут мы подходим к такой проблеме: agile придумали программисты для программистов. И они придумали для себя много фановых штучек, практик. Они придумали парное программирование. Тестировщики потом как-то попытались делать парное тестирование — не получилось. А парное программирование работает хорошо.

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

И тут мы переходим к технической части.

Часть II, Техническая

Почему тестировщикам ничего не придумали? Потому что программисты, когда начали придумывать… наверное, самой первой штукой был eXtreme programming, там это зафиксировали, а все остальные практически без изменений унаследовали… Они сказали: «Так, бывают unit testing и acceptance testing. И unit testing мы вообще себе забираем, а вам, тестировщикам, остаётся некий acceptance testing. И вообще, этот acceptance testing может делать сам заказчик, если дать ему подходящие инструменты». И всё, тестировщикам не осталось ни работы, ни развлечения.

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

Тогда программисты сказали: «Так, теперь всем вам будет FIT!» Ну, или FitNesse, более расширенная версия.

Тестировщики попробовали пользоваться FIT – нет, не айс *… Никакого fun нет.

* Тонкий намек на рекламу.

Почему? Оказалось, что у них разной работы гораздо больше. Помимо unit testing и acceptance testing есть еще и интеграционное тестирование, где надо вглубь системы руки по локоть запускать, и FIT туда не влезает. Есть системное тестирование, условно говоря, его можно назвать acceptance testing, но FIT помогает только если у вас веб-приложение. Если вы зайдете на сайт FIT и посмотрите, какие там есть предопределенные, стандартные fuxtures — вы найдете fuxtures для JDBC и для веб-приложений. Всё!

А если у вас какие-то сложные протоколы, а если вам надо SMS обмениваться, если у вас нормальный обычный GUI-интерфейс — что вам делать? Нет, там не работает FIT, он doesn’t fit вообще!

Unit testing

Integration testing

System testing

Performance testing

Reliability testing

Security testing

Usability testing

Portability testing

Acceptance testing

Тестирование производительности, тестирование надежности (когда система у вас сутки работает и при этом не падает), тестирование безопасности — FIT не работает. Тестирование удобства использования, тестирование переносимости, кросс-платформенное, кросс-браузерное, кросс-ещё-не-знаю-чего… на разных архитектурах, на разных процессорах, куда все это запихать?

Программисты сказали: «Мы себе забираем unit testing». А все остальное, по-видимому, следует отнести по их мнению к acceptance testing.

Хорошо. Мы, тестировщики — мы говорим «О’кей! Всё это вот будем считать за acceptance testing, теперь мы будем заниматься всем этим. А куда от этого денешься? Надо — значит надо».

А программисты: «У вас есть только FIT!»

Что мы должны сказать в ответ? Мы должны сказать этому решительное

«НЕТ!»

FIT нам мало. Мы хотим много всего интересного.

Откуда взялся FIT? FIT взялся вот откуда.

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

Но что предлагается Емеле для этого?

Емеля, ты хочешь лежать на печке и играть на балалайке 24-й каприс Паганини? О’кей! Сейчас ты будешь пахать как папа Карло, долго, а потом (может быть – если требования не будут меняться, если то и это не произойдет, если мы интерфейс не поменяем, и все твои тесты будут работать) ты сможешь лежать на печке и играть на балалайке.

Фиг!

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

Более того, что они нам предлагают? «Ну, вы же программировать толком не умеете, да?! Мы вам сделаем убогий язык, на котором вы будете программировать в виде таблички».

Человеку, который умеет программировать, это дико. Программировать в виде таблички – это же неудобно! У нас есть хорошие инструменты, хорошие среды разработки, можно пользоваться сторонними библиотеками, можно писать свои библиотеки, чего только там нет… А нам вместо этого говорят: «Вы будете программировать в виде табличек», которые надо писать на wiki-подобном языке с такими вот палочками, в совершенно нечитаемом формате. И даже WYSISWYG толком нет! И после этого они нам говорят: «А вот потом вы будете лежать на печке. И играть на балалайке…»

Увы.

Увы, не наступает это. Именно поэтому мы говорим решительное «НЕТ!»

Наш ответ на это: «Мы не хотим быть программистами на убогом языке. И вообще, что вы, собственно, ожидаете от тестирования, товарищи разработчики, менеджеры проектов и прочие?

Чего вы хотите?

Чтобы у вас просто были тесты, написанные на FIT, которые постоянно не работают из-за того, что всё меняется?

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

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

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

Своего дела у них много.

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

Представьте себе, что целый взвод всей толпой приходит в деревню, заходит в один дом и ищет там боевика. А они все в других местах рассредоточились. Зачистка местности предполагает, что мы проходимся по всей этой местности, и всё посмотрели, всё проверили. Конечно, боевики попрятались по подвалам, но мы говорим: «На поверхности боевиков нет!» Они все попрятались, но, по крайней мере, они не ходят внаглую с автоматами по деревне. Мы в первую очередь произвели небольшую зачистку.

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

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

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

* Вендор — производитель/продавец.

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

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

Назовем зачистку функциональным тестированием. Ковровая бомбардировка — это нагрузочное тестирование (тестирование производительности, тестирование надежности).

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

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

Тестирование удобства использования — это дегустация.

Здесь можно даже вместе с заказчиком собираться, совмещать приятное с полезным. «А вот какую удобную кнопочку мы сделали!», «А вот эту операцию мы выполняли за десять шагов, а теперь можно её за три клика сделать!» – и от этого получаете удовольствие вместе с заказчиком.

Видов тестирования много разных. Не надо зацикливаться на чём-нибудь одном, ни на unit-тестировании, ни на FIT, ни на Selenium, ни ещё на чём-то. Смотрите на мир и на жизнь шире.

Ну и наконец, если у вас тестировщики уже всё протестировали, больше им заняться нечем, остается ещё очень большое поле деятельности, которое не относится напрямую к тестированию. Иногда его называют quality assurance. Возьмите тестировщиков, которые умеют программировать, и чтобы им было весело жить, пустите их читать ваш код. Пусть они занимаются code review. Пусть они тоже повеселятся, читая ваш код.

Единственной метрикой качества кода является количество «WTF?» в минуту 🙂

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

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

Для ясности

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

Понятно, почему он так легко  проповедует подход «Тестировщик должен уметь программировать«?

Понятно, почему его предложение wtf-чить код программистов — не праздная выдумка? Тем более, что дух agile к этому подходу даже благоволит (долой роли!).

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

Некоторых тестировщиков от такого подхода колбасит в другую крайность: «Да если бы я умел программировать, разве сидел бы я тут и по кнопкам кликал?!…«

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

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

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

Спасибо.

В текст перевел: Алексей Лупан (testitquickly.com)

Вместо введения

Доклад был представлен на конференции SQA Days’2009 24 апреля. Его можно было послушать в виде слайдкаста (слайды, снабженные звуком), но слайдкаст утерян.

Текст совсем чуть-чуть поправлен и снабжен (не всеми) картинками в нужных местах.

Руководство по тестированию в Agile

Кто-нибудь работает по эджайлу? Пожалуйста, поднимите руки. Уау… А из тех, кто не поднял, кто-нибудь собирается это сделать? Хорошо. Давайте я сначала представлюсь — меня зовут Асхат Уразбаев, меня уже представили, поэтому я коротко… Он сказал всю правду обо мне, немножко преувеличил местами… Работаю в компании ScrumTrek, мы занимаемся внедрением гибких методологий, помогаем компаниям и организациям всем этим заниматься.

Итеративность

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

Что такое эджайл — в большинстве случаев это просто итеративная разработка. Видите, там цель — бизнес-цель — сменилась?! Она во время пути, естественно, меняется. Мы следуем так, чтобы не выпускать ее из вида, даже если требования меняются, мы, постепенно корректируем движение и направление нашего проекта. Работаем при этом вот такими короткими итерациями.

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

Проблемы ответственности

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

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

И еще одна проблема: «Настоящий мужик решает свои проблемы сам». У меня серьезный баг, я с ним вожусь уже три недели, но я буду сражаться, пока не сумею его побороть, потому что я — мужик, у меня есть проблема, но я о ней никому не скажу, я всегда сам…

Это — проблема ответственности.

Самоорганизация

Какой ответ на это дает эджайл? Самоуправляемые, самоорганизующиеся команды. Команды у которых до какой-то степени нет менеджмента — какой-то менеджмент, конечно, есть всегда, только он переквалифицировался. Product owner не раздает задачи людям — команда сама распределяет задачи.

Вот определение, которое мне очень нравится:

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

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

Если крупными мазками набросать, что такое самоорганизация, то это коллективное принятие решений… Я не знаю, насколько вы с этим согласитесь, но ответственность — это право принимать решения. Если мы хотим коллективной ответственности от команды за что-то, то мы должны коллективно принимать решения. Согласны? Все кивают, удивительно. Несколько лет назад все качали бы головами «Нееееет, мы не согласны, фигня это, всегда должен менеджер все решать…»

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

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

Взаимная ответственность не работает без прозрачности.

Например… знаете, что такое daily scrum? Или stand up meeting? Это когда мы ежедневно общаемся на какую-то тему. Это способ увеличить прозрачность. Без такой прозрачности доверия между людьми не будет. Это способ установить взаимоответственность между людьми внутри команды — я отвечаю перед тобой, ты отвечаешь передо мной. Ты что-то не сделал? Ты виноват не по отношению к менеджеру, а по отношению к команде — ты нас задерживаешь.

Как устроено тестирование в Agile? Первая, самая важная вещь — за качество отвечает команда…

Жизненный цикл

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

Как все это происходит — есть Product Owner – менеджер, он определяет набор фич, которые нам нужно сделать. Это просто фичи, на уровне одного абзаца текста максимум. Команда помогает Product Owner’у создавать требования. Требование — это фича, детализированная на уровень, например, приемочных тестов.

В команду, которая создает требования, составной частью входят тестировщики. Они помогают менеджеру создавать требования в виде тестов, поэтому оторванность тестировщиков от команды, когда в конце программист говорит «Вот, тестируй то, что я написал». А что ты написал? «А я вот сейчас тебе расскажу...» — вот такого не происходит. Если тестировщики принимают работу, то они должны ее и ставить. Иначе это просто безумие 🙂

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

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

В конце итерации у нас демонстрация. Фактически это «приемка» — каждый демонстрирует, что он сделал, и product owner принимает результат.

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

Как это все выглядит?

Task Board

Одна из практик, которую я очень рекомендую, называется task board. Что это такое — вот у нас есть To Do, In Progress и Done – три свимлайна, и вот фича большая (сверху), декомпозированная на кучу мелких задач.

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

На планировании мы не распределяем задачи по людям. Иначе мы получаем проблему ответственности, когда у меня, у программиста, есть куча своих задач, и какой мне смысл помогать своим товарищам?! Меня попросят помочь, а я скажу «Вообще-то, я занят». Или «Пошел ты в задницу!» в самом пиковом случае. А если будете достаточно вежливы, то просто скажете «У меня сейчас нет времени, но в конце итерации, когда я освобожусь, я тебе помогу…» — то есть, этого не произойдет. Поэтому задачи на людей не планируются.

На daily scrum вы можете распределить задачи по людям.

Таким образом, задача переносится сюда, в In Progress, человек под ней подписывается, и, как только она сделана, она перевешивается направо, в Done. Таким образом, задачи слева все время перевешиваются направо. Когда они все перелезли, значит, мы сделали нашу работу. Это обеспечивает прозрачность — и это очень удобный механизм.

Методы обеспечения качества

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

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

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

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

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

Голос из зала: Есть еще один способ! Вот такой — еще пива.

Еще пива — способ, да, я его тоже пробовал, но это полумера.

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

Итак, как мы сделаем так, чтобы проблем не было вообще?

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

Некоторая «полумера» — ревью кода. Оно должно происходить до коммита, тогда имеет смысл его делать.

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

Если уж сделали ошибку, ее лучше исправить как можно раньше. Как это можно сделать? Ну вот:

• Непрерывная интеграция
• Юнит-тесты
• Разработка через тестирование (TDD)
• Автоматизированное приемочное тестирование

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

А что тогда такое «Ручное тестирование»? Если вы делаете все то, что написано на двух предыдущих слайдах, (это, кстати, бывает не всегда), то что остается на долю ручного тестирования?

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

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

Вот и все тестирование 🙂

Я тут с Лешей Кривицким разговаривал, говорю «Я поеду на конференцию, буду про тестирование в эджайле говорить», а он говорит «Я не понимаю, о чем вы там рассказываете. Просто автоматизируйте все тесты, и всё».

Леша рулит в agile, но он программист. У программистов всегда всё так — взять всё и поделить автоматизировать!

Проблемы

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

Недостаток дисциплины — да, мы решили, да, мы будем делать код-ревью, договорились. И не делаем. Тоже бывает достаточно часто — как мы это будем делать, как мы это будем контролировать?

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

Definition Of Done

Такой инструмент есть — его упоминал Саша Орлов в своем докладе — в оригинале этот инструмент называется Definition Of Done.

Мы должны определить, что значит «ГОТОВО». Определить критерии готовности той или иной вещи, которая нас интересует. Ну, самые распространенные кандидаты на определение Defintion of done это требования. Задачи. Фичи. Что значит «фича сделана до конца» — мы должны это определить. И итерация — что значит «Итерация сделана»?

Требование. Каждая история…

• снабжена приемочными тестами
• снабжена сценарием демонстрации
• имеет приоритет

Для задачи

• Для каждой задачи проведено code review (если не разрабатывалась в паре)
• Написаны автоматизированные тесты на основные методы
• Все тесты успешно проходят

Для фичи

• Созданы автоматизированные приемочные тесты
• Неавтоматизированные тесты добавлены в Check list
• Все пофиксенные дефекты валидированы
• Фича получила статус Validated

Для итерации

• Система прошла регресионное тестирование
• Вся созданная документация прошла ревью

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

Значит, требования.

Перед тем, как фича падает вам в разработку, она должна быть снабжена приемочными тестами. Вы так считаете, и вы договорились об этом. В конце тестирования вы просто будет ставить галочки — это сделано, то сделано — все это значит, что фича готова. Она должна быть снабжена сценарием демонстрации. Мы должны в фиче указать, как мы потом будем демонстрировать ее результат. И она должна иметь приоритет.

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

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

Написаны автоматизированные тесты на основные методы. Все тесты успешно проходят.

Вы можете определить, что значит «написан автоматизированный тест». Определить какое покрытие вы требуете — например 100% для бизнес-логики…

Для фичи – созданы автоматизированные приемочные тесты. Это значит, что создан приемочный тест, который проверяет, что фича готова.

Те тесты, которые не автоматизированны — добавлены в Check list.

Все пофиксенные дефекты валидированы — фича получила стату Validated.

Какие-то еще вещи, например, в фиче не должно быть критических дефектов.

Или вы можете определить долю дефектов: ни одного критического, не больше двух Major, не больше трех Minor. Или вообще ноль.

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

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

Как мы вырабатываем Definition of Done

Очень просто, как всегда в эджайле — мы собираемся командой, куда входят тестировщики, разработчики, аналитики, менеджеры — все, кто вовлечены в разработку, у кого руки по локоть в работе. И мы выписываем на бумагу и договариваемся о том, что такое «готово». Все в команде должны быть согласны с тем, что это то, что нам нужно. Все. Если хотя бы один не согласен, то договариваемся дальше. Вы понимаете, зачем это нужно? Консенсус означает, что — вы же будете потом всем этим пользоваться?!

Если кто-то будет против, то он не будет этого делать? А какая же это командная работа? Мы должны договориться. Мы обсуждаем, что конкретно его не устраивает.

Definition Of Done должен отражать реальное положение дел. Это то, что вы собираетесь делать со следующей итерации. Это не то, что вы хотите делать, когда вырастите, когда у вас не будет legacy-кода, или когда вы найдете замечательных автоматических тестировщиков, которые вам все заавтоматизируют… Если вы этого делать не будете — выкиньте, потом добавите, если будет надо.

Результат стоит распечатать и повесить в рамочку, чтобы все было прозрачно.

Как мы пользуемся Definition Of Done

Корректируем на ретроспективах. Напомню, что ретроспектива — это способ скорректировать процесс. Собрались и обсудили. Какая была проблема — например, для какого-то куска кода не было написано автоматизированного теста. «Давайте обсудим, что мы с этим делаем». «А давайте, например, выкинем это нафиг из определения Definition of Done. Или давайте изменим Definition of Done, чтобы для этого типа нам не нужны автоматизированные тесты. Как-то скорректируем его, ведь это наш договор, договор внутри команды».

Используется при аппеляциях к совести разработчика. «Ты же коммитился на то, что будешь делать код-ревью, давал обязательства вместе со всеми, голосовал, мы помним, как ты голосовал — почему ты его не делаешь?» Это снимает проблему с дисциплиной. А как это снимает проблему с мотивацией — не совсем снимает, но это повод поговорить о том, какие у нас есть критерии качества. Выработать, обсудить, почему они для нас важны. В среднем, по моему опыту, команды стремятся сделать более качественный код. И, как правило, именно «бизнес» мешает писать качественный код.

Это давление снимается тем, что мы сами определяем наш time-box, что мы успеваем сделать в итерации. Вот теперь мы отвечаем за качество.

Ну вот, ребята собрались возле доски задач, и один говорит:

—  Слушайте, мы не делаем код-ревью, давайте выкинем его из definition of done.

— Да не, мы делаем, просто не всегда, — говорит второй.

— А как нам сделать так, чтобы было всегда?

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

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

И один говорит:

— И штрафовать, если ревью не проведено. Десять рублей в пивной фонд!

Всем идея понравилась, приняли.

Вот еще один способ напомнить команде о договоренностях, которые команда достигла. Я сфотографировал одну из команд, наверху там написано «Поработаем в паре», а внизу «Ты делаешь код-ревью?» — способ напомнить команде о том, насколько это важно для нее.

Технологический долг

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

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

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

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

Договариваемся с Product Owner и планируем его внутри итерации. Конечно, не то, чтобы мы теперь пять итераций занимаемся улучшением бэклога. Конечно, задачи для бизнеса тоже нужно делать. Но мы постоянно стараемся что-то добавить в итерацию, чтобы он постоянно уменьшался. Это относится к работе с legacy-кодом — все сразу поднять нельзя, работаем постепенно.

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

Рассуждать хочу долго и о ситах.

Си́то — устройство для разделения сыпучих масс по величине их составляющих (зёрен, круп, песка и т.п.).

Сперва послушаем историков:

Человеческие жертвоприношения из ряда тестировщиков до и после релиза были распространённым явлением у менеджеров проектов, живших на полуострове Юкатан до нашествия конкистадоров. Тестировщиков приносили в жертву через повешение, утопление, отравление, избивание, а также посредством захоронения заживо в груде документации по проекту.

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

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

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

Итак, утопление.

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

Как все это добро достать?

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

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

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

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

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

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

Сделаем музыкальную паузу.

Прочти, раскрась, запомни:

Тестирование в Agile-way особенно сильно тем, что всё, что можно автоматизировать, автоматизируется до и во время разработки, а не отдельно от неё.

Продолжим сосать мартини и рассуждать.

Каждое «сито» в девелопменте имеет свое имя.

1. Test Driven Development — сито мелкоячеистое.
2. Acceptance Test Driven Development — сито среднеячеистое.
3. Functional Testing — сито крупноячеистое.

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

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

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

Например, понятие сита — уже абстракция.

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

Unit testing

Внятный пример — LoveUT.

Цитата из статьи:

Тихо мурлыкая под нос, Анна продолжает кодировать свой класс.

Суть «разработки через тестирование» проста:

• Сначала программист пишет тест для проверки функциональности, которую собирается написать. Этот тест называется «unit-test», потому, что он проверяет только одну единицу функционала.
• Затем программист пишет функциональность.
• И постоянно проверяет ее посредством ранее написанного, специально для нее, теста.
• Как только функционал удовлетворяет требованиям этого теста, разработка функции считается завершенной. Переходим к следующей.
• Во время разработки других функций, которые связаны с уже существующей, программисту можно и следует запускать юнит-тесты чаще, чем его легкие всасывают в себя один литр воздуха. Если все «горит зеленым» — программист счастлив. Если красное — увы.

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

Особенности юнит-тестов:

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

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

Acceptance testing

Внятное описание на английском языке: wikipedia.org.

Акксептанс-тесты — второй шаг после юнит-тестов. Это уже существенный уровень абстрактности от кода.

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

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

Особенности акксептанс-тестов:

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

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

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

Для сочувствующих agile development уточняем: акксептанс-тесты проверяют юзер-сториз. А юзер-сториз — вне кода, вне технологий. Получается, что у нас есть high level tests, которые запускаются нажатиями кнопок.

Пример, пример!

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

В примере проверялась такая юзер-стори:

«User want to perform money operation from my account to another one to pay/receive money to/from another User»

посредством следующего приемочного критерия:

«After money operation one of the accounts is increased and another is decreased by the same amount of money».

Критерии акксептанс-тестов задают (а в идеальном мире — пишут) заказчики софта, а не разработчики. Например, пресловутый заказчик просит* следующего:

• в базе должны существовать аккаунты разных юзеров.
• у каждого юзера на счету есть какие-то деньги.
• после нажатия кнопки «Сделать офигенно», со счета юзера №1 на счет юзера №2 должны передаваться какие-то суммы.

* имхо, неимоверно удачно выбранный глагол.

Как выглядит такой тест, написанный в wiki-разметке в фреймворке «FitNesse»

Тесты в FitNesse читаемы и понятны

Как эта таблица выглядит в формате wiki:

Make sure that there are no accounts in the bank.

!|ensure|clean accounts|

Create two different accounts.

!|create account for user|Bob|with amount|5|

!|create account for user|John|with amount|7|

и тд

Как это выглядит после прогона теста:

FitNesse рапортует о выполнении задач партии

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

Предварительное резюме

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

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

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

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

Functional testing

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

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

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

Тут мы узнаем, что бывает, если муравьев в системе слишком много или слишком мало.

Это можно делать как всеми органами осязания, воззрения и осмысления, так и заранее документируя свои действия (тест-кейсы).

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

Окончательное прозрение

Если

1. проект только начинается
2. разработка ведется в стиле on-going (неизвестны ни конечный результат, ни дата полного финала)
3. код пишется «с нуля»
4. заказчик умеет работать в agile-стиле
5. разработчики умеют работать в agile-стиле
6. инженеры «болеют» тестированием
7. все три сита постоянно применяются в процессе разработки

тогда

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

Например:

1. Люди важнее процесса

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

Этот прикол может «не работать» из-за разногласий в методах достижения конечного результата, или из-за проблем с коммуникациями («Чем занимаешься? Почему не приходишь на работу вовремя? Почему не утвердил эти изменения у такого-то начальника?»).

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

Верно следующее утверждение: если работник просит изменить процесс, то при рассмотрении этого дела приоритет будет у работника, а не у заведующего процессом.

2. Реакция на изменения важнее следования плану

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

Просто надо знать, что планы корректируются по ходу дела. Ежеминутно.

Двое людей выезжают из пункта А в пункт Б. У первого есть план. У второго — нет. Второй — романтик… У кого больше шансов «доехать»?

Учитывая прогноз «к дождю», вероятнее всего — не доедут оба. Но у первого, как ни крути, больше шансов доехать, чем у того, кто просто жмет на педали, глядя на ромашки.

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

Вот если он заблудится, но будет тупо следовать плану…

3. Работающий код важнее документации

Да.

Но это не значит, что документацию не надо писать 🙂

Если встает проблема «или делать код, или делать к нему документацию», то первый вариант приоритетнее — вот и всё.

Сперва подумай о том, что ты сам в какой-то момент начнешь путаться в «работающем коде».

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

Еще запланируй внезапную смерть главного «носителя» информации по проекту…

Документацию, все-таки, надо делать. «Agile» не означает, что можно проектировать и кодировать без сборника информации о том, что и как, по-меньшей мере, предполагалось делать.

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

4. Сотрудничество важнее формальных отношений

Еще бы…

I. Бабушка «фурычит» в пирожках

Технология создания пирожков слегка запутанная.

Одни пирожки пекутся в духовой печи.

Другие жарятся во фритюре.

Третьи сперва обмакиваются в кляр.

Тесто для пирожков делают различное:

1. слоеное,
2. рассыпчатое,
3. рубленое,
4. блинчатое,
5. заварное,
6. на дрожжах — постное и скоромное.

Конечные пирожки тоже бывают разными:

1. слоеные в виде рога изобилия с фаршем из мозгов
2. с грибным фаршем
3. с фаршем из печенки, с ромом и мадерою
4. с фаршем из щуки или окуня
5. с сыром
6. с телячьим ливером
7. с вишней

Поклонникам Елены Молоховец — полный расклад пирожковой индустрии.

Теперь идем к такой-то бабушке и просим пирожков.

Нормальная бабушка спросит только: «Какие именно, внучара? Творог, капуста, вишня?«

Ненормальная бабушка спросит: «Какие именно тебе нужны пирожки? Одни пирожки пекутся в духовой печи, другие жарятся во фритюре, третьи — обмакиваются сперва в кляр. Я могу сделать слоеные в виде рога изобилия с фаршем из мозгов, или с грибным фаршем, или с фаршем из печенки, с ромом и мадерою, или с фаршем из щуки или окуня, или с сыром, или с телячьим ливером, или с вишней…«

Нам нас жаль…

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

II. Сколько раз в неделю нужно проводить daily-митинги?

На любой тусовке agile-девелоперов кто-то из пришедших обязательно спрашивает о следующем:

• сколько раз в неделю нужно проводить daily-митинги?
• как и когда agile-тестировщикам нужно сочинять тест-кейсы?
• как девелопить без документации по проекту?
• как убить убедить заказчика в том, что он сам не знает, чего захочет через несколько итераций?
• как «уйти» от фиксыд-прайс-прожэкта? (имеется ввиду «fixed-price project», якобы антипод agile-ориентированного процесса)
• как продавать agile-процесс?

Все эти вопросы вы уже где-то видели — это же темы семинаров по agile. Пример последнего семинара…

Вот о последнем и хочется сказать: НИКАК.

Еще раз: как продать процесс создания пирожка человеку, которому нужен собственно пирожок?

Продаются пирожки, а не процесс их создания.

Исключение — продажа патента на пирожковое производство.

III. У нас офигенный процесс производства сайтов

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

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

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

• …(тупое молчание)…

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

У нас есть сотня вариантов того, что мы можем сделать. У нас есть десяток вариантов того, как именно мы это будем делать (толкую о рабочих процессах). Для решения задачи нужно выбрать «наилучшие» вариант и процесс. Можно сделать по этапам. Можно сделать быстро. Можно изрядно задокументироваться… Можно всё! Критерий успешности — решение задачи.

Как решить задачу? Удобнее средствами Waterfall? Нате вам. Удобнее использовать V-Model? Welcome! Кому тут кажется, что все проекты лучше всего делать через agile? А через задницу проекты делать не приходилось?

Они же все разные, проекты эти 🙂 Можно ли в agile-way делать софт для управления системами боевого истребителя Su-35? Если ответ «Да», то мне очень приятно познакомиться с вами, вождь Бромден. Старшая медсестра Милдред Рэтчед уже ждет вас.

Разумно ли делать «GMail» ватерфольным методом? О, мистер Буш, проходите, бушмены у нас сидят справа.

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

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

Если хочется напугать кого-то словом agile, то пожалуйте пример:

— Вы строите дома? Мне нужен дом!

— Построим. Мы уверены, что вы не знаете, какой дом вы хотите.

— Что значит — не знаю?

— Не знаете, не знаете. Ни один заказчик не знает точно, чего он хочет. Поверьте моему опыту.

— И что вы предлагаете?

— Я предлагаю вам гибкий подход к строительству дома. Мы не будем знать общую стоимость проекта. Сперва мы возведем первый этаж. Затем напишем общий план постройки. Юз-кейс простой — человек хочет жить в доме. Запишем это в бэклог, и… вам плохо?

— Нет. А подвал построите?

— Ну, это же подразумевается. Потом оценим результаты первого спринта, и если вам понравится первый этаж (вы в нем поживете), то мы начнем делать второй этаж.

— И на втором надо будет пожить?

— Да.

— А если мне не понравится?

— Снесем и начнем строить заново…

IV. Agile оценивается в задочасах, а не в пирожках

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

(откашлявшись) Для ориентира: один задочас — это одна восьмая обычного восьмичасового рабочего дня.

Это разумнее, чем ляпнуть «Функция поиска на сайте стоит $100», и не суметь объяснить, почему именно $100, а не $99.

Зная стоимость одного задочаса (примерная оценка), и время разработки той или иной функции (примерная оценка), можно точно сказать, сколько времени будет длиться весь проект, и сколько он будет стоить (тоже примерная, но обсуждаемая оценка). Если в будущем проект выйдет за эти рамки или даже займет меньше ресурсов — какие проблемы? Все течет, все изменяется…

В Agile-разработке тоже существуют сроки, как и в Waterfall (wow, what a surprise!). Эти сроки оговариваются и должны соблюдаться. И в Waterfall тоже есть короткие итерации, постоянная смена ориентиров и сроков. Нетрудно даже провести параллели.

Подробнее о том, как оценивать будуший проект, см. в книге «Scrum and XP from the trenches«. Подсказка: оценивать надо в стори-пойнтах.

Еще надо знать: неграмотное внедрение Agile-процессов требует человеческих жертв. Первой жертвой будет тот, кто громче всех звал народ на agile-бастионы, соблазняя преимуществами TDD перед АКМ.

Резюме: хватить болтать ерундой! Agile не продается. Продаются пирожки.

Проще Родину продать, чем agile…

Третьи стороны медали

1. Денис Петелин, рулевой agilebelarus.org рассказывает о том, «Как продать Agile?»
   • Вкратце: декларации об agile надо подтверждать клиенту наличием опытной команды.
2. Michele Sliger, consultant and co-author of The Software Project Manager’s Bridge to Agility, talks about the role of project managers in an agile environment.
   • Вкратце: Don’t think that transitioning to agile is simply a matter of tool substitution. Don’t think you can put down the Gantt chart and pick up a burndown chart, and poof, you’ll be agile.