Перейти к содержимому

Фотография

Совмещение обязанностей


  • Авторизуйтесь для ответа в теме
Сообщений в теме: 66

#21 galogenIt

galogenIt

    Постоянный участник

  • Members
  • PipPipPip
  • 192 сообщений
  • ФИО:Эдуард

Отправлено 06 июля 2011 - 13:38

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

На мой взгляд -- чутка побыть в техподдержке полезно!

Ну это у нас все и так осознают. А в чем польза?


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

Вот с этим поспорить трудно, хотя есть наблюдение, аналитик все рано смотрит на детище кончтруктивно, тестировщик деструктивно, если его не давить :)
  • 0
С уважением, Эдуард!

#22 ShortLegged

ShortLegged

    Постоянный участник

  • Members
  • PipPipPip
  • 155 сообщений
  • Город:Moscow

Отправлено 06 июля 2011 - 13:46

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

#23 Zhu

Zhu

    Опытный участник

  • Members
  • PipPipPipPip
  • 288 сообщений
  • ФИО:Рина Ужевко
  • Город:Москва


Отправлено 06 июля 2011 - 14:51

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

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

Поэтому я только "за" таких внедрений)
  • 0
Bugs@Feature
Не бывает совершенных программ, бывают недотестированные.

#24 galogenIt

galogenIt

    Постоянный участник

  • Members
  • PipPipPip
  • 192 сообщений
  • ФИО:Эдуард

Отправлено 06 июля 2011 - 17:18

Zhu, Вашу мысль я услышал.

Заметьте разницу: "руковожу отделами", и представитель одного отдела совмещает работу в другом. По сути у Вас один отдел. Существует ли у Вас специализация? Как она организована, каковы обязанности тестировщика и специалиста поддержки, как обязанности совмещаются? Сколько человек?

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

Однако в чем конкретная выгода на Ваш взгляд? Почему ее не получить из анализа ежедневных работ, списка обращений?
  • 0
С уважением, Эдуард!

#25 Vasiliy

Vasiliy

    Профессионал

  • Members
  • PipPipPipPipPipPip
  • 2 959 сообщений
  • ФИО:Касимов Василий
  • Город:Москва

Отправлено 06 июля 2011 - 18:30

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

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

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

Сообщение отредактировал Vasiliy: 07 июля 2011 - 07:51

  • 0

#26 galogenIt

galogenIt

    Постоянный участник

  • Members
  • PipPipPip
  • 192 сообщений
  • ФИО:Эдуард

Отправлено 07 июля 2011 - 04:10

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

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

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

Почему-то эта идея - т.е. периодические отчеты, расстановка приоритетов и т.п. штучки у нас не приветствуются. Преподалагается, что тестировщики сами должны делать такие отчеты(впрочем наверное это не сложно, если есть система учета обращений), сами расставлять нужные приоритеты. Каким образом - а путем превращения тестировщика в аналитика со специализацией тестировщика. Т.е. если тестировщик будет одновременно и аналитиком, то он естественным образом будет понимать и приоритеты, и слабые места системы. Как такая идея?
  • 0
С уважением, Эдуард!

#27 Vasiliy

Vasiliy

    Профессионал

  • Members
  • PipPipPipPipPipPip
  • 2 959 сообщений
  • ФИО:Касимов Василий
  • Город:Москва

Отправлено 07 июля 2011 - 07:54

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

Странно для меня это.
А если сделать тестировщика еще и разработчиком, то он и код сам писать будет. И тестировать сразу же. Чем не мастер на все руки?)
  • 0

#28 elfische

elfische

    Постоянный участник

  • Members
  • PipPipPip
  • 186 сообщений
  • ФИО:Андреева Татьяна
  • Город:Казань


Отправлено 07 июля 2011 - 08:09

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

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

Я не понимаю, как тестировщики должны составлять отчёты о багах, которые находят пользователи, если они ещё не работают с пользователями? Или что-то не так поняла?
Поддреживаю Василия в разделении труда. Хотя! по ходу своей работы тестировщики могут генерировать много интересной информации (в том числе и запросов всяких). Главное, чтобы она была полезной для управленцев.

Вопрос. А за какое время менеджеры планируют перевести отдел тестирования на новый режим работы? Есть ли возможность испробовать "демо": на ком-то одном или на каком-то небольшом промежутке времени? Чтобы оценить реальное положение дел именно у вас, а не на основе опыта других людей.
  • 0

#29 galogenIt

galogenIt

    Постоянный участник

  • Members
  • PipPipPip
  • 192 сообщений
  • ФИО:Эдуард

Отправлено 07 июля 2011 - 10:17

Странно для меня это.
А если сделать тестировщика еще и разработчиком, то он и код сам писать будет. И тестировать сразу же. Чем не мастер на все руки?)

Я тоже задался этим вопросом. Но если отбросить факт разработки:) А только остановится в рамках анализа, реально в чем разница между тесировщиком и аналитиком?

Например есть такой аргумент:
аналитик получает больше, соответственно более дорогой ресурс,
тестировщик тоже должен понимать предметку и явно не хуже аналитика
  • 0
С уважением, Эдуард!

#30 galogenIt

galogenIt

    Постоянный участник

  • Members
  • PipPipPip
  • 192 сообщений
  • ФИО:Эдуард

Отправлено 07 июля 2011 - 10:32

Я не понимаю, как тестировщики должны составлять отчёты о багах, которые находят пользователи, если они ещё не работают с пользователями? Или что-то не так поняла?

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

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

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

Вопрос. А за какое время менеджеры планируют перевести отдел тестирования на новый режим работы? Есть ли возможность испробовать "демо": на ком-то одном или на каком-то небольшом промежутке времени? Чтобы оценить реальное положение дел именно у вас, а не на основе опыта других людей.

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

А причина - недовольство тем, что тестирровщик порою уделяет слишком много внимания системным ошибкам, техническим деталям в противовес к бизнес аспектам и логике использования.
  • 0
С уважением, Эдуард!

#31 Vasiliy

Vasiliy

    Профессионал

  • Members
  • PipPipPipPipPipPip
  • 2 959 сообщений
  • ФИО:Касимов Василий
  • Город:Москва

Отправлено 07 июля 2011 - 10:38

Я тоже задался этим вопросом. Но если отбросить факт разработки:) А только остановится в рамках анализа, реально в чем разница между тесировщиком и аналитиком?

Например есть такой аргумент:
аналитик получает больше, соответственно более дорогой ресурс,
тестировщик тоже должен понимать предметку и явно не хуже аналитика

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

Предлагаю не примешивать сюда зарплаты. А то получается, что как-только тестировщик начнет понимать предметную область не хуже аналитика - ему сразу же поднимут зарплату.
  • 0

#32 Vasiliy

Vasiliy

    Профессионал

  • Members
  • PipPipPipPipPipPip
  • 2 959 сообщений
  • ФИО:Касимов Василий
  • Город:Москва

Отправлено 07 июля 2011 - 10:43

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

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

#33 Zhu

Zhu

    Опытный участник

  • Members
  • PipPipPipPip
  • 288 сообщений
  • ФИО:Рина Ужевко
  • Город:Москва


Отправлено 07 июля 2011 - 10:47

Zhu, Вашу мысль я услышал.

Заметьте разницу: "руковожу отделами", и представитель одного отдела совмещает работу в другом. По сути у Вас один отдел. Существует ли у Вас специализация? Как она организована, каковы обязанности тестировщика и специалиста поддержки, как обязанности совмещаются? Сколько человек?

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

Однако в чем конкретная выгода на Ваш взгляд? Почему ее не получить из анализа ежедневных работ, списка обращений?


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

единственное,что мне упрощает (иногда усложняет)жизнь - у нас нет тест-кейсов. Ибо на написание их времени нет. Юзаю чек-листы максимально упрощенного варианта.
я занята в двух проектах, один из которых имеет клиентскую версию, браузерную, и 4-5 социальных.
второй проект - имеет версию социальную и глобальные планы ...он в стадии разработки.

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

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

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

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

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

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

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

тут можно продолжать бесконечно.

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

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


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


но тут как бы все сказанное тоже спорно
кому-то может это не подходит.
также зависит от того, кто с какими проектами еще работает.
может кто-то работает в команде там тестировщиков 200 и техподдержки человек стопицот и пр. нюансы.

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

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

ну вот пока что вот так работаем)
  • 0
Bugs@Feature
Не бывает совершенных программ, бывают недотестированные.

#34 galogenIt

galogenIt

    Постоянный участник

  • Members
  • PipPipPip
  • 192 сообщений
  • ФИО:Эдуард

Отправлено 07 июля 2011 - 13:04

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

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

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

Как важный момент - тестиовщик просто уйдет из тестирования в анализ


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

Да интересная мысль!
  • 0
С уважением, Эдуард!

#35 galogenIt

galogenIt

    Постоянный участник

  • Members
  • PipPipPip
  • 192 сообщений
  • ФИО:Эдуард

Отправлено 07 июля 2011 - 13:11

Спасибо, Zhu. Очень интересно, но видимо мало применимо к нам.
У нас тяжеленное корпоративное решение, с гигантским количеством функционала, параметризации и настроек, в результате количество возможных комбинаций мгновенное уходит в бескончность. + жесткая ответственность перед бизнесом. Потому у нас и есть разделение.

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

#36 Zhu

Zhu

    Опытный участник

  • Members
  • PipPipPipPip
  • 288 сообщений
  • ФИО:Рина Ужевко
  • Город:Москва


Отправлено 07 июля 2011 - 13:16


Спасибо, Zhu. Очень интересно, но видимо мало применимо к нам.
У нас тяжеленное корпоративное решение, с гигантским количеством функционала, параметризации и настроек, в результате количество возможных комбинаций мгновенное уходит в бескончность. + жесткая ответственность перед бизнесом. Потому у нас и есть разделение.

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



в вашем случае - я бы выделила 1-2 человек, которые будут совмещать.
тесное сотрудничество может принести больше проблем и недопонимания, нежели пользы.
поэтому одного вот такого "посла" между отделами - я бы рекомендовала сделать.
Понятно что совмещать сложно, просто разгрузите его немного в тестировании, перекиньте на других, а на него свесьте немного техподдержки.
Но тут надо быть весьма осторожным, ибо грань хрупкая, чтоб у вас тестировщик просто не переквалифицировался в саппорта =)
  • 0
Bugs@Feature
Не бывает совершенных программ, бывают недотестированные.

#37 Vasiliy

Vasiliy

    Профессионал

  • Members
  • PipPipPipPipPipPip
  • 2 959 сообщений
  • ФИО:Касимов Василий
  • Город:Москва

Отправлено 07 июля 2011 - 14:07

Как важный момент - тестиовщик просто уйдет из тестирования в анализ

Это укладывается в вашу цель?
  • 0

#38 galogenIt

galogenIt

    Постоянный участник

  • Members
  • PipPipPip
  • 192 сообщений
  • ФИО:Эдуард

Отправлено 07 июля 2011 - 14:14


Как важный момент - тестиовщик просто уйдет из тестирования в анализ

Это укладывается в вашу цель?

В мою нет, в цель компании может быть. Тестирование трамплин для карьерного роста и инструмент снижения затрат на подготовку аналитика и выполнения части аналитической работы
  • 0
С уважением, Эдуард!

#39 elfische

elfische

    Постоянный участник

  • Members
  • PipPipPip
  • 186 сообщений
  • ФИО:Андреева Татьяна
  • Город:Казань


Отправлено 07 июля 2011 - 16:48

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

А почему он это делает?

Как важный момент - тестиовщик просто уйдет из тестирования в анализ

Наши рядовые аналитики получают по моей информации примерно так же, как и тестировщки. А вот ценные аналитики... Там такой опыт и такие знания, что вполне понятно, за что им платят деньги. Другое дело, что, по моей же информации, рядовые программисты получают больше тестировщиков. Откуда растут ноги у таких явлений?
  • 0

#40 elfische

elfische

    Постоянный участник

  • Members
  • PipPipPip
  • 186 сообщений
  • ФИО:Андреева Татьяна
  • Город:Казань


Отправлено 07 июля 2011 - 16:59

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

...

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

Что-то мне кажется, это два неравнозначных примера. Пропадание босса не относится к тому, что может быть протестировано заранее (если нет, то спишем это на моё непонимание контекста). А вот проблемы с регистрацией очень даже могут быть найдены до заливки версии на боевой сервер (или же у вас не такая система регистрации, как представляется мне).
Как мне кажется, конечная цель менеджеров galogenIt -- отловить все особо важные баги до релиза, потому что они, найденные пользователями, стоят гораздо больше (возможно потому, что не могут быть быстро починены).
  • 0


Количество пользователей, читающих эту тему: 0

0 пользователей, 0 гостей, 0 анонимных