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

[galogenIt]

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

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

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

А какое это имеет отношение к нашей беседе?

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

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

[elfische]

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

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

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

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

А какое это имеет отношение к нашей беседе?

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

[Фрося]

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

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

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

В чем польза?
Человек пробует себя в другой сфере. Он наверняка узнает что-то новое. У него появится несколько иной взгляд на конечный продукт. У него появятся ИДЕИ -- что можно улучшить, что изменить.
Не стоит боятся, что человек вообще уволится/попросится в саппорт. В конце концов -- всем надо развиваться и искать именно свое место (причем -- свое место это не навсегда, потому как человек меняется).
В конце концов это и тренировка умения меняться и подстраиваться (дальше может быть спич на тему -- Как ломались люди в перестройку). Что плюс для человека.

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

[galogenIt]

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

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

[barancev]

Эдуард, а что ваши тестировщики думают по этому поводу?

[Фрося]

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

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

Подумаю... напишу....
Для меня просто это очевидно.
Ну - -свойство характера.
Я к примеру -- документатор+тестировщик при авиационных блоках.

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

ПС.
До маразма смену деятельности доводить не надо. См. "Град обреченных" бр. Стругацких

[galogenIt]

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

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

[elfische]

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

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

[galogenIt]

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

Красиво сказали :)

[Freiman]

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

Может, дешевле и проще тогда отправить в техподддержку аналитика, чтоб он сразу учел детали и нюансы? :)
Потому как если эти детали и нюансы не зафиксированы, то программисты их не реализуют, или реализуют "антипользовательским" способом (типа "Command line - наше все!").
А затем тестировщик, который с этими нюансами вроде как знаком по работе в техподдержке, создает большое количество improvement request-ов, и получается еще куча фактически лишней работы и для программиста, и для тестировщика.

[elfische]

galogenIt, Вы пропустили один вопрос про мнение Ваших тестировщиков.

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

[Freiman]

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

не знаю. Может, и внедренец. Но в любом случае архиполезный человек

[Zhu]

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

баги до релиза - а смысл тогда внедрять тестера в техподдержку?)
особо важные я думаю итак отлавливаются до релизoв.
а если найдутся пользователи которые поломают вашу систему?

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

P.S.
может пропадать босс и до релиза и после

система регистраций может навернуться в любой момент, даже если работала идеально.

[elfische]

баги до релиза - а смысл тогда внедрять тестера в техподдержку?)

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

может пропадать босс и до релиза и после

система регистраций может навернуться в любой момент, даже если работала идеально.

Ок, понятно.

[galogenIt]

Эдуард, а что ваши тестировщики думают по этому поводу?

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

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

Да это так. Автоматизированное тестирование одно из генеральных направлений (по крайней мере было). Исследовательское тестирование производится. Достаточно регулярно. Мало или немало, не могу сказать. А как Вы определили по моим словам, что мало? А сколько надо?

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

[elfische]

Автоматизированное тестирование одно из генеральных направлений (по крайней мере было). Исследовательское тестирование производится. Достаточно регулярно. Мало или немало, не могу сказать. А как Вы определили по моим словам, что мало? А сколько надо?

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

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

[galogenIt]

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

Я видимо уже вечером писал на автопилоте:), коррекции внесены подчеркнутым.

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

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

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

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

[elfische]

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

Я видимо уже вечером писал на автопилоте:), коррекции внесены подчеркнутым.

:) То-то я никак не могла понять смысл этой фразы.

Правда не совсем понял, почему Вы решили, что нам не так уж важно качество продукта, и что мы совершенно не мотивированы на его улучшение. Может у нас разные понимания путей улучшения?

Наверно, неправильно выразилась. Хотела сказать, что это я слишком требовательна, а не что у вас что-то не так :)

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

И Вам спасибо за возможность пошевелить мозгами вне привычных рамок. Хотелось бы узнать, какое решение в итоге примете.

[barancev]

Эдуард, а что ваши тестировщики думают по этому поводу?

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

Мда, неудачно я задал вопрос, слишком двусмысленно :)
Я имел в виду:
1) согласны ли тестировщики с тем, что они действительно недостаточно хорошо понимают логику работы приложения и/или то, как клиенты используют приложение и с какими проблемами они сталкиваются,
2) могут ли они предложить какие-нибудь ещё способы устранения этого недостаточного понимания, помимо отправки "на передний край" службы технической поддержки?

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

[galogenIt]

Мда, неудачно я задал вопрос, слишком двусмысленно :)

Ну спасибо за интерес к теме :)

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

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

2) могут ли они предложить какие-нибудь ещё способы устранения этого недостаточного понимания, помимо отправки "на передний край" службы технической поддержки?

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

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

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

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

Альтернативы всегда есть. Отправка на стажировку исключена.

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

А как Вы себе это видите?

Почему только один вариант решения проблемы рассматривается?

В данном случае на форуме рассматривается именно вариант совмещения. Дабы оценить его возможности, а также рассмотреть варианты его реализации.

Работа техписом - да это вполне возможно. Я сам когда-то им работал и совершенно без каких-либо знаний предметной области. Однако могу сказать определенно, это не даст нужного эффекта. Проблема-то не в том, в какой последовательности и какие кнопочки нажимать. Пробле6ма в том, будет ли такая последовательность разумной.

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