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

[barancev]

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

Это вы, дорогой товарищ, заблуждаетесь. Оба важно. Иногда важнее одно, а в другой раз другое. Вот, кстати, почитайте это: http://www.jrothman....priorities.html , особенно внимательно раздел "Define Product Quality and Milestone Criteria".

[Pryanik]

Я видел такое много раз -- тестировщики ждут, а релиз на тестирование всё не выкатывают и не выкатывают. Неужели правда у вас такого не бывало?

А как тогда вы нашли ошибки если релиз на стадии разработки? Вот, к сожалению, не бывало:) Занимаюсь в описаном выше случае : авт. часть тестов предыдущей версии, стат. тестированием, составление тест-плана, тест-кейсов, ...

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

Опять же повторюсь я не отвергаю сразу этот вариант. Если тестировщик (как человек) " и швец и жнец и на дуду игрец" (обладает всеми качествами этих ролей), то я только "ЗА" такой вариант.
Риски такая штука, которые все же стоит минимизировать. Иначе за то, что у вас получится, никто ручаться не будет. А Мы все на этом форуме радеем за качественный продукт! Или я не прав?:)

[greesha]

Риски такая штука, которые все же стоит минимизировать. Иначе за то, что у вас получится, никто ручаться не будет. А Мы все на этом форуме радеем за качественный продукт! Или я не прав?:)

"Да, все голосуют за качество, но если оно стоит лишнюю копейку, вы начинаете быстро познавать настоящее отношение к качеству со стороны тех, кто платит."
Том Демарко и Тимоти Листер. Человеческий фактор: успешные проекты и команды

[Pryanik]

Это вы, дорогой товарищ, заблуждаетесь. Оба важно. Иногда важнее одно, а в другой раз другое. Вот, кстати, почитайте это: http://www.jrothman....priorities.html , особенно внимательно раздел "Define Product Quality and Milestone Criteria".

Это лишь подтверждает мое мнение, единого подхода ко всем проектам нет. "Равнять все под одну гребенку" - не надо.
Отсюда вытекает ответ на вопрос топика: и Да и Нет. Все зависит от многих показателей.
А вот теперь более сложная задача определить все показатели...

[ShortLegged]

Риски такая штука, которые все же стоит минимизировать. Иначе за то, что у вас получится, никто ручаться не будет. А Мы все на этом форуме радеем за качественный продукт! Или я не прав?:)

Рисками нужно управлять. No risk - No value.

[Clauster]

Вы, наверное, неправильно поняли. Я не считаю и не писал, что "это не моя работа". Я лишь считаю, что не все тестировщики обладают необходимой квалификацией для исправления кода. Программисты сделают это быстрее и качественнее, даже если ошибка проста и очевидна на первый взгляд, и можно исправить код самому. А бросаться на те ошибки которые "я могу исправить", а те, которые "не могу" и оставлю ее программистам - не стоит. Если бы все было так просто, то зачем тогда отдельно отдел тестирования? Хватит и программистов: один пишет код; другой делает ревью и исправляет найденные ошибки! Мой подход в другом - у кого хватает опыта и квалификации тот и должен заниматься этим. К тому же изначально было условие "если программист занят, а у тестировщика есть свободное время". Я, из личного опыта, такого еще ни разу не видел. А вы? Даже если время тестировщика стоит меньше чем программиста это не повод чтоб данным тип работ передавать тестировщику, это может потом вылиться в сумму "более ощютимую" чем стоимость часов работы программиста.

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

[Clauster]

А Мы все на этом форуме радеем за качественный продукт! Или я не прав?:)

Снимите уже ваши розовые очки. Быстро, дешево, качественно - лишнее вычеркнуть. Обычно вычеркивают последнее. Мы, конечно, радеем, но надо быть поближе к реалиям.

[Pryanik]

Снимите уже ваши розовые очки. Быстро, дешево, качественно - лишнее вычеркнуть. Обычно вычеркивают последнее. Мы, конечно, радеем, но надо быть поближе к реалиям.

Если "быть ближе к реалиям", то задача не вычеркнуть лишнее, а подобрать оптимальное соотношение всех трех параметров, которое устраивает заказчика. ;)
Или ваши заказчики готовы платить за воздух?

[Bars Master]

Снимите уже ваши розовые очки. Быстро, дешево, качественно - лишнее вычеркнуть. Обычно вычеркивают последнее. Мы, конечно, радеем, но надо быть поближе к реалиям.

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

[Boltick]

И еще к разделению обязанностей: мы ведь не задаем вопрос "должен ли тестировщик исправлять баги, которые сделал разработчик (хоть некоторые )?"

Очень верное замечание. Почему мы действительно не задаём такой вопрос?

Итак, коллеги, хочу задать вопрос: должен ли тестировщик исправлять баги, которые сделал разработчик, ну хотя бы некоторые?

Нет, не должен! Если конечно это не разработчик, выполняющий на проекте роли тестера и девелопера в одном лице. :)

АнтиПример: из жизни я тестер, но как-то на одном богом забытом проекте, который долго уже висел на саппорте, была найдена пара тройка багов, которые лично меня ПМ попросил зафиксить :) по причине того, что я знаю это приложение, и я неплохо знаю Java.

Вот.

[Boltick]

Я видел такое много раз -- тестировщики ждут, а релиз на тестирование всё не выкатывают и не выкатывают. Неужели правда у вас такого не бывало?

А как тогда вы нашли ошибки если релиз на стадии разработки? Вот, к сожалению, не бывало:)

Все зависит от того, когда вы начинаете тестирование... Если вы "идете" по водопаду, то да - пока продукт не готов, вы его не увидите, а что если у вас итеративная модель? тогда вы получаете в тестирование все по кусочкам, итерация за итерацией. А если еще и автотесты пишутся параллельно с разработкой, т.е. вы можете гонять их на самом "свежесобранном" девелоперском окружении? :)
Так что It Depends on...

[Clauster]

Снимите уже ваши розовые очки. Быстро, дешево, качественно - лишнее вычеркнуть. Обычно вычеркивают последнее. Мы, конечно, радеем, но надо быть поближе к реалиям.

Если "быть ближе к реалиям", то задача не вычеркнуть лишнее, а подобрать оптимальное соотношение всех трех параметров, которое устраивает заказчика. ;)
Или ваши заказчики готовы платить за воздух?

Ключевое слово платить.

[Clauster]

Снимите уже ваши розовые очки. Быстро, дешево, качественно - лишнее вычеркнуть. Обычно вычеркивают последнее. Мы, конечно, радеем, но надо быть поближе к реалиям.

брр, не согласен, точнее все зависит от продукта в целом, к примеру я работал в компании, которая не могла себе позволить хоть один minor на полевой версии...

В это слабо верится, но давайте не будем впадать в крайности.

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

Вообще, вы выдернули мой пост из контекста и придираетесь к словам. Для вас разъясню:
быстро - есть определенные временные рамки
дешево - есть определенный бюджет
качественно - тут ничего определенного нет. Можно отказаться от некоторых фич, сократить время на тестирование и т.д.
И ещё учтите что качество обеспечивает далеко не только тестирование.

[Bars Master]

В это слабо верится, но давайте не будем впадать в крайности.

в принципе да, тут больше исключение чем правило.

Вообще, вы выдернули мой пост из контекста и придираетесь к словам. Для вас разъясню:
быстро - есть определенные временные рамки
дешево - есть определенный бюджет
качественно - тут ничего определенного нет. Можно отказаться от некоторых фич, сократить время на тестирование и т.д.
И ещё учтите что качество обеспечивает далеко не только тестирование.

Я к счастью, не имею привычки выдергивать слова из контекста, я сказал ровно так, как понял фразу, а фраза далеко не двусмысленна была.
Вот теперь я понял что имелось ввиду под "вычеркивают качество" и собственно с такой фомулировкой полностью согласен.