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

[EugeneL]

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

Например, к Вам приходит Большой и Толстый Шеф и спрашивает: "А как у нас с тестированием фичи (области приложения) Х?". Вы понимаете, что можете дать достаточно краткий ответ, вроде "Все хорошо", "Все плохо", "Вне скоупа", но ответить на вопрос "Почему?", уже трудновато, ибо информация накапливалась в течение длительного периода времени, и чтобы найти, например, мейл Джона Доу, в котором содержиться просьба об исключении фичи/области из скоупа тестирования, Вам придется либо просмотреть переписку с ним за последние 2,5 года, либо заранее позаботится о консолидации важных знаний о проекте.

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

 

[Molechka]

Хм. На тестирование фичи ставится задача.

 

Мой опыт — писать туда все важное. Джон Доу сказал, что ее не тестируем, а принимаем на веру? Так и пишем комментом «Джон сказал не тестить, закрываю задачу без проверки». Можно еще добавлять туда дату и название письма, в котором это говорилось.

 

И всегда при закрытии писать какое-то резюме — «проверил то-се на таком то билде, закрываю».

 

Это как совещание — вы можете общаться полчаса-час-два часа, но по итогу должны сделать «Итого» и подтвердить у участников, что вы ничего не забыли. Также и в переписке, даже если она длительная, важные вещи надо закреплять, вынося в свою вики или джиру. Чтобы не искать потом по полтора часа =)

[lurk]

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

Можете использовать для введения тестового набора TestRail, TestLink, Ситечко, Zephyr... Покопайтесь в системах тест менеджмента и будет вам счастье.

Для консолидации знаний о том как работает продукт используйте Confluence, Wiki, Google Docs...

 

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

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

Если задача исключена из скопа - то тут сложнее, но тоже разрешимо. 

[SALar]

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

Элементарно решается через любой трекер. Методику лучше брать RUP-скую.