Привет!
Возник такой вопрос, что лучше - сделать работу быстро или сделать ее качественно?
Речь о нашей с вами работе - и тестировании и обеспечении качества продукта в целом.

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

Предлагаю рассмотреть два аспекта - личную работу и работу сделанную коллегами\подчиненными.
Лично за собой замечаю, что иногда в пику скорости я делаю упор на качестве. Проверяю маловероятные вещи, double-checking итд. Иногда, готов забить на что-то, главное поскорее завершить тот или иной вид работ. Но в большинстве случаев я ставлю на качество, а не на скорость собственно работы.
Коллеги\подчиненные: иногда, чью-то работу хочется перепроверить, т.к. есть сомнения, что человек за такой короткий срок сумел все протестировать. А в другой раз - думаешь, ну и фиг с ним, главное, что там хоть как-то посмотрели, сделали shallow тестирование и хватит.
Но у меня-то и опыт работы уже неплохой, а как быть с новыми сотрудниками? Кого бы вы предпочли взять?
И как определить критерии, где важнее скорость, а где качество?

PS: Очевидный ответ "и быстро и качественно" - не годится :).

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

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

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

Как показывает практика, вначале проходим быстро, чтобы найти явные ошибки (дабы было что показать заказчику и приложение не валилось) - дымовое тестирование. Цель - заставить приложение не падать и не давать очевидных ошибок.

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

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

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

Поэтому обычно делаем ставку на скорость, а затем на качество (это не утверждение, а рекомендация, т.к. проекты бывают разные).

Вы меня немного недопоняли. Я спрашиваю о человеческом аспекте. Не о стратегии тестирования. С этим более-менее понятно.
Просто все люди разные. Есть те, которые просто не могут делать работу быстро, а будут копать по сторонам, пытаясь найти возможные проблемы. И есть другие, которые не в состоянии сделать шаг влево\вправо от действий, предписаных в описании теста и т.о. найти кучу жуков.
По первым, есть опастность, что человек, если прывык изучать все в деталях, то вместо выполнения тестов, он застрянет на первом же баге. Переворошит кучу спецификаций, потратит кучу времени на investigation, когда этого не надо делать. Есть примеры из жизни. Сам так начинал, правда без перегибов.
Во втором случае тоже есть недостаток. Зачастую тестовая документация пишется так, чтобы предоставить свободу человеку, выполняющему тестирование. Или что-то упущено в тестовой документации. И если у человека не возникает вопроса "а что если?" - он все сделает хорошо, как предписано - но этого будет недостаточно для качественного тестирования.

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

Если оба хороши, то есть ясно, что кого-то из них надо брать - выбрал бы того, который поживей, порассудительней, или же бросил монету. ("Надо брать", замечу, автоматически означает, что человек неплохо отдаёт себе отчёт в осуществляемых операциях и в высказываниях, адекватен в целом.)
Если есть сомнения, брать ли вообще кого-то из двух, - не брал бы никого, искал других.

Я бы на вашем месте взял и того, и другого. А руководитель может помочь научить одного "не тормозить", а второго тщательнее проверять. Ведь тестировщиков мало, нужно всего лишь "доработать напильником" :)
А вот если человек не хочет работать в команде и считает себя умнее всех, то такой специалист не нужен.
Смотрите на человеческий фактор.

Как людям объяснить когда быстрее, а когда качественнее? У вас ведь есть процессы, вот и покажите сотрудникам, что в соответствии с процессами (что я писал в предыдущем посте) нужно быстрее, а потом качественнее. Объясните, что ошибки вначале целесообразнее находить критические, т.к. фикс одной может закрыть результаты тщательного, но излишнего тестирования (т.е. 10 ошибок закрыты, как следствие лечения 1).
Ну и сроки, сроки... Идеальных продуктов не бывает, но бывают рабочие и сопровождаемые.

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

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


Спасибо.

1. Теорвер. Раздел многофакторный эксперимент. Читаем и проникаемся великими возможностями математического аппарата. (IMG:style_emoticons/default/smile.gif)
2. Проводим многофакторный эксперимент на своем проекте.
3. Показываем результат заинтересованным лицам и убеждаем их максимизировать результат. К несогласным принять меры. Расстрел через повешение, например. (IMG:style_emoticons/default/diablo.gif)

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

http://pmprofy.ru/content/rus/126/1261-article.asp

Просто стремитесь работать в организациях типа Дельта.

PS. На самом деле, данный метод обладает существенной погрешностью. Размер погрешности находится в обратной зависимости от опыта инженера.

Сергей, тип организации, имхо, не сможет сильно повлиять на выбор между кандидатом парвого или второго типа. Я прочитал еще раз ответы и сделал такой вывод, что большее значение имеет тип работы, который как предполагается будет выполнять сорудник. А в любом типе организации нужны как те, так и другие люди.
Поэтому резюме такое:
1) Если есть возможность взять обоих - надо брать. Первый хорошо подойтет на работу, типа регрессионного тестирования, где главное не просмотреть новых-старых проблем. Или на acceptance тестирование, где не надо копать вглубь. Второй тип, хорошо подойдет для написания тестовой документации или на углубленное исследование какой-нибудь функциональности с высокими бизнес-рисками.
2) Если есть возможность взять только одного - то, надо понимать что он будет делать и куда потом его можно определить, после того как задача, под которую нанимается человек закончится.
3) Со временем и с опытом большинство людей "научаются" сами расставлять приоритеты, где надо быстро, но поверхностно, а где надо убить время и убедиться, что все хорошо. А вот на первых порах - задача руководителя, как можно более четко формулировать задание и приоритеты - вглубь или вширь копать. И постоянно контролировать.
4) А вот про "доработать напильником" не уверен, что это будет полезно. Можно получить нечто среднее, утку. Ведь как известно, утка - птица, которая умеет летать, плавать и ходить. Но все это она делает одинаково плохо.

Для нашей ситуации, я уже пришел к определенному выводу и знаю какому типу кандидата отдать предпочтение.

PS: а проводить эксперимент, по-моему, в данном случает нет смысла. Т.е. экперимент-то все-таки проводится на собеседовании. А вот во время работы, когда человек уже принят - проводить эксперименты поздно - надо работать.

Как-то я не очень понимаю о каких экспериментах идет речь на собеседовании. Есть нормальная практика - испытательный срок, вот на нем и можно проводить эксперименты.

Насчет испытательного срока - вы правы. Я как-то подзабыл об этом.
А на собеседовании даются задания. Даются для того чтобы проверить что человек думает и как человек умеет размышлять. Из того, как человек мыслит - можно составить первое впечатление.
Чем это не эксперимент. На форуме есть ветка с картинкой неудачного сообщения об ошибке. Вот - вы там тоже учавствовали. Показательная ситуация.
Мы насобеседовании логические задачки даем - тоже очень показательно. Одни кучу if-ов при решении найдут, другие - в лоб, по простому, решают. Причем главное не само решение - а процесс достижения этого решения.

Вопрос дискуссии относится к категории классического треугольника альтернатив. "Быстро", "Качественно" и "Дешево" нужно поместить в вершины треугольника. Объективная реальность утверждает, что в конкретном случае можно выбрать только одну сторону получившегося треугольника. Любо "быстро" и "дешево", тогда страдает качество. Либо "качественно" и "дешево", тогда страдает скорость, и т.д.

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

Что нужно сделать, что бы повысить одну или даже все характеристики? Другими словами, что нужно сделать для того, что бы выполнять больший объем работы с не худшим, а то и лучшим уровнем качества, в рамках того же бюджета.

1. Повысить квалификацию специалистов. За единицу времени они будут выполнять больший объем работ или улучшат качество своей работы.

2. Снизить издержки ( в первую очередь временные) за счет автоматизации рутинных работ, либо за счет оптимизации процессов.

По другому это можно сформулировать, как повышение уровня зрелости процессов.

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

Если говорить об автоматизации, то следует рассматривать два варианта:
- автоматизация регрессионного тестирования, либо автоматизация нагрузочного тестирования
- автоматизация операций

В первом случае все понятно. Во втором - я имею ввиду, работу с более продвинутыми тулами по учету дефектов (к примеру, нажал кнопочку и скрин-шот сам сабмитится в базу), по построению отчетов (один раз определил формат отчета и автоматически получаешь его на протяжении всего проекта), по управлению тестовыми активностями (создал тест кейсы и методом драг-ан-дроп формируешь тест съюты на каждую тестовую итерацию), провел тестирование, а тул тебе сразу же показал покрытие, не выпытываешь у разработчиков - что они нового добавили в билд, а автоматически с билдом получаешь билд ноутс, и т.п.

Решил еще добавить к предыдущему посту...

Лучше использовать термине не "автоматизация операций", а "оптимизация операций", которая в свою очередь может проводиться за счет автоматизации.

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

Это система "Lean", если не ошибаюсь. Кайдзен все таки более широк.

Не уверен на 100%, но у меня сложилось мнение, что Lean - это американизированная (или европеизированная) интерпретация японской кайдзен.

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

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

опять же много зависит от специфики проекта и области тестирования, если это логика, то лучше тщательнее и дольше, если это юзабилити для внутренних нужд какого-нть Центртелекома, то можно и ускориться!