Красиво сказали :)Что-то я перестала видеть Вашу собственную точку зрения. Пожалуй, пока остановлюсь в дальнейшем выуживании информации, мои мысли зашли в тупик собственного контекста.
- Форум тестировщиков
- → Публикации galogenIt
64 публикаций создано galogenIt (учитываются публикации только с 29 апреля 2023)
Отправлено автор: galogenIt 08 июля 2011 - 08:44 в Управление тестированием
Красиво сказали :)Что-то я перестала видеть Вашу собственную точку зрения. Пожалуй, пока остановлюсь в дальнейшем выуживании информации, мои мысли зашли в тупик собственного контекста.
Отправлено автор: galogenIt 08 июля 2011 - 07:45 в Управление тестированием
В начале дискуссия я их понимал как: "отсутствие здравого смысла заказчика". Далее возникло понятие: тестировщик должен выполнять приемочное тестирование, т.е. есть автор работы - скажем аналитик. Обычно он и проверяет исполнение работы, однако на аналитика высока нагрузка и нужно переложить эту работу на тестировщика. Казалось что проще, есть требования - читаем и проверяем. Но тут дело в том, что есть скорее общая постановка, детали и нюансы скрыты или не зафиксированы, потому. чтобы тестировщик мог принимать работу ему нужно быть в бизнес-контексте, который он может получить например работая на службе поддержки, решая конкретные проблемы пользователя, он постигнет нужную глубину бизнес-контекста и такми образму сумеет принять работу без наличия нужных деталей, т.е. просто поймет вычислит ихЯ куда клоню. Менеджер видит проблему в каком-то факте. Трактует этот факт по-своему и предлагает решение, основанное на этой трактовке. Факт мы знаем (нахождение не тех багов, которые бы хотелось найти в первую очередь), но у этого факта тоже есть свои причины. Возможно, менеджер придумал себе причину, которая на самом дере нереальна. Отсюда и предложенное решение, которое Вам не нравится. Хорошо, если мои слова не подходят для вашей ситуации, но если нет? Вот я и хочу докопаться до причины факта, побудившего затеять такие перемены.
Отправлено автор: galogenIt 08 июля 2011 - 07:22 в Управление тестированием
Т.е. плюсы для бизнеса (идеи и новый взгляд), плюсы для человека (понять - где твое место, тренинг адаптируемости, расширение сознания).
Ну и эмоциональная составляющая (см. пример с театром).
Отправлено автор: galogenIt 07 июля 2011 - 18:48 в Управление тестированием
Это я привел возможную причину, выведенную из аргументов извне. Я полагаю, что такова была стратегия до текущего момента. Так же можно предположить, это связано с определенной неопытностью ...А почему он это делает?
А какое это имеет отношение к нашей беседе?Наши рядовые аналитики получают по моей информации примерно так же, как и тестировщки. А вот ценные аналитики... Там такой опыт и такие знания, что вполне понятно, за что им платят деньги. Другое дело, что, по моей же информации, рядовые программисты получают больше тестировщиков. Откуда растут ноги у таких явлений?
Да я с Вами согласен. Вопрос разногласия, что считать важным багом. Однако это тема иной дискуссии. В рамках этой могу добавить, что, предположительно, именно работа в службе поддержки должна помочь тестировщику приобрести способность понимания особо важного бага.Как мне кажется, конечная цель менеджеров galogenIt -- отловить все особо важные баги до релиза, потому что они, найденные пользователями, стоят гораздо больше (возможно потому, что не могут быть быстро починены).
Отправлено автор: galogenIt 08 июля 2011 - 19:56 в Управление тестированием
Вообще мы этот аспект пока не обсуждали. Я лишь сделал анонимный опрос о том, будет ли полезным такое совмещение. В целом сказали, что это было бы полезным, но не в форме ежедневных дежурств. В принципе я сам провожу анализ поступающих инцидентов на протяжении нескольких месяцев. У нас сначала был поток работ, по которым нужен тест (все у кто считал что это важно могли пометить работу таким признаком), но потом я стал анализировать работы, поступающие в течение дня и сам определял, что с ними делать. Сейчас у нас появилась система "мантис", которая позволяет не только активнее участвовать в поддержке, но и делать анализ поступающих инцидентов с ретроспективой и привязкой к тем или иным разрезам. У меня создалось впечатление, что этого было бы вполне достаточно: а/быть на второй линии, б/постоянно мониторить инциденты.Эдуард, а что ваши тестировщики думают по этому поводу?
Я, наконец, осознала, что там происходит. Люди занимаются в основном автоматизированным тестированием. Исследовательским тоже, но мало. Посему, у них нет общей картины по работе системы в целом. Мне кажется, надо провести полный цикл ручного тестирования, проходя по всем веткам бизнес-процесса. Иначе, даже посидев в техподдержке, будет кусочное представление о проекте, только какие-то кусочки станут более важными.
Отправлено автор: galogenIt 09 июля 2011 - 18:38 в Управление тестированием
Я видимо уже вечером писал на автопилоте:), коррекции внесены подчеркнутым....У нас очень сложные бизнес-процессы. Мне кажется общее представление о них у нас как раз
нетесть, а вот некоторых важных деталей, особенно на стыке задач, вполне возможно и недостаточное
Татьяна, спасибо за попытку объяснить свою точку зрения. Она понятна. Правда не совсем понял, почему Вы решили, что нам не так уж важно качество продукта, и что мы совершенно не мотивированы на его улучшение. Может у нас разные понимания путей улучшения?Сейчас попыталась зайти с другой стороны к вопросу. А так ли хорошо моё предложение? Чувствую, что-то упустила.
У меня была личная заинтересованность в качестве продукта: я доставала всех людей, которых только могла, чтобы выяснить зачем и почему работает вот эта фишечка. Мне хочется выполнять свою работу как можно лучше, потому знаю не всё, но очень много (в плане аналитики и важности функций). Кажется, забыла, что бывают и нормальные люди.
Теперь начинаю думать об исходном предложении иначе. Т.е. очевидно, что информация от техподдержки должна поступать тестировщикам. Но будут ли они через себя пропускать простые отчёты о самых важных функциях? Ведь сидя в техподдержке, информация пройдёт через них гарантированно. Только вот столько времени будет убито на обработку лишней информации.
Отправлено автор: galogenIt 15 июля 2011 - 07:18 в Управление тестированием
А в чем параллелность?да то, что автоматизированное тестироване это несколько иная -параллельная вселенная- (для меня)
отличная от ручного тестирования.
суть не меняется, но коррективы и детали внести надобно)
Отправлено автор: galogenIt 14 июля 2011 - 09:20 в Управление тестированием
Отправлено автор: galogenIt 12 июля 2011 - 16:56 в Управление тестированием
Я, наконец, осознала, что там происходит. Люди занимаются в основном автоматизированным тестированием. Исследовательским тоже, но мало. Посему, у них нет общей картины по работе системы в целом. Мне кажется, надо провести полный цикл ручного тестирования, проходя по всем веткам бизнес-процесса. Иначе, даже посидев в техподдержке, будет кусочное представление о проекте, только какие-то кусочки станут более важными.
о_О
тогда многое проясняется конечно ))))
а я то голову ломала))))
Отправлено автор: galogenIt 10 июля 2011 - 15:22 в Управление тестированием
Ну спасибо за интерес к теме :)Мда, неудачно я задал вопрос, слишком двусмысленно :)
Думаю, да. Причем скорее именно так: недостаточно хорошо понимают бизнес с высоты птичьего полета. Есть достаточно хорошее понимание отдельных частей работы приложения (слишком уже большое приложение, чтобы понимать его логику досконально во всем). Другие понимаются хуже, особенно те, которые слабо документированы, да и не слишком интенсивно используются клиентами. Резюме: наверное, нет целостного восприятия, есть хорошее иногда даже глубокое понимание каких-то тонкостей (например, применение различных особых финансовых условий), вместе с тем, могут быть провалы в знаниях (например условиях попадания в какую-то отчетность тех или иных данных)Я имел в виду:
1) согласны ли тестировщики с тем, что они действительно недостаточно хорошо понимают логику работы приложения и/или то, как клиенты используют приложение и с какими проблемами они сталкиваются,
Пока вопрос отправки "на передний край" службы технической поддержки не решен. По мнению товарищей из отдела аналитики - да, поскольку, таким образом, они прогоняют всех своих сотрудников. Это по их мнению дает "здравый смысл заказчика", причем наиболее быстро и полезно для компании и человека.2) могут ли они предложить какие-нибудь ещё способы устранения этого недостаточного понимания, помимо отправки "на передний край" службы технической поддержки?
Мне, кажется, что дежурства действительно не дадут нужного эффекта. Однако работа вторым фронтом на поддержке, по мнению руководства не даст нужного эффекта. По-видимому, альтернативой может быть двух-трех недельная работа одного из сотрудника группы тестирования, чья специализация лежит в области тест-анализа и тест-проектирования.Если их просто отправить в техсаппорт на подработку -- они погрязнут в рутине и текучке, которой там ещё больше, чем в тестировании. И вовсе не факт, что это сформирует у них целостную картину -- акцент будет исключительно на проблемных местах.
Есть ли иные альтернативы? Например, отправить на стажировку непосредственно к клиенту, чтобы он там наблюдал за всем, что и как они делают.
Или, действительно, на время сделать их аналитиками, а может быть техническими писателями.
В данном случае на форуме рассматривается именно вариант совмещения. Дабы оценить его возможности, а также рассмотреть варианты его реализации.Почему только один вариант решения проблемы рассматривается?
Отправлено автор: galogenIt 05 июля 2011 - 19:31 в Управление тестированием
Отправлено автор: galogenIt 07 июля 2011 - 14:14 в Управление тестированием
В мою нет, в цель компании может быть. Тестирование трамплин для карьерного роста и инструмент снижения затрат на подготовку аналитика и выполнения части аналитической работыЭто укладывается в вашу цель?
Как важный момент - тестиовщик просто уйдет из тестирования в анализ
Отправлено автор: galogenIt 06 июля 2011 - 12:50 в Управление тестированием
Согласен, спасибо за аргументацию :)Вывод. Я считаю, что в Вашей ситуации, решение предложенное Вами же (про приоритезацию целей от релиза к релизу), более рационально. Так как дополнительные функции могут привести к рассеянному вниманию и излишней концентрации на мелочах.
Тут весь прикол, что реально тестировщик с пользователем не будет общаться, ну для начала не доверят :) А во-вторых - общаться будет с баг-трекером ...Насчет протаскивания "через огонь службы поддержки". А пользователи что объясняют свой бизнес когда обращаются в поддержку? Они наверняка напишут: "Нажал туда-то - сломалось". Нужда ясна - почините. Бизнес процессов здесь может и не быть.
И еще - общение с пользователями - это отдельный склад характера, все-таки. Кому-то нравится, а кому-то и нет...
Отправлено автор: galogenIt 06 июля 2011 - 11:37 в Управление тестированием
Насколько я понял свое руководство, цель внедрения тестировщиков в работу службы сопровождения вовсе не закрыть дыру поддержки, а в первую голову поднять уровень пони мания системы тестировщиками. Причем не с точки зрения устройства, а с точки зрения бизнес-контекста.У нас что-то похожее. Только получается уже третий уровень. Есть диспетчер, который отвечает на звонки и действует в соответствии с шаблонами, поступающими от нас. Следующий уровень -- внедренцы. Они часто по совместительству и аналитики: добывают требования. Уже смыслят в базах данных, отчётах, проводят срочные проверки каких-либо функций. Если от пользователей сыпятся сообщения, причину которых внедренец понять не в состоянии (либо же некогда выяснять), эти сообщения направляются на тестировщиков.
Отправлено автор: galogenIt 06 июля 2011 - 10:16 в Управление тестированием
Конечно нужноЕсли ещё нужно, вот моё мнение (о чём ещё не говорили).
Не совсем понял, вы одобряете или порицаете такое объединение?Хорошенько подумайте, во что такое совмещение может вылиться именно в Вашей компании.
Ага, интересно, т.е. отдел тестирования стоял на второй волне фильтрации, т.е. получал список входящих работ от саппорта. но не работал в саппорте непосредствено?У нас на предыдущем месте работы отдел тестирования использовался в качестве 2-го уровня техподдержки. То есть все небольшие замечания техподдержка могла решить сама (они проходили практику в отделе тестирования на испытательном сроке), а сложные/долгие задачи пересылались к тестировщикам. Ну или, например, в отделе поддержки не было такого оборудования для экспериментов просто.
У тестировщиков такие запросы обычно передавались эксперту. Он разбирался с вопросом и писал ответ в службу техподдержки, а не напрямую клиенту. С клиентами общался только один отдел.
Екатерина, а что вы имеет в виду по "работа на подхвате у саппорта"? Как я понимаю это вы одобряете?Работа "на горячей линии" (как написал автор) и работа на подхвате у саппорта - это, на мой взгляд, разные вещи. Второе - когда воспроизводить баги, которые появились у клиентов - это всегда делается. И это действительно ценный опыт, соглашусь полностью.
Отправлено автор: galogenIt 06 июля 2011 - 04:43 в Управление тестированием
Отправлено автор: galogenIt 07 июля 2011 - 13:11 в Управление тестированием
Спасибо, Zhu. Очень интересно, но видимо мало применимо к нам.
Отправлено автор: galogenIt 06 июля 2011 - 13:38 в Управление тестированием
Ну это у нас все и так осознают. А в чем польза?хм... ну нужды заказчика тестировщик может и не поймет. Но четко осознает -- что его работа нужна и важна.
Что есть пользователи, реальные.
На мой взгляд -- чутка побыть в техподдержке полезно!
Вот с этим поспорить трудно, хотя есть наблюдение, аналитик все рано смотрит на детище кончтруктивно, тестировщик деструктивно, если его не давить :)Ох.. для понимания нужд бизнеса эффективнее общаться с заказчиками или аналитиками, а не конечными пользователями. Через пользователей тож можно, но это потребует бОльших затрат, а тестировщику придется побыть и аналитиком тоже.
Отправлено автор: galogenIt 07 июля 2011 - 13:04 в Управление тестированием
Тут интересный момент. Есть документы, есть нечто зафиксированое в работах, но этого явно не достаточно. Поэтому в нашем случае считается нерентабельным производить документы анализа достаточные для тестирования (например)В рамках анализа...
На мой взгляд тестировщик весь этот анализ берет из документов аналитика. В то время как аналитик должен составить эти документы сначала.
Как важный момент - тестиовщик просто уйдет из тестирования в анализПредлагаю не примешивать сюда зарплаты. А то получается, что как-только тестировщик начнет понимать предметную область не хуже аналитика - ему сразу же поднимут зарплату.
Да интересная мысль!А не проще будет провести рабочую встречу для всех тестировщиков где им рассказать чем не нравится текущее положение вещей и куда надо стремиться? Нарисовать основные бизнес-процессы пользователей, распечатать и повесить на стенку - чтобы это было видно, чтобы на их основе можно было доработать текущие тесты или придумать новые.
Отправлено автор: galogenIt 06 июля 2011 - 17:18 в Управление тестированием
Отправлено автор: galogenIt 07 июля 2011 - 10:32 в Управление тестированием
Ну у нас вся разработка не работает с пользователями непосредственно. Есть сопровождение и внедрение. На сопровождении 1 человек работает на телефоне, но в целом мы с клиентами работаем через мантис. Тестеровщик имеет доступ к мантису и может анализировать информацию от пользователей.Я не понимаю, как тестировщики должны составлять отчёты о багах, которые находят пользователи, если они ещё не работают с пользователями? Или что-то не так поняла?
Если рассматривать менеджера как клиента услуг тестирования, то как и с обычными клиентами рано или поздно возникает проблема удовлетворенности ожиданий. Т.е. сейчас видимо менеджер ожидает от тестирования существенно другого чем ранее. Сопровождение инструмент воспитания у членов группы тестирования нужных компетенций. Такая постановка вопроса будет корректной?Поддреживаю Василия в разделении труда. Хотя! по ходу своей работы тестировщики могут генерировать много интересной информации (в том числе и запросов всяких). Главное, чтобы она была полезной для управленцев.
Ну в принципе в любой момент. Мы обсуждали варианты. Правда пока склонились к тому, что цель не помочь поддержки, а повысить уровень компетенции.Вопрос. А за какое время менеджеры планируют перевести отдел тестирования на новый режим работы? Есть ли возможность испробовать "демо": на ком-то одном или на каком-то небольшом промежутке времени? Чтобы оценить реальное положение дел именно у вас, а не на основе опыта других людей.
Отправлено автор: galogenIt 07 июля 2011 - 10:17 в Управление тестированием
Я тоже задался этим вопросом. Но если отбросить факт разработки:) А только остановится в рамках анализа, реально в чем разница между тесировщиком и аналитиком?Странно для меня это.
А если сделать тестировщика еще и разработчиком, то он и код сам писать будет. И тестировать сразу же. Чем не мастер на все руки?)
Отправлено автор: galogenIt 07 июля 2011 - 04:10 в Управление тестированием
Не мотивирован тоже, ну просто сложилось мнение, что только на саппорте можно быстро и широко получить нужный кругозор. При тестировании будет закапывание в детали, а при саппорте решение конкретных задач в реальном времени, будет давать больший кругозор и специфику использования системы пользователями"...тестировщик будет мотивирован перелопатить кучу информации..." - все ок, но почему вы считаете, что он будет мотивирован? А искать ошибки пока он в отделе тестирования он ее мотивирован что ли?
Почему-то эта идея - т.е. периодические отчеты, расстановка приоритетов и т.п. штучки у нас не приветствуются. Преподалагается, что тестировщики сами должны делать такие отчеты(впрочем наверное это не сложно, если есть система учета обращений), сами расставлять нужные приоритеты. Каким образом - а путем превращения тестировщика в аналитика со специализацией тестировщика. Т.е. если тестировщик будет одновременно и аналитиком, то он естественным образом будет понимать и приоритеты, и слабые места системы. Как такая идея?А вот если умный менеджмент, то от отдела сопровождения должен быть периодический отчет где больше ошибок идет от пользователей, где чаще спотыкаются)) Куда пристальнее смотреть при разработке и тестировании.
Отправлено автор: galogenIt 08 февраля 2012 - 08:49 в Управление тестированием
Я тоже не совсем понял этого термина, полагаю, что значение коэффициента может иметь точность только до 2 знаков. Данные с точностью 3 знака признаются ошибочными (видимо)
Выяснилось, что сейчас хранимая точность значения не может быть лучше 2 знаков после запятой, т.е. значение 0.325 или 0.375 является некорректным.
"хранимая точность значения" - это что?
И о каких данных идет речь?
Отправлено автор: galogenIt 08 февраля 2012 - 08:47 в Управление тестированием
1. Ошибку надо записывать всегда
2. Приоритет её определяет менеджер, как и дальнейшую работу по ней
3. Разработчик должен просыпаться в холодном поту с мыслью, что в его коде есть ошибка (в каждой шутке есть доля шутки).
Community Forum Software by IP.Board Русификация от IBResource
Лицензия зарегистрирована на: Software-Testing.Ru