Сообщений в теме: 27

[ch_ip]

Уважаемый SALar, по части красных бус не соглашусь с вами, думаю здесь уместна следующая аналогия - главный контроллер регулярно получает от двух других значения по 1-2 бусины, что является нормой. Вот только на деле контроллеры регулярно недосчитывают несколько бусин - реально их по 5-6. Неужели нельзя научить контроллеров лучше считать бусины? Тогда мы по крайней мере будем знать их реальное количество и не отправлять плохие лопатки заказчику. Лучше вообще ничего не отправить, чем отправить откровенный брак, разве не так?

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

[pachkun]

Уважаемый SALar, по части красных бус не соглашусь с вами, думаю здесь уместна следующая аналогия - главный контроллер регулярно получает от двух других значения по 1-2 бусины, что является нормой. Вот только на деле контроллеры регулярно недосчитывают несколько бусин - реально их по 5-6. Неужели нельзя научить контроллеров лучше считать бусины? Тогда мы по крайней мере будем знать их реальное количество и не отправлять плохие лопатки заказчику. Лучше вообще ничего не отправить, чем отправить откровенный брак, разве не так?

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

[SALar]

Уважаемый SALar, по части красных бус не соглашусь с вами, думаю здесь уместна следующая аналогия - главный контроллер регулярно получает от двух других значения по 1-2 бусины, что является нормой. Вот только на деле контроллеры регулярно недосчитывают несколько бусин - реально их по 5-6. Неужели нельзя научить контроллеров лучше считать бусины? Тогда мы по крайней мере будем знать их реальное количество и не отправлять плохие лопатки заказчику. Лучше вообще ничего не отправить, чем отправить откровенный брак, разве не так?

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

Именно.
То, что программист допустил ошибку, а тестировщик ее не нашел обусловлено системой, а не личными качествами инженеров.

[kukolev]

Уважаемый SALar, по части красных бус не соглашусь с вами, думаю здесь уместна следующая аналогия - главный контроллер регулярно получает от двух других значения по 1-2 бусины, что является нормой. Вот только на деле контроллеры регулярно недосчитывают несколько бусин - реально их по 5-6. Неужели нельзя научить контроллеров лучше считать бусины? Тогда мы по крайней мере будем знать их реальное количество и не отправлять плохие лопатки заказчику. Лучше вообще ничего не отправить, чем отправить откровенный брак, разве не так?

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

Именно.
То, что программист допустил ошибку, а тестировщик ее не нашел обусловлено системой, а не личными качествами инженеров.

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

Коллеги, это противоречие, и эксперимент с бусинами вызывает сомнение. Более адекватный эксперимент - если рабочему разрешено сделать 10 вариантов лопаток и выбрать лучшую. Вот в этом случае можно будет говорить о стараниях рабочего (тестировщика), заработает идея с премированием / депремированием. Хороший работнгик будет стараться и будет приносить минимум красных бусинок. Хороший работник может вообще остаться после работы и делать лопатки до тех пор, пока там не будет НОЛЬ бусинок. Вопрос - у меня хороший тестировщик? должен ли он был выполнить данные проверки? Принят ли такой подход у тестировщиков, или я прошу невозможного?

[nhuber]

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

Коллеги, это противоречие, и эксперимент с бусинами вызывает сомнение. Более адекватный эксперимент - если рабочему разрешено сделать 10 вариантов лопаток и выбрать лучшую. Вот в этом случае можно будет говорить о стараниях рабочего (тестировщика), заработает идея с премированием / депремированием. Хороший работнгик будет стараться и будет приносить минимум красных бусинок. Хороший работник может вообще остаться после работы и делать лопатки до тех пор, пока там не будет НОЛЬ бусинок. Вопрос - у меня хороший тестировщик? должен ли он был выполнить данные проверки? Принят ли такой подход у тестировщиков, или я прошу невозможного?

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

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

[SALar]

2nhuber. Прекрасная формулировка.

2kukolev. Я неоднократно наблюдал ситуацию "красных бус" в реальных проектах. Достаточно типичная картина, которую я наблюдал множество раз:
* Вне зависимости от мастерства инженера дефекты попадают в продакшен.
* Ситуацию может и должен исправлять топменеджмент. Не менджмент среднего звена и, тем более, не лидер группы.
* Топменеджмент уверен, что виноваты инженеры.

Представьте, что мы вручаем поварам: подгнившее и десятки раз замороженное-размороженное мясо; каменноугольную крошку вместо углей, гвозди сотку вместо шампуров; печку прачку вместо мангала. Просим приготовить шашлык и даем семь с половиной минут. По истечению времени удивленно спрашиваем: "Что, неужели даже повар-гуру не может приготовить такую тривиальную вещь, как шашлык, нормально?! Это противоречие, и эксперимент с бусинами вызывает сомнение."

Причинами плохого результата могут быть:
1. Негодные исходные материалы. - встречается чаще всего, и разработка софта не исключение.
2. Негодные средства.
3. Плохой процесс.
4. Несоответствующие нормы деятельности.
5. Неправильное описание продукта.
6. Недостаточные навыки инженера.
За какие пункты из этого кто отвечает?

[blacksmith]

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

kukolev, бабам - бусы и секреты кухни, а мужикам конкретный разговор:
1. какие ступени карьеры ты прошёл, прежде, чем стал "руковожу процессом разработки и тестирования"?
2. исходник с участком кода, где была ошибка обработки события наведения курсора на фрейм смотрел? или на этом уровне адекватно проводить анализ причин ошибки разработки не можешь?
3. какие тест-планы, кейсы, чек-листы, ... что из согласованного тобой не выполнил тестер? или под твоим руководством тестер не имеет конкретных заданий, работает в условиях неопределённости?
4. что это за непрофессиональный лепет ты используешь: "если пользователь проводил мышкой над Фрйэмом" вместо, например, "когда пользователь наводит курсор мыши на Фрйэм"?
5. такой, как ты есть, руководитель над разработчиками и тестерами, зачем ты им нужен? какой их ответ предполагаешь?
6. какая методология в управлении у тебя используется? сам-то продукт смотришь/проверяешь?
Не выяснив ответы на эти вопросы, не готов ответить "кто виноват?" разработчик или тестировщик!

[kukolev]

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

kukolev, бабам - бусы и секреты кухни, а мужикам конкретный разговор:
1. какие ступени карьеры ты прошёл, прежде, чем стал "руковожу процессом разработки и тестирования"?
2. исходник с участком кода, где была ошибка обработки события наведения курсора на фрейм смотрел? или на этом уровне адекватно проводить анализ причин ошибки разработки не можешь?
3. какие тест-планы, кейсы, чек-листы, ... что из согласованного тобой не выполнил тестер? или под твоим руководством тестер не имеет конкретных заданий, работает в условиях неопределённости?
4. что это за непрофессиональный лепет ты используешь: "если пользователь проводил мышкой над Фрйэмом" вместо, например, "когда пользователь наводит курсор мыши на Фрйэм"?
5. такой, как ты есть, руководитель над разработчиками и тестерами, зачем ты им нужен? какой их ответ предполагаешь?
6. какая методология в управлении у тебя используется? сам-то продукт смотришь/проверяешь?
Не выяснив ответы на эти вопросы, не готов ответить "кто виноват?" разработчик или тестировщик!

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