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

[Tanya_]

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

[Tiana]

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

[Clauster]

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

[Lyzzochka]

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

[Imbecile]

Написанием в формализированном виде, как конечного документа, по которым потом идёт разработка - нет. А вот участовать в процессе выработки и уточнения - постоянно. У нас практикуется из-за того, что нет аналитика (системного дизайнера), да он, по-большому счёту и не нужен.
Есть Client Manager, который напрямую общается с заказчиком и получает у него приблизительное видение продукта. На основании этого, формирует своё, более детальное, но всё ещё недостаточное для разработки/тестирования видение и формализует его в виде документов. После этого, руковоитель разработчиков и руководитель отдела качества, начинают думать, а что собственно вытекает из этих требований и начинают засыпать Client Manager вопросами и просьбами уточнить, что имелось в виду. Всё это фиксируется каким-либо инструментом управления задачами (у нас это RT) и отдел качества готовится к проведению тестирования, а разработчики получают более детальную спецификацию, выработанную их руководителем, на основании треккинга начальной задачи.
Если говорить о полезности такого подхода, то с одной стороны у всех участников вырабатывается более полное понимание системы, что хорошо, а с другой - это требует времени (что не очень хорошо) и хороших аналитических и технических знаний у упомянутых людей - Client Manager, Project Manager, QA Leader.