Алексей Лянгузов Кстати, если вы тестируете на пользователях, то вот бодрый и интересный долад, который может заинтересовать http://www.addconf.r...omanYuferev/321
Про manageability. понятно - готового решения там нет, но есть интересные идеи.

Спасибо, правда, тестируете на пользователях - это тайна :)

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

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

Наверное, имеет смысл добавить. Предлагаю желающим высказаться, предложить те или иные метрики. Я постараюсь все это собрать и опубликовать в блоге (вот сочинил себе блог:) http://insectfinder.blogspot.com)

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

Работы в системе управления работами имеют флаги: Проект, Направление деятельности, Тип работы, Приоритетность + есть еще принятые шаблоны сообщений, позволяющие облегчить контекстный поиск.

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

Наталия, извините, я не знаком с жаргоном Post Morten. Исследование трупа? В данном случае я не могу приспособить эттот термин к желанию узнать что-то о метриках.

Да, наш разговор о метриках привратился в философский вопрос: Don't ask me ask God. Не пойму почему бы просто не рассказать о метриках и способах их сбора и использования. Как это сделал yagor. Можно будет решить имеет смысл и нам делать также или нет. Просто это выглядет примерно так. Я спрашиваю: коллеги а как вы решаете квадратное уравнение, а мне в ответ: а зачем вы его хотите решать?

Итог: Предполагалось в течении полугода пособирать числа для статистики, после уже считать что то и делать выводы, пособирали пару месяцев для интереса считали цифры (с умным видом их обсуждали :)). Потом руководитель отдела свернул эту работу в виду нехватки ресурсов для поддержания системы.

Спасибо. Очень познавательный пост. Итог, надо сказать, меня не удивил, ждал что-то подобное. Может из Вашего стиля :)
Не кажется ли Вам, что дело не только в нехватке ресурсов, а скорее сложности подсчетов и то, что все делается вручную? Т.е. статистика не накапливается, а ее приходится потом вводить?

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

Отчет выглядит примерно так:
ID теста Укороченное описание ошибки (выбирается из лога) Дата Статус Причина падения Примечание
Статус - это критично некритично
Причина падения - ошибка тестируемого объекта, ошибка прогона (сбой), ошибка в тестовой процедуре, изменение интерфейса или вообще изменения в тестируемой программе
Примечание - обычно указывает номер работ и ее состояние в системе управления работами

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

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

НаталЬя!

Извините, Наталья. Можете за это меня несколько раз назвать каким-то Этуартом :)

Спасибо за интерес к теме и подробные ответы-советы.

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

Понятно. Я так понимаю, подобная техника может применяться не только к анализу результатов ПРОЕКТА, но и любому этапу относительно законченной деятельности. Например, после выпуска очередного релиза?

Какие критерии успешности у Вашего проекта?

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

Вы можете "измерять" статус продукта: открытые баги / KLOC, открытые баги / разработчик, % реализованных требований, % реализованного функционала с учётом веса, tests pass rate и tests fail rate (желательно с учётом приоритетов) и т.д.
Можете "измерять" статус тестирования: % покрытия функционала тестами и/или автотестами, % багов, найденных после выпуска, средний срок жизни дефекта, срок нахождения критичных дефектов (в баг-трекере проставлять не только сборку обнаружения, но и при фиксе - выявленную сборку "внесения", мне эта метрика почти всегда была полезной), собирать субъективные оценки по анкетам, % reject'ов, % дополнительно запрошенных данных по багам, $/bug, % покрытия окружений и т.д. и т.д.

Спасибо, правда я не понял, поскольку не знаю, что такое:
- % реализованного функционала с учётом веса, что вкладывается здесь в понятие функционал и чем он отличается от требования.
- tests pass rate и tests fail rate (желательно с учётом приоритетов) - доля прошедших и доля упавших тестов? Приоритет - критичность для тестируемой системы?
- % багов, найденных после выпуска, что является основанием? Общее количество багов в релизе? А как его замерить? Когда начинать измерять основание? % найденный после выпуска - вроде понятно, а вот процент к чему нет.
- средний срок жизни дефекта - что это означает? средний срок устранения дефекта? Если да, то тут думаю дефекты тоже имеет смысл разделять иначе данная статистика как средняя температура по больнице.
- срок нахождения критичных дефектов - где? в каком состоянии? или это примерно тоже , что и средних срок пребывания заявки в системе (в системах массового обслуживания?) правда я не очень понимаю, какое это отношение имеет к тестированию, это скорее к дисциплине разработки и устранения ошибок.
- собирать субъективные оценки по анкетам, поясните, пожалуйста, что Вы имеете в виду.

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

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

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

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

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

Но...

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

Средний срок исправления, да. Как предлагаете разделять? По приоритетам?

Да, по приоритетам. В целом у нас уже есть свой регламент: немедленные - исполняются в течение дня, важные - в течение недели, релизные - в течение релиза, обычные - когда руки дойдут + на "днях дезинсектора". Есть конечно внеприоритетные работы, т.е. им ставят, естественно, немедленно, но выполняются они мгновенно :)
Можно придумать и другие способы разделения - по исполнителю, например. Зависит от ситуации, которую требуется контролировать.
Правда мне не совсем понятно какой момент считать начальным, а какой конечный. В принципе, если следовать логике СМО, то от момента создания работы по дефекту до момента закрытия дефекта. У нас такой ЖЦ работ (не обязательно дефектов): предложена - запланирована - в работе - выполнена - проверяется - принята (естественно есть циклы и ветви)

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

Берём и делаем опросник на простой веб-форме, после каждого выпуска рассылаем его разработчикам, аналитикам, РМу. В нём 3-5 вопросов из серии "Оцените глубину тестирования по 10-балльной шкале", "Оцените качество дефектов по 10-балльной шкале" и т.д. Оценки ничего интересного не покажут (люди разные!), а вот динамика между версиями - очень показательна.

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

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

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

И самое главное: Вы уверены, что пропуск багов в Вашем случае - это проблема? Докажите, убедите меня, Этуарт! :)

а/ я написал допустим
б/ фраза про проблему с пропусками багов взята из Вашего предыдущего поста
в/ сама по себе метрика никак не может исправить, решить проблему - это точно так же как факт обнаружения ошибки не означает факт ее устранения или другими словами не решает проблему этой ошибки :) Так что тут у меня никаких возражений нет, да и не могло быть
г/ пропуск багов - это всегда риск. Риск предусмотренный и управляемый или непредусмотренный и неуправляемый. Пропуск ошибки - это выпуск некачественного продукта. Это определенная проблема. Всегда! Ее можно решать: ничего не делать - "сам дурак"; извинится и мгновенно устранить; обещать устранить в будущем. Пропуск багов - это лишние затраты, это риск недополучения прибыли и т.п. - это действительно проблема - серьезная или нет, it depends on
Ваш глубокий анализ верный, он вскрывает корневую причину: root problem, the problem of problems. В общем не вижу противоречий.

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

Аривидерчи

1. Метрики не нужны "для контроля" или "для визуализации". Метрики нужны для принятия решений.

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

2. Есть два типа метрик. Одни нужны для "измерения температуры больного"/"измерения эффективности предприятия" , другие для "поиска ограничений".

И в чем их различие? Можно примеры?

3.

Средний срок исправления, да.

Это неправильное измерение. Мерять нужно от фиксации до того момента, когда заказчик "сказал спасибо" / "получил первый доллар прибыли". Исправление дефекта само по себе ничего не меняет для заказчика.

А каким образом ты предлагаешь фиксировать этот самый момент на стороне заказчика?

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Спасибо за мнение, Ленчик :)

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

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

суть не меняется, но коррективы и детали внести надобно)

А в чем параллелность?

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Да интересная мысль!

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

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

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

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

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