Знакомлюсь вплотную с XP, но после прочтения книг возникли некоторые вопросы/недопонимание. Может кто из реально использующих XP прояснить следующий вопрос. Или даже лучше не из реально использующих ХР, а из тех кто много читал про ХР, т.к. хочеться узнать не то, как это делается в конкретном проекте/команде, а то как это должно делаться, т.е. так сказать ответить на вопрос с высока, а не с точки зрения опыта конкретного проекта/команды.


А Тестировщики вообще есть в процессе XP? Что-то пока читаю и не вижу никаких упоминаний.
Ну ведь новую функциональность всё равно лучше проверить тестеру. Тем более, что из программистов плохие тестеры. Тем более надо тестить gui.
Или опять чего-то недоговаривают?


Заранее спасибо за ответы

R>А Тестировщики вообще есть в процессе XP? Что-то пока читаю и не вижу никаких упоминаний.
R>Ну ведь новую функциональность всё равно лучше проверить тестеру. Тем более, что из программистов плохие тестеры. Тем более надо тестить gui.
R>Или опять чего-то недоговаривают?


Аллё
Ну так что? А то читаю Кена Ауэра и Роя Миллера, так они пишут примерно так "у нас есть команда из 12 разработчиков, мы программируем в парах" и т.д. И далее по ходу никаких намёков на то, что у них есть хоть один тестировщик.

Здравствуйте, remark, Вы писали:

R>А Тестировщики вообще есть в процессе XP? Что-то пока читаю и не вижу никаких упоминаний.
R>Ну ведь новую функциональность всё равно лучше проверить тестеру. Тем более, что из программистов плохие тестеры. Тем более надо тестить gui.
R>Или опять чего-то недоговаривают?
В XP тестировщиков нет, а вообще — есть . Методология XP просто не описывает внешнего тестирования программ. С точки зрения XP, тестировщик — это тоже такой заказчик.

Здравствуйте, Eugene Beschastnov, Вы писали:

EB>Здравствуйте, remark, Вы писали:

R>>А Тестировщики вообще есть в процессе XP? Что-то пока читаю и не вижу никаких упоминаний.
R>>Ну ведь новую функциональность всё равно лучше проверить тестеру. Тем более, что из программистов плохие тестеры. Тем более надо тестить gui.
R>>Или опять чего-то недоговаривают?

EB>В XP тестировщиков нет, а вообще — есть . Методология XP просто не описывает внешнего тестирования программ. С точки зрения XP, тестировщик — это тоже такой заказчик.


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

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

Здравствуйте, remark,


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

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

В xp упор делается все-таки совсем на другое.

Здравствуйте, mrozov, Вы писали:

M>Насколько я понимаю ситуацию, этот вопрос просто находится за пределами ядра xp.
M>Т.е. XP не то, чтобы отрицает концепцию тестировщиков, а просто не рассматривает ее.
Именно.

Здравствуйте, remark, Вы писали:

R>Знакомлюсь вплотную с XP...

Если знакомитесь с XP, то рекомендую следующую книгу (есть в осле):

Extreme Programming Refactored: The Case Against XP (Paperback)
by Matt Stephens, Doug Rosenberg

Там есть ответы на многие вопросы.

Best Regards,
Yevgeny.

Здравствуйте, remark, Вы писали:

R>А Тестировщики вообще есть в процессе XP? Что-то пока читаю и не вижу никаких упоминаний.
R>Ну ведь новую функциональность всё равно лучше проверить тестеру. Тем более, что из программистов плохие тестеры. Тем более надо тестить gui.
R>Или опять чего-то недоговаривают?

Тестировщики в XP производят тестирование на основе историй пользователя. Основная цель тестировщика убедиться в том что корректно реализованы все требования заказчика. В данном случае тестировщики являются людьми осуществляющими коммуникацию между разработчиками и заказчиками.

Более подробно об этом можно прочитать в этой книге: Testing Extreme Programming by Lisa Crispin, Tip House.

Здравствуйте, Аноним, Вы писали:

А>Тестировщики в XP производят тестирование на основе историй пользователя. Основная цель тестировщика убедиться в том что корректно реализованы все требования заказчика. В данном случае тестировщики являются людьми осуществляющими коммуникацию между разработчиками и заказчиками.

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

Здравствуйте, Yevgeny, Вы писали:

Y>Здравствуйте, remark, Вы писали:

R>>Знакомлюсь вплотную с XP...

Y>Если знакомитесь с XP, то рекомендую следующую книгу (есть в осле):

Y>Extreme Programming Refactored: The Case Against XP (Paperback)
Y>by Matt Stephens, Doug Rosenberg

Y>Там есть ответы на многие вопросы.

Y>Best Regards,
Y>Yevgeny.


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

Здравствуйте, remark, Вы писали:

R>Такое ощущение, что люди, пишушие про XP, — фанатики. Что они просто маниакально привязаны к XP. Мне уже самому в голову пришла мысль, что надо бы от них не заразиться и более трезво смотреть на XP.


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

Эта детская болезнь пройдет и всё вернется на круги своя:

1. No silver bullet! (c) Brooks
2. Цените хороших инженеров, которые у Вас есть, и мотивируйте их.
3. Безжалостно увольняйте бездарных и ленивых.
4. Think first! (aka Thought-Driven Development).
5. Обсуждайте и тщательно документируйте требования, дизайн и код при итеративной разработке.
6. Хорошо продуманные требования и дизайн устраняют подавляющее большинство ошибок до их появления.
7. Пишите автоматизированные тесты только когда это имеет реальную пользу.
Написать хороший автоматизированный тест — очень трудоемкая задача.

Best Regards,
-- Yevgeny.

Здравствуйте, Yevgeny, Вы писали:

Y>Здравствуйте, remark, Вы писали:

R>>Такое ощущение, что люди, пишушие про XP, — фанатики. Что они просто маниакально привязаны к XP. Мне уже самому в голову пришла мысль, что надо бы от них не заразиться и более трезво смотреть на XP.


Y>Люди, пишушие про XP, — кажутся фанатиками. На самом деле — это расчетливые бизнесмены, делающие очень много денег на своих
Y>книжках, статьях, но в основном — на лекциях, которые они читают в больших компаниях. Менеджеры ищут "серебряную пулю" и готовы платить
Y>за эти "лекции". Так пару месяцев назад у нас гастролировал Боб Мартин — тот самый. Два часа промывания мозгов в стиле религиозного проповедника. Притянутые за уши факты не относящиеся к делу, голословные утверждения, откровенное враньё. Я задал ему пять-шесть вопросов на которые он не смог дать никакого вразумительного ответа. При этом делал вид, что всё окей, и что учение XP всесильно, потому что оно верно.

Y>Эта детская болезнь пройдет и всё вернется на круги своя:

Y>1. No silver bullet! (c) Brooks
Y>2. Цените хороших инженеров, которые у Вас есть, и мотивируйте их.
Y>3. Безжалостно увольняйте бездарных и ленивых.
Y>4. Think first! (aka Thought-Driven Development).
Y>5. Обсуждайте и тщательно документируйте требования, дизайн и код при итеративной разработке.
Y>6. Хорошо продуманные требования и дизайн устраняют подавляющее большинство ошибок до их появления.
Y>7. Пишите автоматизированные тесты только когда это имеет реальную пользу.
Y> Написать хороший автоматизированный тест — очень трудоемкая задача.

Y>Best Regards,
Y>-- Yevgeny.


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

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

Здравствуйте, bkat, Вы писали:

B>А не упарится ли этот человек?
B>На коммуникацию с заказчиком уходит столько времени,
B>что о тестировании говорить не приходится.
B>Ну там пару "тест кейзов" прогнать — это конечно не проблема.
B>Но чтобы систематически искать баги — на это требуется отдельный человек,
B>или даже целая команда, если проект чуть посложнее...

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

R>А Тестировщики вообще есть в процессе XP?

А кто сказал, что XP — это хорошо?

Модно — да. Но хорошо???

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

Ага. Типа НЛП-тренеров, которые учат юнцов снимать девок на улице.

>Менеджеры ищут "серебряную пулю" и готовы платить
Y>за эти "лекции".

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

>Так пару месяцев назад у нас гастролировал Боб Мартин — тот самый. Два часа промывания
>мозгов в стиле религиозного проповедника.

А какие у него за плечами реальные продукты? Я лучше послушаю любого менеджера из Микрософта.

Y>4. Think first! (aka Thought-Driven Development).

Вот это очень хорошо.

Y>7. Пишите автоматизированные тесты только когда это имеет реальную пользу.

И это хорошо.

Y> Написать хороший автоматизированный тест — очень трудоемкая задача.

Зависит от предметной области, но часто да, сравнима с самим кодом.