Это вы, дорогой товарищ, заблуждаетесь. Оба важно. Иногда важнее одно, а в другой раз другое. Вот, кстати, почитайте это: http://www.jrothman....priorities.html , особенно внимательно раздел "Define Product Quality and Milestone Criteria".Время выпуска не самая главная характеристика. На мой взгляд, и менеджеру и заказчику важнее все же "качество".
должен ли программист тестировать?
#61
Отправлено 20 января 2009 - 11:08
Тренинги для тестировщиков (тестирование производительности, защищенности, тест-дизайн, автоматизация):
Линейка тренингов по Selenium
#62
Отправлено 20 января 2009 - 11:25
А как тогда вы нашли ошибки если релиз на стадии разработки? Вот, к сожалению, не бывало:) Занимаюсь в описаном выше случае : авт. часть тестов предыдущей версии, стат. тестированием, составление тест-плана, тест-кейсов, ...Я видел такое много раз -- тестировщики ждут, а релиз на тестирование всё не выкатывают и не выкатывают. Неужели правда у вас такого не бывало?
Опять же повторюсь я не отвергаю сразу этот вариант. Если тестировщик (как человек) " и швец и жнец и на дуду игрец" (обладает всеми качествами этих ролей), то я только "ЗА" такой вариант.Иногда может вылиться, а иногда можно и неплохо сэкономить. Почему сразу нужно отвергать этот вариант? Из-за того, что есть риски? Ну так и работайте с рисками, что просто так-то бояться.
Риски такая штука, которые все же стоит минимизировать. Иначе за то, что у вас получится, никто ручаться не будет. А Мы все на этом форуме радеем за качественный продукт! Или я не прав?:)
#63
Отправлено 20 января 2009 - 11:32
Риски такая штука, которые все же стоит минимизировать. Иначе за то, что у вас получится, никто ручаться не будет. А Мы все на этом форуме радеем за качественный продукт! Или я не прав?:)
"Да, все голосуют за качество, но если оно стоит лишнюю копейку, вы начинаете быстро познавать настоящее отношение к качеству со стороны тех, кто платит."
Том Демарко и Тимоти Листер. Человеческий фактор: успешные проекты и команды
#64
Отправлено 20 января 2009 - 11:35
Это лишь подтверждает мое мнение, единого подхода ко всем проектам нет. "Равнять все под одну гребенку" - не надо.Это вы, дорогой товарищ, заблуждаетесь. Оба важно. Иногда важнее одно, а в другой раз другое. Вот, кстати, почитайте это: http://www.jrothman....priorities.html , особенно внимательно раздел "Define Product Quality and Milestone Criteria".
Отсюда вытекает ответ на вопрос топика: и Да и Нет. Все зависит от многих показателей.
А вот теперь более сложная задача определить все показатели...
#65
Отправлено 20 января 2009 - 11:51
Рисками нужно управлять. No risk - No value.Риски такая штука, которые все же стоит минимизировать. Иначе за то, что у вас получится, никто ручаться не будет. А Мы все на этом форуме радеем за качественный продукт! Или я не прав?:)
#66
Отправлено 20 января 2009 - 12:06
Зачем передавать что-то тестировщику. Здесь не было речи о том, что начальник ставит задачу неквалифицированному тестировщику фиксить баги. Мой посыл в том, что если ты видишь проблему и знаешь как её решить, реши её. Не важно что это за проблема - ошибка в программе или может даже кофемашина загрязнилась.Вы, наверное, неправильно поняли. Я не считаю и не писал, что "это не моя работа". Я лишь считаю, что не все тестировщики обладают необходимой квалификацией для исправления кода. Программисты сделают это быстрее и качественнее, даже если ошибка проста и очевидна на первый взгляд, и можно исправить код самому. А бросаться на те ошибки которые "я могу исправить", а те, которые "не могу" и оставлю ее программистам - не стоит. Если бы все было так просто, то зачем тогда отдельно отдел тестирования? Хватит и программистов: один пишет код; другой делает ревью и исправляет найденные ошибки! Мой подход в другом - у кого хватает опыта и квалификации тот и должен заниматься этим. К тому же изначально было условие "если программист занят, а у тестировщика есть свободное время". Я, из личного опыта, такого еще ни разу не видел. А вы? Даже если время тестировщика стоит меньше чем программиста это не повод чтоб данным тип работ передавать тестировщику, это может потом вылиться в сумму "более ощютимую" чем стоимость часов работы программиста.
#68
Отправлено 20 января 2009 - 12:30
Если "быть ближе к реалиям", то задача не вычеркнуть лишнее, а подобрать оптимальное соотношение всех трех параметров, которое устраивает заказчика. ;)Снимите уже ваши розовые очки. Быстро, дешево, качественно - лишнее вычеркнуть. Обычно вычеркивают последнее. Мы, конечно, радеем, но надо быть поближе к реалиям.
Или ваши заказчики готовы платить за воздух?
#69
Отправлено 20 января 2009 - 13:07
брр, не согласен, точнее все зависит от продукта в целом, к примеру я работал в компании, которая не могла себе позволить хоть один minor на полевой версии...Снимите уже ваши розовые очки. Быстро, дешево, качественно - лишнее вычеркнуть. Обычно вычеркивают последнее. Мы, конечно, радеем, но надо быть поближе к реалиям.
Вообще потеря качества может существенно вылится в потерю денег, и имиджа, а как следствие опять денег.
Благо, я не работал в компаниях где необходимо дешево и быстро, а насчет качества - как получится.
#70
Отправлено 20 января 2009 - 13:20
Очень верное замечание. Почему мы действительно не задаём такой вопрос?И еще к разделению обязанностей: мы ведь не задаем вопрос "должен ли тестировщик исправлять баги, которые сделал разработчик (хоть некоторые )?"
Итак, коллеги, хочу задать вопрос: должен ли тестировщик исправлять баги, которые сделал разработчик, ну хотя бы некоторые?
Нет, не должен! Если конечно это не разработчик, выполняющий на проекте роли тестера и девелопера в одном лице. :)
АнтиПример: из жизни я тестер, но как-то на одном богом забытом проекте, который долго уже висел на саппорте, была найдена пара тройка багов, которые лично меня ПМ попросил зафиксить :) по причине того, что я знаю это приложение, и я неплохо знаю Java.
Вот.
Про Тестинг
#71
Отправлено 20 января 2009 - 13:25
Все зависит от того, когда вы начинаете тестирование... Если вы "идете" по водопаду, то да - пока продукт не готов, вы его не увидите, а что если у вас итеративная модель? тогда вы получаете в тестирование все по кусочкам, итерация за итерацией. А если еще и автотесты пишутся параллельно с разработкой, т.е. вы можете гонять их на самом "свежесобранном" девелоперском окружении? :)А как тогда вы нашли ошибки если релиз на стадии разработки? Вот, к сожалению, не бывало:)Я видел такое много раз -- тестировщики ждут, а релиз на тестирование всё не выкатывают и не выкатывают. Неужели правда у вас такого не бывало?
Так что It Depends on...
Про Тестинг
#72
Отправлено 20 января 2009 - 14:07
Ключевое слово платить.Если "быть ближе к реалиям", то задача не вычеркнуть лишнее, а подобрать оптимальное соотношение всех трех параметров, которое устраивает заказчика. ;)Снимите уже ваши розовые очки. Быстро, дешево, качественно - лишнее вычеркнуть. Обычно вычеркивают последнее. Мы, конечно, радеем, но надо быть поближе к реалиям.
Или ваши заказчики готовы платить за воздух?
#73
Отправлено 20 января 2009 - 14:37
В это слабо верится, но давайте не будем впадать в крайности.брр, не согласен, точнее все зависит от продукта в целом, к примеру я работал в компании, которая не могла себе позволить хоть один minor на полевой версии...Снимите уже ваши розовые очки. Быстро, дешево, качественно - лишнее вычеркнуть. Обычно вычеркивают последнее. Мы, конечно, радеем, но надо быть поближе к реалиям.
Вообще, вы выдернули мой пост из контекста и придираетесь к словам. Для вас разъясню:Вообще потеря качества может существенно вылится в потерю денег, и имиджа, а как следствие опять денег.
Благо, я не работал в компаниях где необходимо дешево и быстро, а насчет качества - как получится.
быстро - есть определенные временные рамки
дешево - есть определенный бюджет
качественно - тут ничего определенного нет. Можно отказаться от некоторых фич, сократить время на тестирование и т.д.
И ещё учтите что качество обеспечивает далеко не только тестирование.
#74
Отправлено 20 января 2009 - 15:14
в принципе да, тут больше исключение чем правило.В это слабо верится, но давайте не будем впадать в крайности.
Я к счастью, не имею привычки выдергивать слова из контекста, я сказал ровно так, как понял фразу, а фраза далеко не двусмысленна была.Вообще, вы выдернули мой пост из контекста и придираетесь к словам. Для вас разъясню:
быстро - есть определенные временные рамки
дешево - есть определенный бюджет
качественно - тут ничего определенного нет. Можно отказаться от некоторых фич, сократить время на тестирование и т.д.
И ещё учтите что качество обеспечивает далеко не только тестирование.
Вот теперь я понял что имелось ввиду под "вычеркивают качество" и собственно с такой фомулировкой полностью согласен.
Количество пользователей, читающих эту тему: 0
0 пользователей, 0 гостей, 0 анонимных