СФ
На таком уровне ок, но наполнить этот тест конкретными шагами ты не сможешь
Size: a a a
2020 September 06
n
То, что вы выше писали - дверь зеленая, проем 10 на 20 и так далее
А можно синонимы подобрать? 😂
AG
Что значит пишутся по контракту?
Контракт, в данном контексте: спецификация интерфейса взаимодействия.
Напр: набор полей и структура запроса к определённому методу апи.
Напр: набор полей и структура запроса к определённому методу апи.
AG
На таком уровне ок, но наполнить этот тест конкретными шагами ты не сможешь
А надо?
СФ
А в чем практический смысл писать сторю но другими словами?
AG
А в чем практический смысл писать сторю но другими словами?
Смысл в том, на одну стори у тебя будет N тесткейсов.
Условно: отображение такого заказа в админке, триггеры рассылок, етк.
И здесь, как и у любых тест кейсов есть три задачи: очертить круг проверок, создать артефакты тестирования (прозрачность) и подсветить возможные конфликты на этапе тест-дизайна.
Условно: отображение такого заказа в админке, триггеры рассылок, етк.
И здесь, как и у любых тест кейсов есть три задачи: очертить круг проверок, создать артефакты тестирования (прозрачность) и подсветить возможные конфликты на этапе тест-дизайна.
AG
При этом все три задачи так или иначе выполняются, даже если конкретных шагов у тебя нет.
AG
По мере появления реализации (и необходимости) ты эти кейсы можешь дополнять, а можешь просто закинуть в регресс в таком виде, если задачи тестирования они в таком виде закрывают.
СФ
Звучит разумно
AG
Ну и кстати, для фичей с уже известной реализацией я бы делал ровно так же.
AG
Писать подробные тесткейсы нужно тогда, когда ты понимаешь зачем они такие нужны.
AG
В остальных случаях тестовых сценариев (которые по сути являются пересказом юзерсторей но в тмс) - достаточно.
СФ
Наверное, это даже правильнее в общем случае
СФ
Так как в моем кейсе на этапе проектирования тестировщики блокируются
2020 September 07
C
Зиг хайль
C
* /
S
Ребята, не успеваю писать тест кейсы для каждого тикета, который открывают/закрывают мои разработчики.
До этого тестеров в компании не было и все хотят, чтобы тикет "быстренько" проверялся.
До этого тестеров в компании не было и все хотят, чтобы тикет "быстренько" проверялся.
S
Я понимаю, что для проверки нужно потратить время, документацию написать...но это, как правило, занимает время, а проектов много и тикетов много
S
И вот не знаю, проверять все "быстренько" отталкиваясь от опыта и логики...или тратить время и писать текст-кейсы постоянно и затягивать деплой