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

[TC_Noob]

Всем доброго времени суток!

Вопрос в следующем, Стоит ли описывать повторяемые шаги не ссылками?

Раскрою вопрос:

Представим вполне реальную ситуацию, в системе 10 функциональных блоков, в каждом из которых есть функции, которые повторяются в остальных,

в первом случае, мы описываем как проверить эти самые функции, а в последующих - мы лишь указываем ссылки на эти шаги

Например
 15-02-2012 9-56-55.jpg   50,15К   98 Количество загрузок:

Как показано из примера, мы, дабы, сократить описание пишем, Выполнен шаг и номер шага

Какой я вижу плюс: Сокращение описания, сокращение самого плана тестирования

Какие я вижу минусы:
1. Нужно постоянно искать по плану тестирования тот самый шаг, т.е. представим, вы на шаге номер 100 и вам говориться, выполнить шаг 15, представляете, вам НАДО скроллировать план тестирования на шаг номер 15, ПОТОМ обратно на шаг номер 100 - это не удобно.
2. Не подготовленный человек, порой, запутывается с нумерацией, и тратит намного больше времени с проверкой, а если ему указать повторяющиеся шаги, то он, во-первых, проверит без всяких вопрос, типа, а что тут имелось ввиду, во-вторых, проверить быстрее.

Вот, собственно, и камень преткновения, как поступить правильно?

[nstreltsov]

Мое мнение: не надо писать кейсы с количеством шагов 100, например есть отдельно тест на авторизацию, в остальных тестах в начальных условиях можно описать, что пользователь должен быть авторизован и находиться на определенной странице(это описывается, например в тестах 1 и 41)
Что касается написания: "повторить шаг 15" один шаг можно и написать, а вот допустим для дальнейшего продолжения надо повторить шаги 2-15, то лучше так и написать.

[TC_Noob]

Из моего примера, у нас головных пунктов - 10 штук

В каждом пункте по 30 функциональных пунктов-проверок

1.1
1.2
...
1.30

2.1
2.2
...
2.30
....
10.30


Предлагается каждый раз скроллировать к нужному пункту в таком случае, для шага 9.27 Выполнить шаг 3.10, правильно я понял?

[theart]

Возникала проблема в подобной ситуации. Хотел поступить так же как ТС, но после полученного опыта - отказался от этой идее и завёл на каждое меню отдельные кейсы.
А теперь суть:
Есть некое приложение для работы с документами. Приложение содержит 5 страниц различных разбивок документов (например "Документы по регионам", "документы по ценам" и т.д.).
Функциональное меню страниц почти идентично, за редким исключением. Это кнопки - добавить, удалить, перейти, экспорт в эксель и т. д.
В итоге возникла ситуация что некоторые кнопки были недоступными в конкретном окне, например "Документы по регионам" не должны поддерживать функцию удалить и прочее.
Так как нормальной документации не было, пришлось обсуждать каждое меню с разработчиками и после этого было найдено порядка 20 неточностей с меню (продукт был очень сырой), если оформлять всё это отсылаясь к определённому шаблону - то очень тяжело будет документировать все найденные баги.