Комментарии: Каким должно быть приёмочное тестирование в agile-проектах? https://testitquickly.com/2009/09/02/dati-ne-testare-interesanta-in-agile/ про тестирование ПО и всё такое прочее Thu, 28 Feb 2013 06:10:23 +0000 hourly 1 https://wordpress.org/?v=6.9.4 Автор: Vasya https://testitquickly.com/2009/09/02/dati-ne-testare-interesanta-in-agile/#comment-5014 Thu, 28 Feb 2013 06:10:23 +0000 http://testitquickly.com/?p=1128#comment-5014 Эхехе. Всегда со скепсисом относился к идиотской моде на гламурные стразы вроде scrum, xp и прочего agile. По мне, так главное отличие agile от waterfall это длина итерации. Acceptance testing бывает User Acceptance Testing, а бывает тем, к чему привык под названием «функциональное тестирование». А какой вывод?
Весь этот эджайл, все эти МОДНЫЕ ФИШКИ (для дураков) — чушь и хрень, придуманная теми, кто в тестировании ни бельмеса не смыслит.
Другими словами, это методология по-настоящему сплоченных и профессиональных команд, основанная на здравом смысле, опыте, умении работать быстро и качественно.
Но, не обладая достаточной квалификацией, вы ее применить не сможете. Вы сможете только сделать вид, что работаете круто и модно.

]]> Автор: Ievgen https://testitquickly.com/2009/09/02/dati-ne-testare-interesanta-in-agile/#comment-5013 Sat, 14 Apr 2012 06:24:29 +0000 http://testitquickly.com/?p=1128#comment-5013 Правильно ли я понимаю, что Ваша точка зрения, это:
1. Нет фитнесу, потому что он не позволяет проводить интеграционное тестирование.
2. Нет фитнесу, потому что его язык убог
3. Нет автоматизации вообще, непродуктивно, все будем тестировать руками. А в свободное время будем автоматизировать.
?
Какой еще в Agile есть fun у програмиста такой, какого нет у тестировщика, кроме парного программирования?

]]> Автор: ruslanix https://testitquickly.com/2009/09/02/dati-ne-testare-interesanta-in-agile/#comment-5012 Sun, 02 May 2010 18:13:41 +0000 http://testitquickly.com/?p=1128#comment-5012 Очень интересная статья (доклад)!
Заставляет мозг работать)
Хочу задать (уточнить) несколько вопросов:
1) «в системе разработки ПО люди — это ненадежные звенья, чтобы сделать ее надежной — классические подходы добавляют избыточность, чтобы выход из строя одного из звена не оказывал влияния на всю систему»,
можете привести пример избыточности?
— на сколько я понял примером может быть — ограничение ответств-ти человека, т.е. чтобы он делал только выделенну ему работу, и ничего больше (типа конвеер). НА пример разработчика — это может быть кодер, которому просто дают уже разраобтанный проект, или человек отвечающий только за один модуль в системе
какие еще есть способы добавить избыточность?
— и наоборот, как в agile проявляется высокая КПД члена команды?
например за счет того, что он может быть и архитектором и разработчиков, и через совместное владение кодом имеет представление о всей системе?
2) Вы говорите, что в классике выход из строя одного элемета — не оказывает влияния на всю систему, в Agile — нет (оказывает)
— но ведь как раз в Agile мы и пытаемся путем практик типа «совместного владения кода», не выраженных ролей и т.п. сделать так, чтобы люди были «на все руки» и если один человек заболел, его могут легко заменить другие, т.к. они могут выполнять его работу?
— получается тут идет речь о другом воздействии одного человека на результат работы всей системы?
3) «если хотите, чтобы проект закончился быстрее — уменьшите команду, за счет этого вы повышаете КПД её отдельных элементов, вы позволяете им оказывать большее влияние на общий результат работы системы за счет уменьшения количества связей, которые как раз всё это КПД гасят»
— «большая часть взаимодействий ни к чему хорошему не приводит»
— получается общение (каналы связи) — гасят КПД? Как это происходит, можете привести примеры? Ведь в agile наоборот делается упор на общение между участниками команды (разработчиками, тестировщиками, суппортом и т.п.)??
4) получается, что методологии можно разделить на две группы:
— процессо-ориентируемые — т.к. те, которые ставят ставку на процесс и исскуственно уменьшают ответственности (кпд и т.п.) отдельного человека из команды
— человеко-ориентированные, т.е. те, которые наоборот позволяют человеку максимально влиять на общий результат
??
Спасибо 😉

]]> Автор: Алексей Лупан https://testitquickly.com/2009/09/02/dati-ne-testare-interesanta-in-agile/#comment-5011 Sat, 05 Sep 2009 15:45:30 +0000 http://testitquickly.com/?p=1128#comment-5011 Какое-то время термин «парное программирование» меня смешил из-за устойчивой ассоциации с «парное молоко»…

]]> Автор: Алексей Лупан https://testitquickly.com/2009/09/02/dati-ne-testare-interesanta-in-agile/#comment-5010 Sat, 05 Sep 2009 15:45:11 +0000 http://testitquickly.com/?p=1128#comment-5010 Дополнение про парное тестирование:

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

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

]]> Автор: Алексей Лупан https://testitquickly.com/2009/09/02/dati-ne-testare-interesanta-in-agile/#comment-5009 Fri, 04 Sep 2009 09:58:58 +0000 http://testitquickly.com/?p=1128#comment-5009 В ответ на Maksim H.

Главное — fun.

]]> Автор: Maksim H https://testitquickly.com/2009/09/02/dati-ne-testare-interesanta-in-agile/#comment-5008 Fri, 04 Sep 2009 09:40:07 +0000 http://testitquickly.com/?p=1128#comment-5008 Хорошая статья… Agile, не-Agile — главное fan и каждый день/месяц/год что-то новое!!!

]]> Автор: Yosef https://testitquickly.com/2009/09/02/dati-ne-testare-interesanta-in-agile/#comment-5007 Fri, 04 Sep 2009 02:44:58 +0000 http://testitquickly.com/?p=1128#comment-5007 Fun to listen…

]]> Автор: Алексей Лупан https://testitquickly.com/2009/09/02/dati-ne-testare-interesanta-in-agile/#comment-5006 Wed, 02 Sep 2009 12:50:12 +0000 http://testitquickly.com/?p=1128#comment-5006 В ответ на Дмитрий.

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

]]> Автор: Дмитрий https://testitquickly.com/2009/09/02/dati-ne-testare-interesanta-in-agile/#comment-5005 Wed, 02 Sep 2009 12:17:50 +0000 http://testitquickly.com/?p=1128#comment-5005 Браво, очень понравилась статья.
В принципе у нас так и живем.
Аргументы про аналитические способности тестировщиков в код ревью прям открытие, возьму на вооружение.

]]>