Перейти к содержимому

Фотография

Зависимость тест-кейсов

зависимость тест-кейсов зависимость

  • Авторизуйтесь для ответа в теме
Сообщений в теме: 2

#1 Murat_Minsk

Murat_Minsk

    Новый участник

  • Members
  • Pip
  • 14 сообщений
  • ФИО:Исламбеков Мурат

Отправлено 20 апреля 2015 - 23:04

Добрый день,

 

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

 

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

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

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

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

...

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

 

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

 

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

 

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

 

 


  • 0

#2 bu4er

bu4er

    Постоянный участник

  • Members
  • PipPipPip
  • 195 сообщений
  • ФИО:Шмыга Артём


Отправлено 21 апреля 2015 - 06:13

На реальном проекте будет так как там привыкли или как договоришься с менеджером.

У меня был проект где 6 шагов(6 разных страниц) шли друг за другом и я не описывал предыдущие 5 шагов если тест кейс был для шага 6.
Но в моем случае предыдущий шаг не влиял на следующий шаг. Тогда достаточно просто корректных данных в предыдущих шагах как предусловие тест кейса либо пишешь в шагах тест-кейса - шаги с 1 по 5 заполнить корректными данными(и можно написать какими).

Если я правильно понял описываемую тобой ситуацию.

Однако если есть какая то прямая зависимость когда например шаг 3 определяет какие поля будут в шаге 4, тогда тебе нужно писать это либо как предусловие тест-кейса(если это не должно повлиять на появление бага), либо как шаг воспроизведения тест-кейса(если это может повлиять на появление бага).

Но это все рассуждения.

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


  • 0

#3 clipsa

clipsa

    Специалист

  • Members
  • PipPipPipPipPip
  • 527 сообщений
  • ФИО:Ермолаева Ольга
  • Город:Москва


Отправлено 21 апреля 2015 - 12:31

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

 

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

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

 

Такая система подходит для большой распределенной команды, особенно, если состав команды постоянно расширяется/меняется.

Для маленьких команд вполне подойдет чек-лист или очень кратко и вольно описанные полу-тест-кейсы))

 

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

 

ИМХО :)


  • 1

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



Количество пользователей, читающих эту тему: 0

0 пользователей, 0 гостей, 0 анонимных