- Форум тестировщиков
- → Публикации galogenIt
Публикации galogenIt
64 публикаций создано galogenIt (учитываются публикации только с 29 апреля 2023)
По типу контента
По пользователю
#90796 Совмещение обязанностей
Отправлено автор: galogenIt 05 июля 2011 - 19:31 в Управление тестированием
Добрый вечер, участники форума.
Искал куда разместить сообщение, подумал, что в управление тестированием вполне подойдет.
У руководства возникло предложение привлечь сотрудников отдела тестирования к работе в службе сопровождения (горячей линии).
Цели (по заявлению руководства):
1. более глубокое погружение тестировщика в предметную область, развитие у него "здравого смысла заказчика"
2. личностный рост тестировщика за счет более глубокого проникновения в предметную область, а следовательно приобретение шансов переквалифицироваться в иные виды деятельности (например аналитическую)
3. более гибкое перераспределение нагрузки между сотрудниками особенно на время отпусков.
Выглядеть это может примерно так. Ежедневно 1 сотрудник отдела тестирования поступает в распоряжение службы сопровождения. С моей позиции это равносильно переводу одного сотрудника отдела тестирования в службу поддержки (т.е. целом я против). Правда, соглашусь, что такой способ совмещения обязанностей поможет тестировщику лучше понять нужды заказчика в тестируемой системе. Больше понимать в том как она устроена и зачем так устроена. Последнее особенно важно, учитывая, тот факт, что классических спецификаций требования не будет, в лучшем случае - это объяснения в заданиях на разработку, справка.
Кто-то может что-то сказать по этому поводу? Следует ли соглашаться или, наоборот, не соглашаться? Типичная ли это практика?
Еще хотелось выяснить кто осуществляет приемочное тестирование? Автор постановки задачи или тестировщик?
Искал куда разместить сообщение, подумал, что в управление тестированием вполне подойдет.
У руководства возникло предложение привлечь сотрудников отдела тестирования к работе в службе сопровождения (горячей линии).
Цели (по заявлению руководства):
1. более глубокое погружение тестировщика в предметную область, развитие у него "здравого смысла заказчика"
2. личностный рост тестировщика за счет более глубокого проникновения в предметную область, а следовательно приобретение шансов переквалифицироваться в иные виды деятельности (например аналитическую)
3. более гибкое перераспределение нагрузки между сотрудниками особенно на время отпусков.
Выглядеть это может примерно так. Ежедневно 1 сотрудник отдела тестирования поступает в распоряжение службы сопровождения. С моей позиции это равносильно переводу одного сотрудника отдела тестирования в службу поддержки (т.е. целом я против). Правда, соглашусь, что такой способ совмещения обязанностей поможет тестировщику лучше понять нужды заказчика в тестируемой системе. Больше понимать в том как она устроена и зачем так устроена. Последнее особенно важно, учитывая, тот факт, что классических спецификаций требования не будет, в лучшем случае - это объяснения в заданиях на разработку, справка.
Кто-то может что-то сказать по этому поводу? Следует ли соглашаться или, наоборот, не соглашаться? Типичная ли это практика?
Еще хотелось выяснить кто осуществляет приемочное тестирование? Автор постановки задачи или тестировщик?
#90807 Совмещение обязанностей
Отправлено автор: galogenIt 06 июля 2011 - 04:43 в Управление тестированием
Спасибо за ответ коллеги.
Как могу судить - вижу два противоположных мнения, которые как не странно сходятся в одном - осуществлять ежедневное полноценное дежурство 1 сотрудника отдела тестирования в саппорте не целесообразно, а вот активное участие в разборе инцидентов, вполне приемлемо.
Из этих двух точек зрения тем не менее можно вычленить: нет это ничего не даст, либо будет иметь временный характер.
да, это супер интересно и конкретно стыкает - можно повеселится от души и развлечься, отдохнув от рутины тестирования .
Наверное везде по-разному, но насчет рутины в нашем отделе тестирования - это явно не про нас. У нас весьма разнообразная, живая, многоуровневая работа.
Как могу судить - вижу два противоположных мнения, которые как не странно сходятся в одном - осуществлять ежедневное полноценное дежурство 1 сотрудника отдела тестирования в саппорте не целесообразно, а вот активное участие в разборе инцидентов, вполне приемлемо.
Из этих двух точек зрения тем не менее можно вычленить: нет это ничего не даст, либо будет иметь временный характер.
да, это супер интересно и конкретно стыкает - можно повеселится от души и развлечься, отдохнув от рутины тестирования .
Наверное везде по-разному, но насчет рутины в нашем отделе тестирования - это явно не про нас. У нас весьма разнообразная, живая, многоуровневая работа.
#90808 Кто проводит приемочное тестирование
Отправлено автор: galogenIt 06 июля 2011 - 04:55 в Управление тестированием
Я было задал этот вопрос в другой теме, но мне предложили начать новую. Начинаю.
Поскажите, пожалуйста, кто по факту должен выполнять приемочное тестирование. Согласно ГОСТ 34 - это делает заказчик - поскольку это в его интересах. На практике этим скорее всего занимаются и исполнитель, и заказчик.
У нас следующий цикл разработки - большой перманентный проект (1 продукт), много клиентов, у всех одно и тоже решение с минимальной кастомизацией и в первую очередь через настройку. Периодично выпускаются релизы.
В нашем случае под приемочным тестированием будем понимать прием всех заявленных в релиз фичей. Фичи прописываются через работы-задания. Работы задания пишутся авторами: аналитиками, работы-задания исполняются программистами. В неявном фоне проверяются тестируются тестировщиками, а принимаются окончательно автором работы или иным проверяющим. прверяющим может быть любой компетентный работник - аналитик или тестировщик.
Т.е. можно сказать так приемочное тестирование (приемку работы) сейчас осуществляет обычно автор-постановщик. Предполагается, что это не совсем эффективная практика и эту работу следует полностью передать тестировщикам.
Считается ли это нормальной, правильной практикой? Как организуется эта работа? Следует учесть, что формализованное специфицирование требований отсутствует или недостаточно формально. Серьезных изменений в этом не будет. Предполагается, что в данной ситуации проще и быстрее обучить тестировщика "здравому смыслу заказчика". Спасибо
Поскажите, пожалуйста, кто по факту должен выполнять приемочное тестирование. Согласно ГОСТ 34 - это делает заказчик - поскольку это в его интересах. На практике этим скорее всего занимаются и исполнитель, и заказчик.
У нас следующий цикл разработки - большой перманентный проект (1 продукт), много клиентов, у всех одно и тоже решение с минимальной кастомизацией и в первую очередь через настройку. Периодично выпускаются релизы.
В нашем случае под приемочным тестированием будем понимать прием всех заявленных в релиз фичей. Фичи прописываются через работы-задания. Работы задания пишутся авторами: аналитиками, работы-задания исполняются программистами. В неявном фоне проверяются тестируются тестировщиками, а принимаются окончательно автором работы или иным проверяющим. прверяющим может быть любой компетентный работник - аналитик или тестировщик.
Т.е. можно сказать так приемочное тестирование (приемку работы) сейчас осуществляет обычно автор-постановщик. Предполагается, что это не совсем эффективная практика и эту работу следует полностью передать тестировщикам.
Считается ли это нормальной, правильной практикой? Как организуется эта работа? Следует учесть, что формализованное специфицирование требований отсутствует или недостаточно формально. Серьезных изменений в этом не будет. Предполагается, что в данной ситуации проще и быстрее обучить тестировщика "здравому смыслу заказчика". Спасибо
#90835 Кто проводит приемочное тестирование
Отправлено автор: galogenIt 06 июля 2011 - 10:07 в Управление тестированием
Хм, у нас тут совсем другое понимание приёмочного тестирования, и проводят его тестировщики перед выкладкой сборки на боевой сервер. Основная цель -- быстро пройти по всей функциональности (согласно бизнес процессам), чтобы выявить в первую очередь критические ошибки. Те задания, о которых говорите Вы, у нас проверяются сразу после выставления им статуса Resolved. Это и есть наша рутинная работа. Собственно потому не понимаю, чем же занимаются тестировщики у Вас большую часть времени.
Очень много чего. У нас очень сложно-хитроумный процесс. Кратко это так. Мы постоянно! тестируем одновременно три-четыре инстанса-релиза (старый релиз, молодой релиз, кандидат-релиз и транк). Связано это с тем, что у клиентов могут быть разные версии релизов но обычно в пределах 3 номеров. При этом ошибки возникают во всех релизах к сожалению.
Тестирование у нас в первую очеерд автоматизированное регрессионное. В каждом прогоне порядка 500 тестов, представляющие собой сложные бизнес-цепочки.
Работа начинается с разбора ночных прогонов, разбор тоже частично автоматизирован, формируется совокупный лог отчет. который мы потом анализируем. Чем меньше ошибок тем лучше и быстрее
Другой уровень работы - написание новых тестов для автоматизированных прогонов, расширение покрытия
Третий уровень изучение новой функциональности по транку - по необходимости написание тестов для автоматизациии и проверка прием работ
Четвертый уровенб исследовательское перманентное тестирование
Достаточно?
#90836 Кто проводит приемочное тестирование
Отправлено автор: galogenIt 06 июля 2011 - 10:08 в Управление тестированием
А у тебя нет примерчика?Один из лучших видов документации - приемочный тест. Можно в виде ГОСТ 34.603, можно в свободной форме. По ГОСТ писать проще. Меньше думать надо.
#90838 Совмещение обязанностей
Отправлено автор: galogenIt 06 июля 2011 - 10:16 в Управление тестированием
Конечно нужноЕсли ещё нужно, вот моё мнение (о чём ещё не говорили).
Не совсем понял, вы одобряете или порицаете такое объединение?Хорошенько подумайте, во что такое совмещение может вылиться именно в Вашей компании.
Ага, интересно, т.е. отдел тестирования стоял на второй волне фильтрации, т.е. получал список входящих работ от саппорта. но не работал в саппорте непосредствено?У нас на предыдущем месте работы отдел тестирования использовался в качестве 2-го уровня техподдержки. То есть все небольшие замечания техподдержка могла решить сама (они проходили практику в отделе тестирования на испытательном сроке), а сложные/долгие задачи пересылались к тестировщикам. Ну или, например, в отделе поддержки не было такого оборудования для экспериментов просто.
У тестировщиков такие запросы обычно передавались эксперту. Он разбирался с вопросом и писал ответ в службу техподдержки, а не напрямую клиенту. С клиентами общался только один отдел.
Екатерина, а что вы имеет в виду по "работа на подхвате у саппорта"? Как я понимаю это вы одобряете?Работа "на горячей линии" (как написал автор) и работа на подхвате у саппорта - это, на мой взгляд, разные вещи. Второе - когда воспроизводить баги, которые появились у клиентов - это всегда делается. И это действительно ценный опыт, соглашусь полностью.
#90844 Кто проводит приемочное тестирование
Отправлено автор: galogenIt 06 июля 2011 - 11:29 в Управление тестированием
Угу, готовь на ЛАФ-2012 :)
#90845 Совмещение обязанностей
Отправлено автор: galogenIt 06 июля 2011 - 11:37 в Управление тестированием
Насколько я понял свое руководство, цель внедрения тестировщиков в работу службы сопровождения вовсе не закрыть дыру поддержки, а в первую голову поднять уровень пони мания системы тестировщиками. Причем не с точки зрения устройства, а с точки зрения бизнес-контекста.У нас что-то похожее. Только получается уже третий уровень. Есть диспетчер, который отвечает на звонки и действует в соответствии с шаблонами, поступающими от нас. Следующий уровень -- внедренцы. Они часто по совместительству и аналитики: добывают требования. Уже смыслят в базах данных, отчётах, проводят срочные проверки каких-либо функций. Если от пользователей сыпятся сообщения, причину которых внедренец понять не в состоянии (либо же некогда выяснять), эти сообщения направляются на тестировщиков.
Есть такое мнение, что тестировщики слишком увлечены поиском каких-то отвлеченных ошибок, вместо того, что бы в первую очередь осуществлять тестирование важных с точки зрения бизнеса функций. Я не спорю, это правильно. Но я предлагал определять этот самый приоритетный контекст в пределах релиза. Но похоже есть мнение, что тестировщик, протащенный через огонь службы поддержки, сразу будет понимать все и без всяких дополнительных указаний свыше, от отдела аналитики, поскольку будет понимать нужды заказчика, его бизнес и соответственно иметь здравый смысл отделять нужное от ненужного. Как Вы считаете по своему опыту, это реально? На мой взгляд это очень похоже на заблуждение ...
#90860 Совмещение обязанностей
Отправлено автор: galogenIt 06 июля 2011 - 12:50 в Управление тестированием
Согласен, спасибо за аргументацию :)Вывод. Я считаю, что в Вашей ситуации, решение предложенное Вами же (про приоритезацию целей от релиза к релизу), более рационально. Так как дополнительные функции могут привести к рассеянному вниманию и излишней концентрации на мелочах.
Тут весь прикол, что реально тестировщик с пользователем не будет общаться, ну для начала не доверят :) А во-вторых - общаться будет с баг-трекером ...Насчет протаскивания "через огонь службы поддержки". А пользователи что объясняют свой бизнес когда обращаются в поддержку? Они наверняка напишут: "Нажал туда-то - сломалось". Нужда ясна - почините. Бизнес процессов здесь может и не быть.
И еще - общение с пользователями - это отдельный склад характера, все-таки. Кому-то нравится, а кому-то и нет...
Во по поводу понять свой бизнес. Похоже Вы в точку. Смотрю инциденты, написано часто очень кратко и малопонятно. Но видимо предполагается, что для ответа на вопрос, тестировщик будет мотивирован перелопатить кучу информации и понять суть проблемы, а если он вумный, то постепенно начнет понимать нужды бизнеса,хотя бы по частоте обращений и по стилю вопросов :)
#90866 Совмещение обязанностей
Отправлено автор: galogenIt 06 июля 2011 - 13:38 в Управление тестированием
Ну это у нас все и так осознают. А в чем польза?хм... ну нужды заказчика тестировщик может и не поймет. Но четко осознает -- что его работа нужна и важна.
Что есть пользователи, реальные.
На мой взгляд -- чутка побыть в техподдержке полезно!
Вот с этим поспорить трудно, хотя есть наблюдение, аналитик все рано смотрит на детище кончтруктивно, тестировщик деструктивно, если его не давить :)Ох.. для понимания нужд бизнеса эффективнее общаться с заказчиками или аналитиками, а не конечными пользователями. Через пользователей тож можно, но это потребует бОльших затрат, а тестировщику придется побыть и аналитиком тоже.
#90879 Совмещение обязанностей
Отправлено автор: galogenIt 06 июля 2011 - 17:18 в Управление тестированием
Zhu, Вашу мысль я услышал.
Заметьте разницу: "руковожу отделами", и представитель одного отдела совмещает работу в другом. По сути у Вас один отдел. Существует ли у Вас специализация? Как она организована, каковы обязанности тестировщика и специалиста поддержки, как обязанности совмещаются? Сколько человек?
То, что ошибки обнаруживаются пользователями, это конечно, подспорье, правда не то, за которое гладят по голове. И тот факт, что в месте обнаруженной ошибки высока вероятность обнаружения еще ошибки, тоже понятно.
Однако в чем конкретная выгода на Ваш взгляд? Почему ее не получить из анализа ежедневных работ, списка обращений?
Заметьте разницу: "руковожу отделами", и представитель одного отдела совмещает работу в другом. По сути у Вас один отдел. Существует ли у Вас специализация? Как она организована, каковы обязанности тестировщика и специалиста поддержки, как обязанности совмещаются? Сколько человек?
То, что ошибки обнаруживаются пользователями, это конечно, подспорье, правда не то, за которое гладят по голове. И тот факт, что в месте обнаруженной ошибки высока вероятность обнаружения еще ошибки, тоже понятно.
Однако в чем конкретная выгода на Ваш взгляд? Почему ее не получить из анализа ежедневных работ, списка обращений?
#90880 Кто проводит приемочное тестирование
Отправлено автор: galogenIt 06 июля 2011 - 17:24 в Управление тестированием
А что значит серьезное разделение ролей?В проектах с серьезным разделением ролей заказчик дает задачу аналитику, а аналитик должен продемонстрировать работу системы заказчику.
Так проще и логичнее.
А если рассматривать схему: есть аналитик - постановщик задачи и есть тест-дизайнер который сопровождает постановку такой задачи, готовит тесты и осуществляет полную приемку решений, освобождая аналитика для новых работ, вместо рутины проверки.
Т.е. ситуация когда реально аналитиков мало, а тестировщиков вроде бы многовато, и хотелось бы больше отдачи инвестиций, т.е. чтобы тестировщик полноценно мог принимать работу.
Возможна ли такая схема? Впринципе, что как ты думаешь нужно сделать для ее реализации и успеха?
#90886 Совмещение обязанностей
Отправлено автор: galogenIt 07 июля 2011 - 04:10 в Управление тестированием
Не мотивирован тоже, ну просто сложилось мнение, что только на саппорте можно быстро и широко получить нужный кругозор. При тестировании будет закапывание в детали, а при саппорте решение конкретных задач в реальном времени, будет давать больший кругозор и специфику использования системы пользователями"...тестировщик будет мотивирован перелопатить кучу информации..." - все ок, но почему вы считаете, что он будет мотивирован? А искать ошибки пока он в отделе тестирования он ее мотивирован что ли?
Почему-то эта идея - т.е. периодические отчеты, расстановка приоритетов и т.п. штучки у нас не приветствуются. Преподалагается, что тестировщики сами должны делать такие отчеты(впрочем наверное это не сложно, если есть система учета обращений), сами расставлять нужные приоритеты. Каким образом - а путем превращения тестировщика в аналитика со специализацией тестировщика. Т.е. если тестировщик будет одновременно и аналитиком, то он естественным образом будет понимать и приоритеты, и слабые места системы. Как такая идея?А вот если умный менеджмент, то от отдела сопровождения должен быть периодический отчет где больше ошибок идет от пользователей, где чаще спотыкаются)) Куда пристальнее смотреть при разработке и тестировании.
#90887 Кто проводит приемочное тестирование
Отправлено автор: galogenIt 07 июля 2011 - 04:19 в Управление тестированием
Заказчик - это клиенты, новые и уже имеющиеся. В ходе работы у них возникают те или иные потребности в добавлении, изменении и улучшении. Все эти потребности составляют потенциальный бэклог работ, которые нуждаются:Я еще раз перечитала первый пост. Так и не поняла - есть заказчик или его нету?
Т.е. работа ведется по чьему-то заказу или речь идет об инициативной разработке?
И почему 34 ГОСТ вспомнили?
- в анализе потребности и постановке задачи
- в проектировании и разработке
- в тестировании
- во внедрении и обучении
Часть подобных инноваций инициативные, но все равно первопричины в заявках клиентов.
Про ГОСТ вспомнил SALar. Я лишь сформулировал вопрос: Кто должен осуществлять приемочное тестирование? Постановщик задачи и тестировщик, или исключительно тестировщик? Ясно, что мы можем просто сказать Вася(тестировщик) с сегодняшнего дня ты принимаешь все работы. но будет ли это возможно, и что следует сделать, чтобы было возможно?
#90905 Совмещение обязанностей
Отправлено автор: galogenIt 07 июля 2011 - 10:17 в Управление тестированием
Я тоже задался этим вопросом. Но если отбросить факт разработки:) А только остановится в рамках анализа, реально в чем разница между тесировщиком и аналитиком?Странно для меня это.
А если сделать тестировщика еще и разработчиком, то он и код сам писать будет. И тестировать сразу же. Чем не мастер на все руки?)
Например есть такой аргумент:
аналитик получает больше, соответственно более дорогой ресурс,
тестировщик тоже должен понимать предметку и явно не хуже аналитика
#90908 Совмещение обязанностей
Отправлено автор: galogenIt 07 июля 2011 - 10:32 в Управление тестированием
Ну у нас вся разработка не работает с пользователями непосредственно. Есть сопровождение и внедрение. На сопровождении 1 человек работает на телефоне, но в целом мы с клиентами работаем через мантис. Тестеровщик имеет доступ к мантису и может анализировать информацию от пользователей.Я не понимаю, как тестировщики должны составлять отчёты о багах, которые находят пользователи, если они ещё не работают с пользователями? Или что-то не так поняла?
Если рассматривать менеджера как клиента услуг тестирования, то как и с обычными клиентами рано или поздно возникает проблема удовлетворенности ожиданий. Т.е. сейчас видимо менеджер ожидает от тестирования существенно другого чем ранее. Сопровождение инструмент воспитания у членов группы тестирования нужных компетенций. Такая постановка вопроса будет корректной?Поддреживаю Василия в разделении труда. Хотя! по ходу своей работы тестировщики могут генерировать много интересной информации (в том числе и запросов всяких). Главное, чтобы она была полезной для управленцев.
Ну в принципе в любой момент. Мы обсуждали варианты. Правда пока склонились к тому, что цель не помочь поддержки, а повысить уровень компетенции.Вопрос. А за какое время менеджеры планируют перевести отдел тестирования на новый режим работы? Есть ли возможность испробовать "демо": на ком-то одном или на каком-то небольшом промежутке времени? Чтобы оценить реальное положение дел именно у вас, а не на основе опыта других людей.
Исходя из этой концепции базовым предложением служит передача на определенный срок 1 сотрудника из отдела тестирования в отдел сопровождения. Повторю: цель быстрое пгружение в предметную область и рост компетенций в бизнес среде.
А причина - недовольство тем, что тестирровщик порою уделяет слишком много внимания системным ошибкам, техническим деталям в противовес к бизнес аспектам и логике использования.
#90942 Совмещение обязанностей
Отправлено автор: galogenIt 07 июля 2011 - 13:04 в Управление тестированием
Тут интересный момент. Есть документы, есть нечто зафиксированое в работах, но этого явно не достаточно. Поэтому в нашем случае считается нерентабельным производить документы анализа достаточные для тестирования (например)В рамках анализа...
На мой взгляд тестировщик весь этот анализ берет из документов аналитика. В то время как аналитик должен составить эти документы сначала.
Как важный момент - тестиовщик просто уйдет из тестирования в анализПредлагаю не примешивать сюда зарплаты. А то получается, что как-только тестировщик начнет понимать предметную область не хуже аналитика - ему сразу же поднимут зарплату.
Да интересная мысль!А не проще будет провести рабочую встречу для всех тестировщиков где им рассказать чем не нравится текущее положение вещей и куда надо стремиться? Нарисовать основные бизнес-процессы пользователей, распечатать и повесить на стенку - чтобы это было видно, чтобы на их основе можно было доработать текущие тесты или придумать новые.
#90950 Совмещение обязанностей
Отправлено автор: galogenIt 07 июля 2011 - 13:11 в Управление тестированием
Спасибо, Zhu. Очень интересно, но видимо мало применимо к нам.
У нас тяжеленное корпоративное решение, с гигантским количеством функционала, параметризации и настроек, в результате количество возможных комбинаций мгновенное уходит в бескончность. + жесткая ответственность перед бизнесом. Потому у нас и есть разделение.
Я все-таки полагаю. что совмещение в нашем случае малоэффективно, вот стоять на втором этапе разбора инцидентов - хорошо, возможно проходить начальное обучение для быстрого погружения в предметку тоже, тесное сотрудничество - великолепно. Совмещение - думаю слишком разные акцепты
#90979 Совмещение обязанностей
Отправлено автор: galogenIt 07 июля 2011 - 14:14 в Управление тестированием
В мою нет, в цель компании может быть. Тестирование трамплин для карьерного роста и инструмент снижения затрат на подготовку аналитика и выполнения части аналитической работыЭто укладывается в вашу цель?
Как важный момент - тестиовщик просто уйдет из тестирования в анализ
#90988 Совмещение обязанностей
Отправлено автор: galogenIt 07 июля 2011 - 18:48 в Управление тестированием
Это я привел возможную причину, выведенную из аргументов извне. Я полагаю, что такова была стратегия до текущего момента. Так же можно предположить, это связано с определенной неопытностью ...А почему он это делает?
А какое это имеет отношение к нашей беседе?Наши рядовые аналитики получают по моей информации примерно так же, как и тестировщки. А вот ценные аналитики... Там такой опыт и такие знания, что вполне понятно, за что им платят деньги. Другое дело, что, по моей же информации, рядовые программисты получают больше тестировщиков. Откуда растут ноги у таких явлений?
Да я с Вами согласен. Вопрос разногласия, что считать важным багом. Однако это тема иной дискуссии. В рамках этой могу добавить, что, предположительно, именно работа в службе поддержки должна помочь тестировщику приобрести способность понимания особо важного бага.Как мне кажется, конечная цель менеджеров galogenIt -- отловить все особо важные баги до релиза, потому что они, найденные пользователями, стоят гораздо больше (возможно потому, что не могут быть быстро починены).
#90998 Совмещение обязанностей
Отправлено автор: galogenIt 08 июля 2011 - 07:22 в Управление тестированием
Т.е. плюсы для бизнеса (идеи и новый взгляд), плюсы для человека (понять - где твое место, тренинг адаптируемости, расширение сознания).
Ну и эмоциональная составляющая (см. пример с театром).
Да под таким углом я не смотрел. Можно вопрос? Под каким углом это подавать? Сказать - ты завтра работаешь в другом месте, потому что это хорошо для тебя, бизнеса, компании?
#91003 Совмещение обязанностей
Отправлено автор: galogenIt 08 июля 2011 - 07:45 в Управление тестированием
В начале дискуссия я их понимал как: "отсутствие здравого смысла заказчика". Далее возникло понятие: тестировщик должен выполнять приемочное тестирование, т.е. есть автор работы - скажем аналитик. Обычно он и проверяет исполнение работы, однако на аналитика высока нагрузка и нужно переложить эту работу на тестировщика. Казалось что проще, есть требования - читаем и проверяем. Но тут дело в том, что есть скорее общая постановка, детали и нюансы скрыты или не зафиксированы, потому. чтобы тестировщик мог принимать работу ему нужно быть в бизнес-контексте, который он может получить например работая на службе поддержки, решая конкретные проблемы пользователя, он постигнет нужную глубину бизнес-контекста и такми образму сумеет принять работу без наличия нужных деталей, т.е. просто поймет вычислит ихЯ куда клоню. Менеджер видит проблему в каком-то факте. Трактует этот факт по-своему и предлагает решение, основанное на этой трактовке. Факт мы знаем (нахождение не тех багов, которые бы хотелось найти в первую очередь), но у этого факта тоже есть свои причины. Возможно, менеджер придумал себе причину, которая на самом дере нереальна. Отсюда и предложенное решение, которое Вам не нравится. Хорошо, если мои слова не подходят для вашей ситуации, но если нет? Вот я и хочу докопаться до причины факта, побудившего затеять такие перемены.
#91014 Совмещение обязанностей
Отправлено автор: galogenIt 08 июля 2011 - 08:44 в Управление тестированием
Красиво сказали :)Что-то я перестала видеть Вашу собственную точку зрения. Пожалуй, пока остановлюсь в дальнейшем выуживании информации, мои мысли зашли в тупик собственного контекста.
#91025 Кто проводит приемочное тестирование
Отправлено автор: galogenIt 08 июля 2011 - 11:11 в Управление тестированием
Давайте этот вопрос обсудим подробнее.Честно говоря, я сначала испугалась, а не так ли это? :) Потом подумала и пришла вот к чему. В течении недели я слежу за каждой задачей в отдельности. По каждой в отдельности правят баги, если требуется. Перед релизом мне выдаётся кандидат, на котором я смотрю на работу системы в целом и как в неё вписалась новая функциональность. Разве это не приёмочное?
Почему это делаем мы. Заказчик -- министерство. Задачи поступают от внедренца-аналитика, продажника, ещё одного человека, функций которого я не знаю, но реального пользователя. Т.о. нет единого центра, кто бы нёс ответственность за приёмку. Ответственность возложили на тестировщика.
А ещё у нас есть чек-листы, которые должны заполняться при проведении приёмочного. По ним, видно, что проверено и какие баги возникли.
Итак у Вас есть заказчки - это министерство, естественно с ним Вы не контактируете. У нас также собственно.
В момент Х вы планируете приемочное тестирование, как я понял у вас есть чек-листы. Кто их составляет? На основании чего их составляют? Как Вы понимаете, что принимаемая вами функциональность работает правильно?
#91047 Совмещение обязанностей
Отправлено автор: galogenIt 08 июля 2011 - 19:56 в Управление тестированием
Вообще мы этот аспект пока не обсуждали. Я лишь сделал анонимный опрос о том, будет ли полезным такое совмещение. В целом сказали, что это было бы полезным, но не в форме ежедневных дежурств. В принципе я сам провожу анализ поступающих инцидентов на протяжении нескольких месяцев. У нас сначала был поток работ, по которым нужен тест (все у кто считал что это важно могли пометить работу таким признаком), но потом я стал анализировать работы, поступающие в течение дня и сам определял, что с ними делать. Сейчас у нас появилась система "мантис", которая позволяет не только активнее участвовать в поддержке, но и делать анализ поступающих инцидентов с ретроспективой и привязкой к тем или иным разрезам. У меня создалось впечатление, что этого было бы вполне достаточно: а/быть на второй линии, б/постоянно мониторить инциденты.Эдуард, а что ваши тестировщики думают по этому поводу?
Я, наконец, осознала, что там происходит. Люди занимаются в основном автоматизированным тестированием. Исследовательским тоже, но мало. Посему, у них нет общей картины по работе системы в целом. Мне кажется, надо провести полный цикл ручного тестирования, проходя по всем веткам бизнес-процесса. Иначе, даже посидев в техподдержке, будет кусочное представление о проекте, только какие-то кусочки станут более важными.
Да это так. Автоматизированное тестирование одно из генеральных направлений (по крайней мере было). Исследовательское тестирование производится. Достаточно регулярно. Мало или немало, не могу сказать. А как Вы определили по моим словам, что мало? А сколько надо?
А что значит провести полный цикл ручного тестирования? У нас очень сложные бизнес-процессы. Мне кажется общее представление о них у нас как раз нет, а вот важных деталей, особенно на стыке задач, вполне возможно
- Форум тестировщиков
- → Публикации galogenIt
- Политика Конфиденциальности
- Правила форума ·