Я еще раз перечитала первый пост. Так и не поняла - есть заказчик или его нету?
Т.е. работа ведется по чьему-то заказу или речь идет об инициативной разработке?
И почему 34 ГОСТ вспомнили?

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

Часть подобных инноваций инициативные, но все равно первопричины в заявках клиентов.

Про ГОСТ вспомнил SALar. Я лишь сформулировал вопрос: Кто должен осуществлять приемочное тестирование? Постановщик задачи и тестировщик, или исключительно тестировщик? Ясно, что мы можем просто сказать Вася(тестировщик) с сегодняшнего дня ты принимаешь все работы. но будет ли это возможно, и что следует сделать, чтобы было возможно?

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

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

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

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

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

Так проще и логичнее.

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

Возможна ли такая схема? Впринципе, что как ты думаешь нужно сделать для ее реализации и успеха?

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Угу, готовь на ЛАФ-2012 :)

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

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

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

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

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

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

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

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

Один из лучших видов документации - приемочный тест. Можно в виде ГОСТ 34.603, можно в свободной форме. По ГОСТ писать проще. Меньше думать надо.

А у тебя нет примерчика?

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

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

Достаточно?

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

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

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

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

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

Считается ли это нормальной, правильной практикой? Как организуется эта работа? Следует учесть, что формализованное специфицирование требований отсутствует или недостаточно формально. Серьезных изменений в этом не будет. Предполагается, что в данной ситуации проще и быстрее обучить тестировщика "здравому смыслу заказчика". Спасибо

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

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

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

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

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

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

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

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

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