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

[Morovinger]

Занимаясь в данный момнет тест-дизайном столкнулся с дилеммой. 

Имеем пример. Веб приложение.С карточками заполненными полями с информацей. 
Через выпадающее меню карточки можно:
1. Сворачивать.
2. Разворачивать.
3. Удалять.
4. Восстанавливать.
Правильно ли я делаю, что разделяю тест кейсы на каждое действие? 
Если да, то сталкиваемся с проблемой. Перед всеми этими действиями есть список из 10+ предусловий. По скольку тесты должны быть изолированы, эти предусловия надо повторять в каждом тест кейсе? 

Или же надо делать один большой тест кейс "Тестирование действий с карточкой" в котором предусловия выполняются 1 раз? 

Но тогда если потом автоматизировать этот тест или вести какую то статистику, то завалится он в одном месте, но за собой завалит весь остальной огромный кейс. 

[Vasiliy]

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

[astenix]

Через выпадающее меню карточки можно:

1. Сворачивать.
2. Разворачивать.
3. Удалять.
4. Восстанавливать.
Правильно ли я делаю, что разделяю тест кейсы на каждое действие?

 

Правильно, но подумайте о том, что тестами надо покрывать задачи, а не действия в приложении.

 

Один, но большой тест-кейс делать не надо, это путь в менеджмент тестирования и соответствующий ежедневный дурдом.

[Vasiliy]

...
это путь в менеджмент тестирования и соответствующий ежедневный дурдом.

Да, ладно, здесь прикольно!  

[Morovinger]

 

Через выпадающее меню карточки можно:

1. Сворачивать.
2. Разворачивать.
3. Удалять.
4. Восстанавливать.
Правильно ли я делаю, что разделяю тест кейсы на каждое действие?

 

Правильно, но подумайте о том, что тестами надо покрывать задачи, а не действия в приложении.

 

Один, но большой тест-кейс делать не надо, это путь в менеджмент тестирования и соответствующий ежедневный дурдом.

 

Хм. Я с одной стороны понимаю разницу, а с другой стороны не очень. Под задачей понимается юзер стори или бизнес кейс? 
У нас к сожалению часто бывает, что отваливаются прямо с одной стороны казалось бы не зависимые друг от друга части в очень не обычных местах). 

 

 

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

 

На сколько это правильно что бы тесты кейсы были не однородные? 

 

И тогда ещё вопрос. Я конечно понимаю, что многое зависит от проекта, но в среднем по больнице на сколько полные должны быть тест кейсы конкретно для регресса? Должен ли регресс содержать в себе все тесты входящих в него фич? 

[Vasiliy]

Зависит "от больницы". Договоритесь в команде между собой и утвердите. Не понравится - поменяете через полгода.

Что такое неоднородные тест-кейсы?

[Morovinger]

Зависит "от больницы". Договоритесь в команде между собой и утвердите. Не понравится - поменяете через полгода.

Что такое неоднородные тест-кейсы?

 

Ну когда одна часть функционала описана допустим по правилам с предусловиями, тестами, постусловиями. Другая часть функционала просто чек листом, а третяя это огромная табличка в экселе, так как по другому нельзя)) 

[Vasiliy]

Ну когда одна часть функционала описана допустим по правилам с предусловиями, тестами, постусловиями. Другая часть функционала просто чек листом, а третяя это огромная табличка в экселе, так как по другому нельзя))

И что из этого?
Описанное состояние является проблемой? Я не очень понимаю вопрос)

[Spock]

 

 

Должен ли регресс содержать в себе все тесты входящих в него фич? 

теоретически должен, а практически не должен

 

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

[astenix]

Под задачей понимается юзер стори или бизнес кейс?

Под тест-кейсом подразумевается инструкция по выполнению какой-то задачи.

 

Обычно тестировщик пырится в экран и последовательно описывает какие-то действия на наблюдаемом экране. И начинаются проблемы: «А тут можно сделать сразу много всякого, мне что, всё это описывать по-отдельности? Я же дошёл до одного экрана. Давайте я сделаю один, но большой тест-кейс, в котором будет описано всё то, что можно сделать «на одном экране».

 

Об этом и предупреждение.

[Morovinger]

Я подведу итог. Правильно ли я понял?

1. Тесты кейсы могут быть любого вида главное что бы было удобно команде, заказчику и т.д. 

2. Один тест кейс не должны содержать в себе проверку разных функций программы даже, если они к примеру часть одного элемента интерфейса.

3. Тесты должны быть изолированы и предусловия в 10+ пунктов это нормально.

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

 

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

[astenix]

// С одной стороны вроде очевидные вещи, но когда с ними сталкиваешься ...

Именно поэтому все делятся на джунов и синиоров. Опытные — удивлялимь, страдали, искали решения и приходили к выводам. Неопытные пытаются обойтись без страданий и перескочить к готовым решениям.

[Vasiliy]

Я подведу итог. Правильно ли я понял?
1. Тесты кейсы могут быть любого вида главное что бы было удобно команде, заказчику и т.д.
2. Один тест кейс не должны содержать в себе проверку разных функций программы даже, если они к примеру часть одного элемента интерфейса.
3. Тесты должны быть изолированы и предусловия в 10+ пунктов это нормально.
4. Надо соблюдать баланс между количеством тестов в регрессе и временем на его выполнение.

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

Верно, но 10+ предусловий мне кажется перебором..