Murat_Minsk

Добрый день,

в книге Савина, при описании тест-кейса сказано, что тест-кейс должен быть максимально независим(по времени и порядку, в котором он выполняются), чтобы исключить ситуации, когда главный тест-кейс изменяется/удаляется, и как следствие зависимые тест-кейсы теряют нужный контекст,а также чтобы дать возможность выполнять тест-кейсы в любом порядке. Вместо такой связи предлагается использовать секцию: Setup and additional information, в которую помещать общие шаги для тест-кейсов(а также ресурсы).

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

На сколько я понял из Савина, в этом случае эти шаги нужно оформлять общими словами, без деталей, например для пошаговой формы шага 2 - это будет звучать как:

шаг 1. корректно заполняем данные для шага 1;

шаг 2. тестируем логику шага 2.

...

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

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

Может кто-то сможет указать, как проблема решается на реальном проекте?

Заранее спасибо.

Добрый день,

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

Вопрос в следующем, если кнопка возле формы Open File, называется "Загрузить отсканированный документ", должно ли в ней при выборе фильтрации быть возможность показывать все файлы (All Files)? На мой взгляд, логично было бы оставить отображение только документов подпадающих под необходимые форматы, в данным случае: jpg, jpeg, png и тд..

Также у меня на этой форме есть выбор из html файлов. И опять вопрос, на сколько он здесь подходит(в общем случае)?

Возможно, кто-то сможет поделится своим опытом в данном вопросе?

Пока я написал следующее:

Здравствуйте,
 
написал несколько тест-кейсов для стандартной формы, которая содержит два поля: Name и Email, но пока есть неуверенность по поводу, как полноты описания, так и "не добавил ли я чего лишнего":)

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

Заранее спасибо.

Всем привет,

при написании тест кейсов возник вопрос.

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

Пока придумал 3 варианта: 

1. Дублировать для каждой страницы эти проверки. Но, как по мне это не рационально, тк например если для каждой страницы на сайте, дублироваться тест-кейсы для хидера и футера + также дублировать тест-кейсы для юзабилити тестирования, то размер документа(для моего сайта) увеличивается больше чем в 2 раза. Да и дублирования к ничему хорошему не приведет - если поменялся один тесткейс, то менять его для всех страниц на сайте? а если их много?

2. Вывести общие тест-кейсы в отдельные модули(usability, header,footer), и вставлять их для каждой новой страницы как ссылку. Причем результаты тестирования для каждого нового модуля выносить в отдельную колонку(общего модуля) с фактическим результатом. Но тут тоже не удобно, тк страниц много, в моем случае их 15, то количество колонок с фактическим результатом увеличивается в число равное количеству страниц сайта(для меня в 15 раз!), а учитывая, что проверять нужно для разных браузеров(на каждый браузер отдельная колонка с результатом) + с учетом дополнительных настроек: вкл/выкл - javascript или flash - количество колонок становится запредельным.

3. Тестировать хидер и футер отдельно, а в остальных страницах тестировать только уникальный контент. Но тут сразу вопрос, где гарантия что если поиск на хидере работает на одной странице он не будет падать на другой?

Подскажите пожалуйста, как оформить тестовый документ в таких ситуациях? Может у кого-то есть пример с решением подобной проблемы?

Заранее спасибо.

Добрый день,

провожу usability тестирования макета сайта. При этом макет является картинкой готового продакшен сайта заказчика.

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

Немного запутался, как мне поступить в таком случае?

С уважением, Мурат.