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

[frei_by]

"пока совсем не прогорели" - это не факт. Формулировка не корректна.
Если тестирование выявляет что "всё капут" - то оно как-бы само себе делает выстрел в голову.

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

[VikaCP]

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

Я согласна с тем, что уж лучше позднее тестирование, чем совсем никакого. Тут сразу можно оговориться, что в продуктовых и в аутсорсиноговых компаниях изначально разные модели поведения в подобных случаях.
Когда я только пришла работать и была еще совсем молоденькой студенкой, я услышала от своего начальника фразу, которая по сей день для меня является руководством к действию:"Прежде, чем говорить, что что-то не сработает, предложи альтернативу, которая, по-твоему мнению, сработает. Критиковать всегда гораздо проще, чем решать проблемы".
Так и результатом работы QA должен являться продукт надлежащего качества. Иначе работа QA превращается в работу контроллера над программистами. Это я к тому, что если тестирование определило, что продукт уныл, то оно же должно предложить альтернативу. Скажем, продукт уныл из-за того, что в нем баг на баге сидит и багом погоняет. Альтернатива - пофиксить баги. Или продукт уныл, потому что он не отвечает требованиям и ожиданиям заказчика (рынка). Альтернатива- обсудить с BA, PM, маркетингом (в зависимости о того, что за проект имеется в виду) какие требования не выполняются и прделоожить вариант доработки. В некоторых ситуациях (в основном продуктовых компаний касается) альтернативой может стать отказ от выпуска продукта или решение о его кардинальное переделке. В аутсорсинговых компаниях все сложнее, но там тоже вряд ли кто-то захочет отдавать заказчику то, что он потом с отвращением вернет обратно. В любом случае и однозначно, лучше найти проблему поздно, чем узнать о ней пост фактум.

[SALar]

Менеджер Василий трудился над большим и сложным проектом. Бюджеты, сроки, таски, кейсы. Пропущено два отпуска, работа сверхурочно и без выходных. Но вот совершенно случайно идя утром на работу Василий услышал в парке чарующие звуки свирели. Как вкопанный остановился он и слушал, и слушал, и слушал. А музыка вела его в неизведанные дали, рассказывала о страшных препятствиях и сказочных кладах, о крепкой дружбе и о предательстве, о тяготах пути и о наградах героям. Слезы текли по лицу Василия и тут он понял, что что продукт уныл, никуда не годится и всех надо разогнать, пока совсем не прогорели. Пришел он на работу, всех разогнал и фирма не прогорела.
Нужно было в таком случае послушать свирель?

Естественно нужно!!! Иначе никто никогда и никак бы не догадался, что продукт уныл. Ведь другого способа узнать этого не существует. Правда?

[frei_by]

...Пришел он на работу, всех разогнал и фирма не прогорела.
Нужно было в таком случае послушать свирель?

Естественно нужно!!! Иначе никто никогда и никак бы не догадался, что продукт уныл. Ведь другого способа узнать этого не существует. Правда?

Поэты-обманщики. Если-бы никто не догадался что проект уныл - он бы не был уныл. То, что проект не состялся - решает только целевая аудитория, и никто больше.
Я думаю, что если менеджер заявляет что проект уныл - то у такого менеджера проблемы с оценкой рисков.
Вложенные деньги в разработку нужно вернуть любым способом. Иначе менеджера вместе с програмистами нужно гнать с.. веником. Причём менеджера - в первую очередь.
Если тестирование выявляет, что всё пипец - нужно начинатьь заново - это плохое тестирование.
Возвращаясь к примеру с трубами -
если вы ожидали ПВХ трубы а вам поставили железные - то нужно просто задумаьтся о том, что возможно человек, котрый был отвественен за поставку не то, чтобы не понимает разницы между ПВХ и железом, а считает, что ПВХ МОЖЕТ быть заменён железом. В этом случае нужно проводить подробное тестирование - чтобы "просвятить" потсавщика о том, что ПВХ не может быть заменен железом. Если вы просто в отчёте напишите что железо не соотвествует ожидаемому ПВХ - вам ответят - используйте железо. И вам всё равно придётся доказвать почему не может быть ПВХ заменено на железо.
Поэтому - тетирование - как я его вижу - это максимальное описание в деталях того, чем ожидаемй результат отличается от фактического.Предполагается - , что если исправить все баги то ожидаемый и фактический совпадут. = проект больше не УГ.
Если единственным выводом из всех багов является то, что нужно всё закрыть - то это плохое тестирование. Самый самый плохой продукт выпущенныйи на рынок имеет мизерный-мизерный шанс отбить расходы на его создание. Если вы всё загубите до выхода релиза - у вас вообще нет никаких шансов отыграть вложенные в разаработку средства.

[LeshaL]

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

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

[aleksirin]

Еще раз перечитал ветку. Смущает фраза

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

и не меня одного, очевидно. Чем больше над этим думаю, тем четче понимаю, что это чушь!

1) Во-первых, тестирование не предназначено априори служить целям для выявления степени годности продукта с т.з. годности на уровне прогорим/не прогорим. Это задача других отделов и специалистов. Тестирование же это часть производственного процесса, уже согласованного, одобренного и принятого в производство. Из-за отбракованной партии готовой продукции на конвеере на любом заводе не останавливают же линию, т.е. заказчики ЖДУТ товар в указанные сроки не зависимо от % брака в отделе ОТК. Наоборот хорошо, что это унылое г-но не попало к заказчику..

2) Во-вторых, результаты тестирования никак не могут служить основанием для принятия решения "разгоним всех, чтобы не прогорели" (см. выше). Я даже не представляю себе тот примитивный уровень руководства организации, которое решило что-то выпустить, выпустили, потом догадались протестировать, поняли, что этим продуктом пользоваться нельзя и его никто не купит, и в итоге всех разогнали... Школота! Поделом таким, персонал вот только жалко...

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

Все наоборот выходит? :-)

P.S.

Что такое поздно проведенное тестирование, мне до сих пор не ясно. Если Производственный процесс завершен и релиз ушел - далее работает поддержка и собирает жалобы и далее по кругу (фиксы, тесты, выпуск), если производственный процесс не завершен, то тестирование, будучи частью производства, не может быть выполнено поздно по-определению. Исключение: аутсорсеры подвели... ну тут уж форс-мажор надо закладывать коль уж на своих тестеров жалко бюджет. Так или иначе но из-за результатов тестирования разгонять персонал... вы меня извините!

[Куатор]

Я сказала, что тестирование не нужно если в результате его действий не будет улучшаться продукт, фикситься баги, и т.д. Есть разница

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

Предупреждён - значит вооружён.
Лично я предпочитаю действовать при свете дня, а не в кромешной тьме (сумерках или просто закрытых глазах).. Мои дальнейшие решения будут основаны на том, что я вижу при свете, будь-то тонущий корабль или лайнер заходящий в порт назначения (причём не важно капитан я , член команды или пассажир, в любом случае дайте мне свет!).
Тестирование - свет на происходящее и оно важно. Я согласен с Натальей - если менеджер (капитан), примет одно и тоже решение - и в случае, если корабль тонет, и в случае, если успешно заходит в порт - тогда такому капитану не нужен свет.. и в этом случае тестирование - лишнее.
Такое себе ИМХО :)