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

[galogenIt]

Добрый вечер, участники форума.
Искал куда разместить сообщение, подумал, что в управление тестированием вполне подойдет.

У руководства возникло предложение привлечь сотрудников отдела тестирования к работе в службе сопровождения (горячей линии).
Цели (по заявлению руководства):
1. более глубокое погружение тестировщика в предметную область, развитие у него "здравого смысла заказчика"
2. личностный рост тестировщика за счет более глубокого проникновения в предметную область, а следовательно приобретение шансов переквалифицироваться в иные виды деятельности (например аналитическую)
3. более гибкое перераспределение нагрузки между сотрудниками особенно на время отпусков.

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

Кто-то может что-то сказать по этому поводу? Следует ли соглашаться или, наоборот, не соглашаться? Типичная ли это практика?

Еще хотелось выяснить кто осуществляет приемочное тестирование? Автор постановки задачи или тестировщик?

[ekaterina.zhulkova]

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

Глубокое ИМХО (как бы сделала я) - либо на это дело надо выделять одного конкретного человека, который изучит, как же надо делать саппорт и просто будет им заниматься по мере надобности (причем ему об этом заранее заявят и введут в его обязанности), либо не делать вообще никак.
Объясню свою позицию - если ссылать в саппорт разных людей по запросу, то
а) демотивирует людей - реально будет восприниматься как "ссылка", ибо работа не по профилю
б) снижает уровень поддержки и добавит стресса сотрудникам - как ни крути, работа инженером по качеству не требует общения с пользователями, не обучает корректному написанию писем заказчикам и т.п.

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

>> Типичная ли это практика?
Думаю, достаточно распространенная, особенно в небольших компаниях, но от этого дополнительных плюсов такому подходу не добавляется.
Хотя, конечно, у каждой компании свои особенности. Возможно, в вашем случае это вполне адекватное и допустимое решение. Это зависит от многих факторов.

>> Еще хотелось выяснить кто осуществляет приемочное тестирование? Автор постановки задачи или тестировщик?
Это уже совсем другая тема на отдельную ветку :)

[Freiman]

Всю свою тестерскую карьеру помогаю техподдержке - и надо сказать, это очень-очень помогает.
На взаимодействие с саппортом трачу от 1 до 3 часов ежедневно, обычно это в самом начале дня, когда остаются письма за предыдущий день, и в конце рабочего дня, когда разбирается часть сегодняшних писем. Так как тестировщиков на проекте всего 3, то выделять кого-то на целый день у нас нецелесообразно, а вот тратить один-два часа рабочего времени одного-двух человек - вполне нормально, я считаю.
К тому же это позволяет отвлечься от рутины, немного отдохнуть от непосредственного поиска ошибок, и иногда даже развлечься :)

Зачем вообще надо тестировщикам лезть к клиентам?
Во-первых, сообщения об ошибках. Они будут всегда, потому что продукта без багов нет. Задача тестировщика - из клиентского запроса вида "ваш продукт не работает!" сделать качественное сообщение об ошибке, а может даже и не одной. Плюс к этому нужно предложить вариант решения проблемы в данных обстоятельствах.
Во-вторых, жалобы на нестабильную (частый error 503, к примеру) или медленную работу, особенно важно это для веб-продуктов и серверных решений. Это не функциональные ошибки, но еле-еле шевелящийся сервер будет раздражать сильнее, чем неработающая фича, так как касается 100% клиентов.
В-третьих, это вопросы клиентов "А как сделать вот это и вот это?". Тут стоит подумать об оптимизации интерфейса - если клиенты не знают, как пользоваться вашим продуктом, то что-то в интерфейсе не так.
Если в продукте обнаружился баг, который мешает пользователю выполнить задачу, то тестировщику придется включить смекалку и проявить знание всех скрытых возможностей своего софта: клиенту надо предложить workaround, с помощью которого пользователь все же сможет делать то, что ему нужно, причем максимально удобно в данных обстоятельствах.
И конечно, клиенты придумывают сотни и тысячи нестандартных вариантов использования вашего продукта :) Такие use case-ы также могут указать не недостаточно протестированные участки.

Зачем тестировщики нужны команде техподдержки?
Тут можно вспомнить про правило 20/80 :)
Большинство писем однотипны, и для их ответа можно пользоваться даже готовыми шаблонами. Зато оставшиеся 20% писем пожирают 80% времени техподдержки и все время тестировщика, выделенное на поддержку техподдержки :)
Техсаппорт хорошо разбирается в продукте на уровне пользователя, знает все фичи-кнопки-чекбоксы-API, но есть случаи, когда знаний сотрудников техподдержки может не хватать. Это, например, проблемы, описываемые впервые - тестировщик по роду своей деятельности постоянно сталкивается с проблемами в продукте, поэтому он быстрее и точнее определит причину и сможет подсказать решение. Если проблема в продукте - то заводится баг, если проблема в окружении и в нашем продукте это никак не решить - то решение во всех подробностях объясняется техподдержке, и создается новый шаблон :)
Еще частый вопрос, с которым обращается техподдержка - а будет ли работать наш продукт вот с таким нестандартным окружением, взаимодействовать через этот протокол, дружить с параноидальным файрволом, а можно ли результаты работы вашего продукта загрузить на сайт, заембеддить в Flex application, распространять на DVD, загрузить на ютуб... Потребности (и фантазии людей в части совмещения несовместимого) крайне разнообразны, и весь этот "compatibility" testing также хорошо знаком тестировщикам.

[Freiman]

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

может, я нестандартный инженер по тестированию, но мне нравится читать письма от клиентов, решать их проблемы с нашим продуктом через remote desktop, иногда даже говорить по телефону (но только с русскоязычными, правда :( )

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

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

>> Типичная ли это практика?
Думаю, достаточно распространенная, особенно в небольших компаниях, но от этого дополнительных плюсов такому подходу не добавляется.
Хотя, конечно, у каждой компании свои особенности. Возможно, в вашем случае это вполне адекватное и допустимое решение. Это зависит от многих факторов.

Отправка тестировщика в саппорт - ИМХО, нетипичная. Редирект некоторых запросов от клиентов к тестировщикам - очень частая.

[Wolonter]

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

Очень согласен с этой мыслью. Как там? Или крестик снимите или трусы наденьте. Берите в саппорт еще одного, если мало, увольте тестировщика, если лишний.

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

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

[galogenIt]

Спасибо за ответ коллеги.

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

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

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

[Freiman]

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

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

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

[elfische]

Если ещё нужно, вот моё мнение (о чём ещё не говорили).

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

Хорошенько подумайте, во что такое совмещение может вылиться именно в Вашей компании.

[Vasiliy]

У нас на предыдущем месте работы отдел тестирования использовался в качестве 2-го уровня техподдержки. То есть все небольшие замечания техподдержка могла решить сама (они проходили практику в отделе тестирования на испытательном сроке), а сложные/долгие задачи пересылались к тестировщикам. Ну или, например, в отделе поддержки не было такого оборудования для экспериментов просто.
У тестировщиков такие запросы обычно передавались эксперту. Он разбирался с вопросом и писал ответ в службу техподдержки, а не напрямую клиенту. С клиентами общался только один отдел.

[ekaterina.zhulkova]

Работа "на горячей линии" (как написал автор) и работа на подхвате у саппорта - это, на мой взгляд, разные вещи. Второе - когда воспроизводить баги, которые появились у клиентов - это всегда делается. И это действительно ценный опыт, соглашусь полностью.

[galogenIt]

Если ещё нужно, вот моё мнение (о чём ещё не говорили).

Конечно нужно

Хорошенько подумайте, во что такое совмещение может вылиться именно в Вашей компании.

Не совсем понял, вы одобряете или порицаете такое объединение?

У нас на предыдущем месте работы отдел тестирования использовался в качестве 2-го уровня техподдержки. То есть все небольшие замечания техподдержка могла решить сама (они проходили практику в отделе тестирования на испытательном сроке), а сложные/долгие задачи пересылались к тестировщикам. Ну или, например, в отделе поддержки не было такого оборудования для экспериментов просто.
У тестировщиков такие запросы обычно передавались эксперту. Он разбирался с вопросом и писал ответ в службу техподдержки, а не напрямую клиенту. С клиентами общался только один отдел.

Ага, интересно, т.е. отдел тестирования стоял на второй волне фильтрации, т.е. получал список входящих работ от саппорта. но не работал в саппорте непосредствено?

Работа "на горячей линии" (как написал автор) и работа на подхвате у саппорта - это, на мой взгляд, разные вещи. Второе - когда воспроизводить баги, которые появились у клиентов - это всегда делается. И это действительно ценный опыт, соглашусь полностью.

Екатерина, а что вы имеет в виду по "работа на подхвате у саппорта"? Как я понимаю это вы одобряете?

[elfische]

Не совсем понял, вы одобряете или порицаете такое объединение?

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

Ага, интересно, т.е. отдел тестирования стоял на второй волне фильтрации, т.е. получал список входящих работ от саппорта. но не работал в саппорте непосредствено?

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

[galogenIt]

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

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

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

[elfische]

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

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

Если бы не последнее предложение! Теперь буду чувствовать, что я Вас склоняю не делать этого. Ведь сама считаю, что это плохо. Ух сейчас как выложу!

Не зря придумали разделение труда. Если очень хочется, можно устроить стажировку в поддержке, но временно. В чём плюс, уже сказали: расширение кругозора во вред быть не может. Минус (и очень жирный): работники (не только тестировщики) начинают зацикливаться на хотелках. Соответственно кругозор сужается в точку. Что вредно особенно для тестировщика. Этот минус я осознала только что на собственном опыте. Когда работаешь без документации в режиме постоянного аврала, очень тяжело противиться давлению и широко мыслить (вот только что забыла, что один из продуктов не подчиняется общему правилу тестирования только на фаерфоксе). Тестировщик обязан находить и фиксировать все баги. Работа менеджера (так понимаю из ветки про приёмочное, у вас это те люди, которые ставят задачи) решать, что из этого будет исправлено срочно, а что не исправлено вовсе.
Однако в реальности всё намного запутаннее и сложнее. Хорошо, когда тестировщик может (и у него есть на то право) принимать менеджерские решения. Проще говоря, думать во время работы, а не выискивать баги абы где. Для этого можно, например, озаботить человека тест-дизайном. В самом простом варианте -- это составление чек-листов. Можно улучшить взаимодействие с отделом аналитики (банальный совместный обед иногда столько ценной информации приносит!). Хотела написать ещё варианты, но уже забыла, а бежать уже нужно. Может, позже вспомню.

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

[elfische]

Ах да. У нас даже разработчики не очень раньше понимали, что важно, а что не очень. Но они же не работали в техподдержке! Но получали информацию о косяках, что дало свои результаты.

[Vasiliy]

Ага, интересно, т.е. отдел тестирования стоял на второй волне фильтрации, т.е. получал список входящих работ от саппорта. но не работал в саппорте непосредствено?

Да, именно так.
Своей работы хватало - зачем еще чужой загружать?

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

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

[galogenIt]

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

Согласен, спасибо за аргументацию :)

Насчет протаскивания "через огонь службы поддержки". А пользователи что объясняют свой бизнес когда обращаются в поддержку? Они наверняка напишут: "Нажал туда-то - сломалось". Нужда ясна - почините. Бизнес процессов здесь может и не быть.
И еще - общение с пользователями - это отдельный склад характера, все-таки. Кому-то нравится, а кому-то и нет...

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

[Фрося]

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

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

хм... ну нужды заказчика тестировщик может и не поймет. Но четко осознает -- что его работа нужна и важна.
Что есть пользователи, реальные. Которым реально что-то нужно. В какой-то степени осознание, что выпускается не некий отвлеченный продукт. А делается нечто для конкретной пользы конкретных людей.

Как аналогия. В театре есть продукт - спектакль. Участникам спектакля (всем!Не только актерам, но и костюмерам, и декораторам) нужно знать и видеть реакцию зрителя? Хотя бы изредка?
На мой взгляд - нужно. Вот платье героини -- вроде и режиссер счел, что классное, и актрисе нравится... а в зале -- кхеканье...
А тех. поддержка - это реальная реакция пользователя. Этакие выкрики из зала или свистки.....
На мой взгляд -- чутка побыть в техподдержке полезно!

[Freiman]

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

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

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

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

[Freiman]

Упс, сообщение продублировалось

Сообщение отредактировал Freiman: 06 июля 2011 - 13:24