А почему именно группу тест дизайна мотивировать нужно? Другие группы и так справляются, без мотивации? :))

потому, что остальные группы уже работают по определённым схемам....

Неплохой вариант проверки - дать тест дизайн человеку, который не видел софта и тестов... если человек сможет выполнить тесты по указанному документу, значит уже неплохо :)

это субъективная оценка.... но как её привязать к заработной плате?!

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

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

Я бы не рискнул завязывать эффективность работы тест дизайнера на деньги через количество тест кейсов, которые он написал.
И мотивировать "Вася написал больше строк кода тест кейсов, чем Петя", тоже гиблое дело".
А вот если человек сказал, что ему нужно 2 дня, утвердили, он справился вовремя и после ревью не выявили пропущенных моментов, это уже хороший мотиватор и возможно привязать это к деньгам в виде премии. Ещё советую почитать книжку "Мотивируйте меня правильно", там много полезного написано...

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

Это не мотивация называется.

смотрим на название темы... я говорил про оценку. Про мотивацию могу сказать только одно - ничто так лучше не мотивирует, как деньги :)

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

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


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

На первых порах ревью необходимо, чтобы повысить качество тест дизайна... дальше уже "по накатанной"...
Не думаю, что уместна. Всё же основная оценка делается во время ревью... а то, что требует время, дык никто и не возражает, но если вы сами хотите делать аудит, то закладывайтесь на него "по полной".
Дальнейшая оценка возможно такая - за определённый период пользователи нашли N- ошибок, которые не были заложены в тест дизайне. Если N- величина меньше критической, то молодец тест дизайнер. Если больше, то не молодец :)
...
Учтите только такой момент, что ответственность аудиторы будут также разделять с тест дизайнером... Получается, что они не заметили явных проколов.

....
Ну всё же с аудитом как с оценкой которая может повлиять на з/п никак не могу согласиться... ведь если например один человек будет проводить ревью, то оценка будет крайне субъективная.... и как же по ней з/п пересчитывать?!
...

А у нас ревью проводили не менее 2 человек . И потом - "субъективно". Тест дизайнер тоже присутствует при рефакторинге и согласование о том ошибка или нет делается совместно.

Поправил.

Шикарно! Разослал знакомым белым и чёрным обезъянам :)

по сути схема должна вынуждать работать

Плохая схема... долго нельзя держать работника одним кнутом.

ИМХО, любая попытка оценить работу в "циферках" и привязать оные к ЗП, только демотивирует...

+1
Дипломатия более эффективна

http://www.btlregion...t/117/index.htm

Как ребята нагло перевирают Сократа.

И не говорите Но зато какой эффект ))

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

Возможно вам повезло, что вы не видели руководителей, которые именно используют психологические приёмы, чтобы заранее настроить работников на переработки (Другое дело, что переработки могут оплачиваться или отгулами компенсироваться). И не то, чтобы ПРОТИВ его воли, а чтобы он был к этому готов заранее и сам дал утвердительный ответ.

Может он вообще не готов так работать и это были всего лишь слова.

А может рядом лежит контракт, где он подписывается?

Пример был утрирован, это всего лишь пример.

Хорошо, я дам вам ссылку
"Метод "сократовских" вопросов.
В свое время Сократ прославился тем, что изобрел оригинальный способ убеждения. Он ничего не “втолковывал” своему собеседнику — он просто задавал ему вопросы. При этом вопрос был сформулирован таким образом, что предполагал заранее прогнозируемый ответ — “да” или “нет”. Вы заинтересовались этой книгой, потому что считаете умение общаться с клиентом очень важным? И вы, наверное, знаете очень важные приемы работы с клиентом? И вы дошли до середины этой книги, потому что хотели бы усилить свое воздействие на клиента? Значит, вам стоит освоить и метод “сократовских вопросов”? Каков ваш ответ на четвертый вопрос? Если мы правильно задали все три вопроса, и получили на них положительные ответы, то на четвертый вопрос вы, скорее всего, ответите “да”.

Три ответа “да” бессознательно заставляют клиента дать положительный ответ и на четвертый вопрос."
http://www.btlregion...t/117/index.htm

Про правило "трёх да". В инете не искал, могу суть объяснить.
Если вам нужно, чтобы человек согласился с вашей точкой зрения, либо чтобы он ответил на вопрос "да", задайте ему 3 вопроса, на которые он 99% ответит "Да".
Например:
Вас зовут Наталья? - Да
В вашем резюме указано, что вы работаете тестировщиком, это так? - Да
Вы хотели бы работать в нашей фирме? - Да
...
Вы готовы к переработкам?....

Статья хорошая, вставлю свои 3 копейки.

Правило 7. Задавайте открытые вопросы. Недавно я была на собеседовании в крупной ИТ-компании. Собеседование проводила руководитель отдела по подбору персонала. И задавала мне вопросы, не оставляющие даже шанса ответить «неверно»: «Вы любите изучать новое?», «Вы не боитесь стрессовой работы?», «Вы готовы много коммуницировать на английском?», «Вы любите ответственность?», «Вы готовы принимать срочные, важные решения?». Как Вы думаете, я могла ответить что-то, кроме «Да, конечно!»?

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

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

Совместно со Славой сделали вариант документа по сабжу.
Это "рыба" (только содержание), поэтому наращивайте и меняйте её содержимое, как вам удобно.

1. Задачи отдела
1.1. Тестирование программных продуктов
1.1.1. Определение тестирования
1.1.2. Основные документы
1.1.3. Этапы выполнения работ
1.1.3.1. Планирование
1.1.3.2. Тест дизайн
1.1.3.3. Выполнение тестирования
1.1.3.4. Тест анализ
2. Состав отдела
2.1. Структура отдела
2.2. Правила назначения сотрудника в группу тестирования
2.3. Штатное расписание
2.3.1. Штатное расписание
2.3.2. Должностные инструкции
2.3.3. Премирования и поощрения
2.3.4. Взыскание и увольнение
2.3.5. Аттестация сотрудников
3. Правила оказания сервиса
3.1. Очередность выполнения заявок на тестирование
3.2. Процедуры приемки продукта в работу
3.2.1. Приёмка документации
3.2.2. Приёмка продукта
3.3. Правила предоставления отчётности и завершения работ
3.3.1. Отчёт о проведённой работе
3.3.2. Передача версии в отдел внедрения
3.3.3. Подготовка к приёмо –сдаточным испытаниям, итоговый отчёт

Алексей.

Либо вам там по случаю кризиса нечем полезным заняться :)

Вы думаете, это я сам придумал?

либо готовится какой-то аудит/сертификация.

- скорее "либо" :) Обратите внимание http://software-test...topic15863.html - видите, не я один такой.
...
To Alfa
Полное название "ПОЛОЖЕНИЕ О ВНУТРЕНЕМ ПРОЦЕССЕ ТЕСТИРОВАНИЯ В ПРОЕКТАХ РАЗРАБОТКИ ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ"

Алексей, спасибо.
Документ "Положение о тестировании" я уже написал.. это немного другой документ, нежели "Методика работы отдела".
В положении указываются общие принципы, стандарт процесса, документы... Это внутренняя организация.
"Методика работы отдела" - это (в моём понимании) документ, описывающий более глобальные схемы, возможно взаимодействие с заказчиком, описание работы отдела и взаимодействия с другими отделами. И в этом документе уже можно ссылку давать на "Положение о тестировании".
В иерархии документов приблизительно так:
1. Штатная структура и должностные обязанности отдела
2. Методика работы отдела
3. Положение о тестировании отдела
и далее вспомогательные документы
4. План тестирования
5. Стратегия тестирования (как часть плана тестирования, но более развёрнуто)
6. Шаблоны ...
и т.д.

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

Привет всем.
Столкнулся с проблемой - нужно описать методику работы отдела тестирования.
Есть наработки, но хотелось бы "классики", либо действительно полезных статей, мнений, идей.
Уважаемый ALL, поделитесь мнениями, как у вас описывается данный документ, что полезного и нужного нужно указать в нём?

Спасибо, Слав, что откликнулся.
По пунктам:
1. Отдел обслуживает несколько проектов.
2. Структура отдела - руководитель отдела, несколько руководителей групп тестирования, тестировщики. Как минимум, на 1 проект есть выделенный 1 тестировщик. На проект (или группу проектов) есть выделенный руководитель группы тестирования.
Есть также группа "захвата" быстрого реагирования. Создаётся из свободных тестировщиков для "аврального" тестирования.
В целом ситуация такая, что группа тестирования, состоящая из 1 постоянного тестировщика + 2-3 из свободных, тестируют некий проект.
Как только они заканчивают основной объём работа, что "свободные" переходят в другую группу, а постоянный продолжает работы.
3. Наружу не работаем.
4. В ответственность руководителя отдела входит HR функция.
5. Своего бюджета нет (всё делается через служебки)
6. Есть оклад, с него могут "срезать" за несвоевременное выполнение или некачественную работу. Бонусы только в виде 13й з.п.

Слав, спасибо. Теперь буду "вкуривать" и "рожать"

Как показывает практика - может.
Человек может быть отличным руководителем и ставить задачи подчинённым, но от it быть далеким.
Задача руководителя раскидать ресурсы по предоставленным планам и следить за исполнением проекта.
Также в его задачи входит "разруливание" проблем с заказчиком. Остальные проблемы он делегирует на компетентных подчинённых.
Хотя на мой взгляд, намного лучше, когда руководитель айтишник. Это позволяет ему видеть процессы не только снаружи, но и внутри. А следовательно, лучше контролировать процесс.

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

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

Так, в догонку...
Попробуйте использовать VS 2010, там есть хорошие средства для автоматизации веб-проектов (только HTTP протокол).
И эти же тесты прекрасно используются в нагрузочном тестировании.
В т.ч. хорошо тестируются проекты на SilverLight и можно тестировать веб-сервисы.

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

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

+1

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