главный редактор портала 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-овых штучек. Чем их больше, тем выше будет КПД, меньше люди будут рваться уйти в другую компанию, в другой проект, и всё это относится, в том числе, и к тестировщикам.

Спасибо.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Тестирование в 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. каждый гребёт свою кучу денег и убегает домой пить пиво и смотреть футбол с любимой женой.

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

Пытается программист уточнить, зачем эта труба клиенту нужна. Умудренный знает, что клиенту этой информацией делиться нафиг не нужно. Что ему труба нужна. Или пирожок 🙂 Но пытается.

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

«How to test software with dynamic requirements?» — достаточно вменяемая статья на тему нестандартных труб, исходя из всей доступной «широты» этого вопроса.

Решение в этому случае достаточно взвешенное, хотя и местами рисковое — чек-лист.

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

Или MindMap.

Вот пример карты в MindMap (required Flash). В примере я показал часть того, что должно было быть сделано программистом в отношении гипотетической задачи «ER-678».

Это все было расписано не в требованиях, а размазано в комментариях к задаче. Занести все это в MindMap и как следует раскидать по логикам вещей — 7 минут. Проще, чем просить письмо с однозначными требованиями и громко предпочитать работать в гетеросексуальном коллективе.

Сколько времени занимает само тестирование — уже не так важно, it’s depends… Важно то, что если какое-то требование будет изменено через час, его изменение займет в этой карте минимальное время, и все равно будет понятно, что и как надо делать. А если будет добавлено что-то новое, то и в карту его добавить несложно.

Интереснее всего то, что будет видно потом. Видно, что в пункте «all the other checkboxes should be unchecked and greyed out» возникли какие-то проблемы… И в комментарии указано, что по этому поводу открыт новый баг в баг-трекере.

MindMap позволяет очень и очень грамотно и гибко сортировать топики по разным признакам — пользуемся Queries.