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

[Yaroslav321]

подскажите что не тек с тест кейсом и чек листом

Прикрепленные файлы

•  gD7pRe5.png   13,93К   64 Количество загрузок:
•  JhNCm7p.png   19,58К   3 Количество загрузок:

[vinogradoff]

В классическом тест-кейсе ожидаемый результат относится к конкретному шагу, но опционален. Т.е. например
Шаг 1. - Результат
Шаг 2. - Результат

Шаг 3.
Шаг 4  - Результат.

Результат "Корректная работа ..." - также нетипичен для классических тесткейсов, обычно вводят конкретные данные и получают конкретные результаты ("Кнопка старт вызывает отображение суммы выигрыша").

Для ноу-тест-кейсов (http://sqadays.com/ru/talk/25572), впрочем, описание - в стиле "Сложение двух числе дает корректный результат" вполне допустимо. Тем не менее, если "Корректный результат" не совсем уж тривиальный лучше описать правила его проверки, например "Сумма выигрыша соответствует описанию в абзаце 2 на странице Помощь" (а еще лучше - скопировать ту часть описания в кейс) 

[ch_ip]

2Ярослав:
Прочитайте статью "Что такое тест-кейс и как его писать"

Для ноу-тест-кейсов (http://sqadays.com/ru/talk/25572), впрочем, описание - в стиле "Сложение двух числе дает корректный результат" вполне допустимо. Тем не менее, если "Корректный результат" не совсем уж тривиальный лучше описать правила его проверки, например "Сумма выигрыша соответствует описанию в абзаце 2 на странице Помощь" (а еще лучше - скопировать ту часть описания в кейс)

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

[Yaroslav321]

2Ярослав:
Прочитайте статью "Что такое тест-кейс и как его писать"

Для ноу-тест-кейсов (http://sqadays.com/ru/talk/25572), впрочем, описание - в стиле "Сложение двух числе дает корректный результат" вполне допустимо. Тем не менее, если "Корректный результат" не совсем уж тривиальный лучше описать правила его проверки, например "Сумма выигрыша соответствует описанию в абзаце 2 на странице Помощь" (а еще лучше - скопировать ту часть описания в кейс)

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

Спасибо, статья очень интересная.

[vinogradoff]

Для ноу-тест-кейсов (http://sqadays.com/ru/talk/25572), впрочем, описание - в стиле "Сложение двух числе дает корректный результат" вполне допустимо. Тем не менее, если "Корректный результат" не совсем уж тривиальный лучше описать правила его проверки, например "Сумма выигрыша соответствует описанию в абзаце 2 на странице Помощь" (а еще лучше - скопировать ту часть описания в кейс)

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

Есть правило: всегда избегайте употребления слов "всегда" и "никогда". Из этого правила существует только одно исключение, и оно в предыдущем предложении.
В тривиальных случаях, см. выше. ничего не скрывается. Впрочем, у меня получается избегать словосочетания "корректный результат" почти всегда. Дело вкуса и владения языком.
Про чек-листы, вообще спорить не желаю, я их не использовал в тестировании, и не особо страдаю. ISTQB c вами не согласно, но я и сам не со всем, что ISTQB считает, согласен.

[aya]

подскажите что не тек с тест кейсом и чек листом

Несколько замечаний по чеклисту (это только самая малая часть)

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

1. Чеклист очень поверхностный. Это скорее общий алгоритм. Например, не ясно, как именно был протестирован вход в игру? Были только позитивные тесты или негативные тоже проверялись? Не раз были случаи, когда не логинило, если имейл содержит точку или дефис. Или где гарантия, что вы проверили все надписи на всех страницах, на всех кнопках и т.д.? Далее, что значит "Корректная работа всех кнопок"? Где гарантия, что вы проверили все кнопки? И где гарантия, что ваше понятие корректности работы совпадает с тем, что ожидаем заказчик? 

2. По структуре. Лучше чеклисты делать в excel'e. (Можно расшарить googledocs документ). Виды тестирования разделить по вкладкам. По функциональности дополнительно разделить на блоки: авторизация (вход, регистрация, восстановление пароля, выход), функционал 1, функционал 2 и т.д.

3. По юзабилити. Что значит "понятно как играть"? Почему не используются гайдлайны и подобное?

4. По совместимости. Что значат разные браузеры и ОС? Я могу быть уверена, что вы проверили минимум в каждом из этих браузеров, не используя эмуляторы: IE 7/8/9/10/11, Chrome, Opera 12/24, Firefox, Safari, Yandex? 

По ОС: на каких версиях МАС ОС и Линуксов вы планировали проверять? 

5. По локализации: на каких языках вы будете проверять? На китайском тоже будет проверено? 

6. Ещё по чеклисту. Как им управлять в том виде, что у вас? Как показать, какой процент работы выполнен и какой статус по каждому виду тестирования и по каждой фиче?