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

[Alexander_A]

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

Это становится уже смешным.
Я ведь уже ответил на этот вопрос Натальи в своём сообщении 20.05. И указал об этом повторно Наталье в своём сообщении 22.05.

Напишу ещё раз.
- "Тестирование можно (кривовато) проводить по RFD и пр. документам программистов." Т.е. мы проверяем соответствие согласно наследованным требованиям из п.3.
- "... к тестированию MUST подключать ПОЛЬЗОВАТЕЛЯ-ЗАКАЗЧИКА, который будет сидеть рядом с профессиональным тестировщиком и они ВМЕСТЕ будут писать сценарии." - T.e. проверяется соответствие исходным требованиям. При открытии бага на бизнес-процесс, можно будет ссылаться на мнение заказчика (статус Production). (В данном случае мы частично, на уровне написания сценариев, объединяем Delivery и Acceptance тестирование, что допускается по методологии CMMI).

(Если кому интересно, то здесь "спрятан под листьями" аргумент для "влияние на начальство": время, затраченное пользователем, не "пропадёт", т.к. пользователь получит в своё распоряжение готовые, им же придуманные сценарии бизнес-процессов. И ему (или его тестировщикам) придётся только прогнать их в своём окружении.)

[Фрося]

Документы программистов - это РАЗ.

Основное -- ТЕКСТ ПРОГРАММ, с расспросами в непонятных местах --- а что тут-то ребята, вы хотели сделать!

[barancev]

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

Напишу ещё раз.
- "Тестирование можно (кривовато) проводить по RFD и пр. документам программистов." Т.е. мы проверяем соответствие согласно наследованным требованиям из п.3.
- "... к тестированию MUST подключать ПОЛЬЗОВАТЕЛЯ-ЗАКАЗЧИКА, который будет сидеть рядом с профессиональным тестировщиком и они ВМЕСТЕ будут писать сценарии." - T.e. проверяется соответствие исходным требованиям. При открытии бага на бизнес-процесс, можно будет ссылаться на мнение заказчика (статус Production). (В данном случае мы частично, на уровне написания сценариев, объединяем Delivery и Acceptance тестирование, что допускается по методологии CMMI).

А если пункт 3 тоже пропал, RFD нет и не было, разработка велась "со слов заказчика"?

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

[Vestalka]

- "... к тестированию MUST подключать ПОЛЬЗОВАТЕЛЯ-ЗАКАЗЧИКА, который будет сидеть рядом с профессиональным тестировщиком и они ВМЕСТЕ будут писать сценарии." - T.e. проверяется соответствие исходным требованиям. При открытии бага на бизнес-процесс, можно будет ссылаться на мнение заказчика (статус Production). (В данном случае мы частично, на уровне написания сценариев, объединяем Delivery и Acceptance тестирование, что допускается по методологии CMMI).

(Если кому интересно, то здесь "спрятан под листьями" аргумент для "влияние на начальство": время, затраченное пользователем, не "пропадёт", т.к. пользователь получит в своё распоряжение готовые, им же придуманные сценарии бизнес-процессов. И ему (или его тестировщикам) придётся только прогнать их в своём окружении.)

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

[Alexander_A]

Документы программистов - это РАЗ.
Основное -- ТЕКСТ ПРОГРАММ, с расспросами в непонятных местах --- а что тут-то ребята, вы хотели сделать!

Осторожно! Мины!
Текст программ может дать информацию по структуре процессов, данными, нтерфейсам с внешними системами и т.д., и показать "места" тестирования, но это, всё же, наоборот - объект тестирования, а не оракул.

А если пункт 3 тоже пропал, RFD нет и не было, разработка велась "со слов заказчика"?

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

Если нет пункта 3, то остаётся только тестирование "с привлечением".
Варианты "уговорить заказчика написать требования", как и "приказать аналитику их написать", невозможны по условиям задачи, определённым Натальей.
Заказчик будет готов "сидеть часами", когда ему объяснят, что он всё равно должен будет потратить время на проверку "того, что он купил".

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

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

Кошмар!
Описанная ситуация - форменная наглость с Вашей стороны. Я понимаю заказчика.
Я бы уже давно сформировал тестовое окружение, приехал бы к заказчику со своими компьютерами и сидел бы у него, вылавливая по паре часов в день его свободного времени. За неделю-другую сценарии для E2E были бы готовы.
А вы его даже "увидеть" не смогли.

2 All.
Извините, мне это начало надоедать. Я пришёл сюда учиться, а не учить.

[Фрося]

Осторожно! Мины!
Текст программ может дать информацию по структуре процессов, данными, нтерфейсам с внешними системами и т.д., и показать "места" тестирования, но это, всё же, наоборот - объект тестирования, а не оракул.

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

2 All.
Извините, мне это начало надоедать. Я пришёл сюда учиться, а не учить.

А тут просто учиться ни разу не получится.
Реально оцените свой опыт --- разве он не достаточно обширен, что бы самому делится знаниями?

[Vasiliy]

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

Наверное, можно начинать завидовать хорошим заказчикам))

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

Так что все зависит от ситуации.

[Vestalka]

Кошмар!
Описанная ситуация - форменная наглость с Вашей стороны. Я понимаю заказчика.
Я бы уже давно сформировал тестовое окружение, приехал бы к заказчику со своими компьютерами и сидел бы у него, вылавливая по паре часов в день его свободного времени. За неделю-другую сценарии для E2E были бы готовы.
А вы его даже "увидеть" не смогли.

Он был на Кипре пару недель. Потом - уехал в Москву. Потом - к родителям во Францию. Потом - Б-г еще знает куда.
У меня есть тестовое окружение, у меня есть отчеты, у меня есть предполагаемый результат даже!
Но как Вы предлагаете его вылавливать? Летать на Кипр на пару недель, потом - во Францию за зарплату тестировщика? ))))
Я все свои выкладки давно показала Project Owner, но нет никаких гарантий того, что его согласование == согласованию заказчика.

[SALar]

Вопрос о написании требований тестировщиком достаточно больной. Мне ближе мнение Alexander_A.
Но я был бы более категоричен.

Если аналитик не написал требования - то на проекте не было аналитика.
Тот, кто написал требования - и есть аналитик.
Совмещение написания требований и тестирования одним человеком - очень хорошая практика.
Если аналитик не умеет тестировать - это плохой аналитик.

И более развернуто: http://blog.shumoos.com/archives/234