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

[PavelB]

Только ведь все равно, разное у них понимание жизни и вопросов

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

[Green]

На мой взгляд, большое значение играет структурное строение проектной команды. Усливно можно выделить две формы: тестировщики в составе проектной команды и подчиняются менеджеру проекта и тестировщики предоставляются в проектную команду, но подчиняются менеджеру тестировщиков.

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

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

Впрочем, есть еще один путь - черный пояс по карате/айкидо/дзюдо/ и пр.
:P

[romanl]

Есть такая фраза: "Мужчины с Марса, женщины с Венеры". Так вот, иногда появляется ощущение, что тестеровщики и программисты тоже с разных планет.

У нас была такая закономерность. Если программист профи то большинство (кроме орфографических) ошибок он с радостью принимает и исправляет, а если не профи, то тогда начинает генерить отмазки. Вся идея в том, что у нас, перед тем как программист отдает проект на тестирование он его сам хорошенько тестирует, а если тестер нашел баг то это камень в его огород и ему интересно как это тестер нашел баг а он нет. <_<

[Green]

Могу еще один приемчик подсказать. У нас его одна женщина использовала...

У нее на столе всегда стояла тарелка с конфетами. Программисты очень любили поговорить с ней о багах.
:D

[romanl]

Могу еще один приемчик подсказать. У нас его одна женщина использовала...

У нее на столе всегда стояла тарелка с конфетами. Программисты очень любили поговорить с ней о багах.
:D

Я тоже любил что-то вкусненькое на рабочем месте ставить (правда для себя) и за 2-3 часа приходили все кому не лень. Чаще всего приходили проджект-менеджеры. :D

[Dmitry_NJ]

Надо постараться не только убедить разработчика, что неработающий шорткат вызовет "панику" :huh: у заказчика, но и заинтерсовать его в исправлении дефекта.

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

[Vasiliy]

Впрочем, есть еще один путь - черный пояс по карате/айкидо/дзюдо/ и пр.
:P

У нас таковой у одного из программистов.
Сначала понаблюдаешь его "бой с тенью" в коридоре, а потом подумаешь стоит ли доказывать ему свою точку зрения на его баги:)

[Victorea]

На мой взгляд, большое значение играет структурное строение проектной команды. Усливно можно выделить две формы: тестировщики в составе проектной команды и подчиняются менеджеру проекта и тестировщики предоставляются в проектную команду, но подчиняются менеджеру тестировщиков.

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

[Green]

На мой взгляд, большое значение играет структурное строение проектной команды. Усливно можно выделить две формы: тестировщики в составе проектной команды и подчиняются менеджеру проекта и тестировщики предоставляются в проектную команду, но подчиняются менеджеру тестировщиков.

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

Еще ни разу в своей практике не встречал ни одного ПМ который бы смог грамотно ставить задачи на тестирование. Помогать - да, но руководить тестировщиком - нет.

Именно поэтому тестировщик не должен подчиняться ПМ-у.

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

[Victorea]

Еще ни разу в своей практике не встречал ни одного ПМ который бы смог грамотно ставить задачи на тестирование. Помогать - да, но руководить тестировщиком - нет.

Именно поэтому тестировщик не должен подчиняться ПМ-у.

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

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

[Dmitry_NJ]

Вот именно! Живут вместе и не могут друг на друга нарадоваться.

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

[barancev]

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

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

Когда МП помогает -- это не подчинение, это горизонтальная связь хоть и находятся они на разных уровнях иерархии.

Лично я имею мнение полностью противоположное высказанному Сергеем. Мне кажется более удобной и эффективной схема с полной проектной командой ("хирургическая бригада" Брукса). Но, по-моему мнению, из предложенных им двух вариантов нельзя выбрать более предпочтительный, всё зависит от конкретной организации, кому-то больше подходит одна форма (группировка по профессии), кому-то другая (группировка по проектам).

[barancev]

Еще ни разу в своей практике не встречал ни одного ПМ который бы смог грамотно ставить задачи на тестирование. Помогать - да, но руководить тестировщиком - нет.

Не буду отвечать на этот вызов, как-то нескромно :)

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

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

Если МП задачу принятия решения перекладывает на тестировщика -- гнать в шею менеждера.

Тоже уже повторяюсь. Тестировщик -- источник информации. Один из. Не более того.

[Green]

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

Если МП задачу принятия решения перекладывает на тестировщика -- гнать в шею менеждера.

Тоже уже повторяюсь. Тестировщик -- источник информации. Один из. Не более того.

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

Что русскому хорошо, то немцу смерть!
B)

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

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

Но Алексей прав, тестировщик не может принимать решение о готовности продукта. Он всего лишь дает информацию, позволяющую сделать такой вывод. Однако, (не помню где это читал, кажеться у Канера) руководитель тестировочного проекта должен иметь право вета на выпуск продукта. Это крайняя мера и может использоваться только, если руководитель проекта сошел с ума и выпускает абсолютно не работающий продукт. :) Но наличие такой возможности придает "вес" тестировщикам и дает возможность влиять на качество не только путем предоставления информации, но и через разделение ответственности за продукт.

[Green]

Еще ни разу в своей практике не встречал ни одного ПМ который бы смог грамотно ставить задачи на тестирование. Помогать - да, но руководить тестировщиком - нет.

Не буду отвечать на этот вызов, как-то нескромно :)

Согласен, звучит слишком категорично.
Жизнь меняется к лучшему!
:rolleyes:

[barancev]

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

[barancev]

Кстати, я запостил Славе статью, проливающую некоторый свет на обсуждаемый вопрос (почему разработчики недолюбливают тестировщиков). Опубликует -- обсудим :)

[Green]

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

Вообще то, не совсем так.

Я держу в голове немного другую модель. Есть Проектный менеджер, есть Руководитель группы разработчиков (key developer), и есть руководитель группы тестирования.

Юридическое решение о выпуске продукта принимает проектный менеджер на основании информации, поступившей как от разработчиков, от тестировщиков, так и от заказчика (если ему предоставляется билд на ознакомление/тестирование).

Но при всем при этом, руководитель тестировщиков может наложить мотивированный запрет на выпуск продукта и апеллировать свое решение к руководству компании.

[Mad Cat]

Как Team tester могу сказать, что неоднократно сталкивался с превалированием финансовых аспектов над качеством. Т.е. если ситуация на рынке благоприятна то могут (и скорее всего так и сделают) выпустить сыроватый продукт. И это вполне естественно.

[barancev]

Я держу в голове немного другую схуму работы. Есть Проектный менеджер, есть Руководитель группы разработчиков (key developer), и есть руководитель группы тестирования.

Юридическое решение о выпуске продукта принимает проектный менеджер на основании информации, поступившей как от разработчиков, от тестировщиков, так и от заказчика (если ему предоставляется билд на ознакомление/тестирование).

Но при всем при этом, руководитель тестировщиков может наложить мотивированный запрет на выпуск продукта и апеллировать свое решение к руководству компании.

Давайте попробуем представить, как работает такая схема. Представим себе, что мы разрабатваем продукт ABC. Руководитель отдела разработки считает, что до выпуска нужно ещё завершить фичи X и Y, а руководитель отдела тестирования не желает смириться с тем, что в модуле Z есть серьёзные ошибки. Вопрос: следует ли выпускать продукт в конце августа, если отдел маркетинга считает, что самое удобное время для начала распространения -- сентябрь и известно, что в начале сентября конкурент готовится выпустить на рынок похожий продукт? И кто должен принять такое решение? Может быть руководитель отдела разработки? Ни в коем случае не нужно его напрягать этими проблемами! У него ни времени ни сил не хватит для обработки всей этой информации, потому что тогда он не сможет руководить разработкой и выполнять свои прямые обязанности. И вообще, чем тогда будет заниматься менеждер производства продукта, а?