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

[galogenIt]

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

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

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

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

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

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

[Natalya Rukol]

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

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

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

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

[elfische]

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

[Freiman]

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

Может, это не приемочное, а smoke-тестирование?

[SALar]

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

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

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

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

Следует учесть, что формализованное специфицирование требований отсутствует или недостаточно формально. Серьезных изменений в этом не будет.

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

--------------------------------
Потратьте 45 минут, посмотрите: http://blogs.uml2.ru...rebovaniy-Video

[galogenIt]

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

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

Достаточно?

[galogenIt]

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

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

[SALar]

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

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

У меня много чего есть. Примеров ПМИ в разных формах масса. Но среди них пока нет тех, которые не попадают под НДА.

Нужно делать семинар, итогом которого будет артефакт, который можно выложить в открытом доступе. Подобный этому: http://www.software-...um/topic/17401/

[galogenIt]

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

[Фрося]

Нужно делать семинар, итогом которого будет артефакт, который можно выложить в открытом доступе. Подобный этому: http://www.software-...um/topic/17401/

Я этот артефакт давно скачала....

Ну как хотите -- никак не пойму.
Этот артефакт это что?
Это требования к системе? Как написано в п.1 "описания требований к системе управления дефектами" ?
Тогда п.3 где "Возможные цели:" описаны тут при чем? А что есть еще и невозможные цели? И какая разница - -как заказчик фичи собирает?
Или - "Поэтому основной целью Системы будем считать именно «увеличение точности прогнозирования дат выпуска релизов»" -- т.е. что? Мы будем считать, что это цель? Хорошо, пусть так. Заказчику просто предлагаем? Ну решили - что это цель и хорошо!
В п.4 "Задачи, решаемые системой " тоже непонятно -- "4.Техподдержка (надо внедрить)". Э.... Это что? данная система решает задачу внедрения техподдержки? Людей набирает, телефоны подключает?

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

Прошу прощения... я еще и технический писатель ... Ну невнятица плюс смесь программерского языка с русским...
"Залогинен" и т.п.

[galogenIt]

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

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

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

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

[Фрося]

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

[galogenIt]

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

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

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

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

[SALar]

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

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

Для реализации ее нужно реализовать.
Для успеха от нее нужно отказаться.

PS.

Потратьте 45 минут, посмотрите: http://blogs.uml2.ru...rebovaniy-Video

[SALar]

Я этот артефакт давно скачала....

Ну как хотите -- никак не пойму.
Этот артефакт это что?
Это требования к системе? Как написано в п.1 "описания требований к системе управления дефектами" ?
Тогда п.3 где "Возможные цели:" описаны тут при чем? А что есть еще и невозможные цели? И какая разница - -как заказчик фичи собирает?
Или - "Поэтому основной целью Системы будем считать именно «увеличение точности прогнозирования дат выпуска релизов»" -- т.е. что? Мы будем считать, что это цель? Хорошо, пусть так. Заказчику просто предлагаем? Ну решили - что это цель и хорошо!
В п.4 "Задачи, решаемые системой " тоже непонятно -- "4.Техподдержка (надо внедрить)". Э.... Это что? данная система решает задачу внедрения техподдержки? Людей набирает, телефоны подключает?

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

Прошу прощения... я еще и технический писатель ... Ну невнятица плюс смесь программерского языка с русским...
"Залогинен" и т.п.

Этот документ такой по двум причинам:
1) Составлен за два часа. Что маловато для вылизования.
2) Хотелось получить артефакт не в конечном, а в промежуточном состоянии. Чтобы показать ход мысли.

По пунктам:
Возможные цели
Примечание аналитика. Пока не утверждены с заказчиком. Потому "возможные/предполагаемые"

п.3
Он в этом документе потому, что решено не выносить концепцию в отдельный документ.

ну и т.д.

[brontozjabr]

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

[elfische]

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

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

Может, это не приемочное, а smoke-тестирование?

Честно говоря, я сначала испугалась, а не так ли это? :) Потом подумала и пришла вот к чему. В течении недели я слежу за каждой задачей в отдельности. По каждой в отдельности правят баги, если требуется. Перед релизом мне выдаётся кандидат, на котором я смотрю на работу системы в целом и как в неё вписалась новая функциональность. Разве это не приёмочное?
Почему это делаем мы. Заказчик -- министерство. Задачи поступают от внедренца-аналитика, продажника, ещё одного человека, функций которого я не знаю, но реального пользователя. Т.о. нет единого центра, кто бы нёс ответственность за приёмку. Ответственность возложили на тестировщика.

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

[galogenIt]

Честно говоря, я сначала испугалась, а не так ли это? :) Потом подумала и пришла вот к чему. В течении недели я слежу за каждой задачей в отдельности. По каждой в отдельности правят баги, если требуется. Перед релизом мне выдаётся кандидат, на котором я смотрю на работу системы в целом и как в неё вписалась новая функциональность. Разве это не приёмочное?
Почему это делаем мы. Заказчик -- министерство. Задачи поступают от внедренца-аналитика, продажника, ещё одного человека, функций которого я не знаю, но реального пользователя. Т.о. нет единого центра, кто бы нёс ответственность за приёмку. Ответственность возложили на тестировщика.

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

Давайте этот вопрос обсудим подробнее.

Итак у Вас есть заказчки - это министерство, естественно с ним Вы не контактируете. У нас также собственно.
В момент Х вы планируете приемочное тестирование, как я понял у вас есть чек-листы. Кто их составляет? На основании чего их составляют? Как Вы понимаете, что принимаемая вами функциональность работает правильно?

[Фрося]

Этот документ такой по двум причинам:
1) Составлен за два часа. Что маловато для вылизования.
2) Хотелось получить артефакт не в конечном, а в промежуточном состоянии. Чтобы показать ход мысли.

По пунктам:
Возможные цели
Примечание аналитика. Пока не утверждены с заказчиком. Потому "возможные/предполагаемые"

п.3
Он в этом документе потому, что решено не выносить концепцию в отдельный документ.

ну и т.д.

а.... ну понятно... т.е. кто-то тренировался и учился как писать...
Ну и что-то типа фиксации возможного потока сознания аналитика, да?

[elfische]

Давайте этот вопрос обсудим подробнее.

Итак у Вас есть заказчки - это министерство, естественно с ним Вы не контактируете. У нас также собственно.
В момент Х вы планируете приемочное тестирование, как я понял у вас есть чек-листы. Кто их составляет? На основании чего их составляют? Как Вы понимаете, что принимаемая вами функциональность работает правильно?

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

Важность. Помимо здравого смысла НЕОБХОДИМО опросить всех, кто может принимать эту работу и выяснить, что в первую очередь должно работать. Т.е. в вашем случае без мнения аналитиков никуда. Отмечается разноцветными звёздочками: красные -- супер важно, желтые -- важно, зелёные -- если не работает или работает частично, катастрофы не будет, но лучше, чтобы работало.

Функциональность. Так как система имеет сложные бизнес-процессы (бп), всё описать не получается. Будьте готовы чем-то пожертвовать. Как описывать функциональность, тут надо подумать.
Я для себя выбрала следующий способ. Описывается каждая сущность-существительное, и крупные действия для них; сущности-действия опускаются и остаются на моей совести. Например, Сначала указаны разделы. Для каждого из них своя табличка. Сущность "случай". Крупные действия для него -- создание, редактирование, удаление, взятие на учёт. Последнее в чистом виде относится к бп. Сущность "случай" содержит вкладки: сущности "осмотр", "исследования", "извещение", "выписки". Каждая из этих сущностей так же имеет подуровни. Начиная с этого уровня сущности-действия описываются только для бп: продвижение извещений и выписок по бп (направление на подтверждение, подтверждение, взятие на учёт). Важность у этих вкладок неодинаковая. Соответственно и важность действий тоже: отмена извещений и выписок не так важна, как их подтверждение, поэтому не включена в чек-лист.
При этом пункты расположены в приблизительном соответствии с проходом по бп.
Можно фиксировать сущности-действия: создание случая, создание осмотра, подтверждение выписки, взятие на учёт по подтверждению выписки. Для меня в таком виде есть опасность, что могу забыть какое-то действие, которое не зафиксировала из-за нерезиновости списка.
Можно фиксировать переходы по бп: взятие на учёт по подтверждению извещения, взятие на учёт по подтверждению выписки, запись на приём, снятие с учёта, составление отчётов. Этот подход хорош, если никому из читающих или проходящих по чек-листу не нужно объяснять, как совершить то или иное действие.
Также у нас было предложение фиксировать новую функциональность (любое изменение), но это не прижилось. Только когда появляются новые сущности, меняется чек-лист.

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

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

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