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

[Zo0]

Привет.

 

У нас есть кейс, с некоторым количеством шагов, и ожидаемым результатом где-то в "другой" части системы.

 

Вопрос: нам нажно добавлять шаги для перехода (в другую часть программы) и проверки результата или мы просто в ожидаемом результате пишем что там-то и там-то должно получиться то-то?

[vkazar]

Зависит от обстоятельств.

Допустим у нас кейс:
...
n. Вводим в поле "Вася"
n+1. Нажимаем "Сохранить".
...

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

[vkazar]

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

[Zo0]

Вопрос был не в описании ошибки в багтрекере, а в написании тест-кейса.

[vkazar]

Акей. Мне переформулировать свой ответ? Или суть Вы уловили?

 

1. Если "пользователь" (читай - "тестировщик") может посмотреть глазками на результат кейса в том же продукте - путь до результата следует указывать в кейсе.

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

 

Примеры:

п.1:

...
n. Вводим в поле "Вася"
n+1. Нажимаем "Сохранить".
n+2. Переходим в ЛК

Ожидаемый результат: в графе "Имя пользователя" стоит значение "Вася"

п.2:

...
n. В выпадающем списке "Тема обратной связи" выбрать значение "Багрепорт"
n+1. В поле "Текст обратной связи" ввести значение "Текст обратной связи"
n+2. Нажать на кнопку "Отправить"

Ожидаемый результат:
1. На странице отобразилась надпись "Спасибо за обращение!"
2. На адрес support@domain.test пришло письмо
3. Тема письма называется "Багрепорт"
4. Само письмо содержит "Текст обратной связи"

Ну и да, это моё мнение и видение ситуации. Нареканий пока что не было :)

[Zo0]

ок. спс

[clipsa]

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

Если проект большой и часто появляются новые тестировщики, которых надо быстро бросить "в бой", то кейсы должны быть описаны максимально детально. Но у такого подхода есть и минусы - такие тяжелые тесты сложно поддерживать и актуализировать, эффект пестицида тем больше, чем более подробные шаги в кейсах :)

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

[aksi]

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

Если проект большой и часто появляются новые тестировщики, которых надо быстро бросить "в бой", то кейсы должны быть описаны максимально детально. Но у такого подхода есть и минусы - такие тяжелые тесты сложно поддерживать и актуализировать, эффект пестицида тем больше, чем более подробные шаги в кейсах :)

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

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

[clipsa]

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