Каким должно быть приёмочное тестирование в agile-проектах?

Автор: | 02.09.2009

Автор: Алексей Баранцев,

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

barancev2

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

barancev3

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

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

barancev4

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

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

barancev5

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

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

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

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

barancev6

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

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

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

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

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

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

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

barancev7

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Стараемся…

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

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

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

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

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

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

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

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

Что делать?

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

barancev8

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

barancev9

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

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

Часть 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 взялся вот откуда.

barancev10

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

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

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

Фиг!

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

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

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

Увы.

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

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

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

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

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

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

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

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

barancev11

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

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

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

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

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

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

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

barancev12

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

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

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

barancev13

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

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

barancev14

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

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

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

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

barancev15

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

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

Для ясности

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

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

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

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

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

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

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

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

Спасибо.

Каким должно быть приёмочное тестирование в agile-проектах?: 10 комментариев

  1. Дмитрий

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

  2. Алексей Лупан

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

  3. Maksim H

    Хорошая статья… Agile, не-Agile — главное fan и каждый день/месяц/год что-то новое!!!

  4. Алексей Лупан

    Дополнение про парное тестирование:

    Тогда я ещё не знал, как можно эффективно организовать парное тестирование, потому что в основном думал про автоматизацию, отталкиваясь от парного программирования. И у меня не было идей, как использовать работу в парах при ручном тестировании. И я не видел публикаций про действительно успешный чужой опыт.
    Но прошёл год, появился новый опыт. Мы в нашей команде опробовали парную работу в режиме сеансового тестирования (session based testing) — и это оказалось хорошо. Я даже удивляюсь, почему основоположники про это не пишут (ну или я не видел). Хотя сами таки тестируют в парах, как можно судить по их заметкам в блогах и по мастер-классам.

    Алексей Баранцев. (Источник).

  5. Алексей Лупан

    Какое-то время термин «парное программирование» меня смешил из-за устойчивой ассоциации с «парное молоко»…

  6. ruslanix

    Очень интересная статья (доклад)!
    Заставляет мозг работать)
    Хочу задать (уточнить) несколько вопросов:
    1) «в системе разработки ПО люди — это ненадежные звенья, чтобы сделать ее надежной — классические подходы добавляют избыточность, чтобы выход из строя одного из звена не оказывал влияния на всю систему»,
    можете привести пример избыточности?
    — на сколько я понял примером может быть — ограничение ответств-ти человека, т.е. чтобы он делал только выделенну ему работу, и ничего больше (типа конвеер). НА пример разработчика — это может быть кодер, которому просто дают уже разраобтанный проект, или человек отвечающий только за один модуль в системе
    какие еще есть способы добавить избыточность?
    — и наоборот, как в agile проявляется высокая КПД члена команды?
    например за счет того, что он может быть и архитектором и разработчиков, и через совместное владение кодом имеет представление о всей системе?
    2) Вы говорите, что в классике выход из строя одного элемета — не оказывает влияния на всю систему, в Agile — нет (оказывает)
    — но ведь как раз в Agile мы и пытаемся путем практик типа «совместного владения кода», не выраженных ролей и т.п. сделать так, чтобы люди были «на все руки» и если один человек заболел, его могут легко заменить другие, т.к. они могут выполнять его работу?
    — получается тут идет речь о другом воздействии одного человека на результат работы всей системы?
    3) «если хотите, чтобы проект закончился быстрее — уменьшите команду, за счет этого вы повышаете КПД её отдельных элементов, вы позволяете им оказывать большее влияние на общий результат работы системы за счет уменьшения количества связей, которые как раз всё это КПД гасят»
    — «большая часть взаимодействий ни к чему хорошему не приводит»
    — получается общение (каналы связи) — гасят КПД? Как это происходит, можете привести примеры? Ведь в agile наоборот делается упор на общение между участниками команды (разработчиками, тестировщиками, суппортом и т.п.)??
    4) получается, что методологии можно разделить на две группы:
    — процессо-ориентируемые — т.к. те, которые ставят ставку на процесс и исскуственно уменьшают ответственности (кпд и т.п.) отдельного человека из команды
    — человеко-ориентированные, т.е. те, которые наоборот позволяют человеку максимально влиять на общий результат
    ??
    Спасибо 😉

  7. Ievgen

    Правильно ли я понимаю, что Ваша точка зрения, это:
    1. Нет фитнесу, потому что он не позволяет проводить интеграционное тестирование.
    2. Нет фитнесу, потому что его язык убог
    3. Нет автоматизации вообще, непродуктивно, все будем тестировать руками. А в свободное время будем автоматизировать.
    ?
    Какой еще в Agile есть fun у програмиста такой, какого нет у тестировщика, кроме парного программирования?

  8. Vasya

    Эхехе. Всегда со скепсисом относился к идиотской моде на гламурные стразы вроде scrum, xp и прочего agile. По мне, так главное отличие agile от waterfall это длина итерации. Acceptance testing бывает User Acceptance Testing, а бывает тем, к чему привык под названием «функциональное тестирование». А какой вывод?
    Весь этот эджайл, все эти МОДНЫЕ ФИШКИ (для дураков) — чушь и хрень, придуманная теми, кто в тестировании ни бельмеса не смыслит.
    Другими словами, это методология по-настоящему сплоченных и профессиональных команд, основанная на здравом смысле, опыте, умении работать быстро и качественно.
    Но, не обладая достаточной квалификацией, вы ее применить не сможете. Вы сможете только сделать вид, что работаете круто и модно.

Добавить комментарий