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

[Paranoid]

Изучаю тестирование, возник такой вопрос.

 

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

 

Пример тест-кейса:

Идея ТК: совершение покупки в интернет-магазине

...

Ожидаемый результат:

1. сообщение "спасибо за покупку!" на экране

2. на email приходит подтверждение заказа

3. платеж с карты клиента успешно прошел

 

И вот слушаю очередную лекцию, где лектор объясняет преимущества чек-листов. И есть такой момент -- тестируем текстовый редактор, в частности при нажатии "Save" видим диалоговое окно "Save" или "Cancel".

 

Пример пункта в чек-листе:

Нажимаем кнопку кнопку "Cancel"

Ожидаемый результат:

1. диалоговое окно "сохранить документ?" закрылось

2. изменения не сохранены

3. кнопка "Save" остается активной

 

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

 

Вот и думаю -- неужели это так? Как раз встречал в нескольких источниках, что может быть несколько ожидаемых результатов в тест-кейсе....

 

Поэтому вопрос: если бы нужно было написать тест-кейс для тестирования этой кнопки "Cancel" при сохранении текста в текстовом редакторе, можно было бы вышеназванные ожидаемые результаты поместить в один тест-кейс или действительно пришлось бы писать три отдельных?

 

Спасибо!

[Freiman]

1. Можно в один

2. Результат "изменения не сохранены" лучше переформулировать, потому что мы не очень знаем, как убедиться, что изменения действительно не сохранены. Было бы лучше что-то вроде "Не создается новый файл", "изменения не записаны в файл" итп

[Little_CJIOH]

так там один ожидаемый результат: "Сохранение отменено"(Диалоговое окно закрылось, Файл не изменился, кнопка сейв активна).

 

А вот в первом примере косяк на косяке.
прохождение оплаты - это обязательное условие, а не ожидаемый результат.

Ну и раз уж платеж совершен, то приходит не подтверждение заказа, а подтверждение покупки.

[Paranoid]

Спасибо за ответы.

 

 

А вот в первом примере косяк на косяке.

прохождение оплаты - это обязательное условие, а не ожидаемый результат.

Ну и раз уж платеж совершен, то приходит не подтверждение заказа, а подтверждение покупки.

 

Можно подробнее?

 

В чем отличие обязательного условия от ожидаемого результата?

 

И при покупке в интернет-магазинах приходит письмо "Order confirmed".

[astenix]

Что такое тест-кейс?

[Paranoid]

Что такое тест-кейс?

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

[astenix]

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

 

Процитированный вами тест-кейс — Совершение покупки в интернет-магазине — это не тест-кейс. Это целая история использования, по-американски называемая "user story". В контексте этой юзер-стори можно распознать много отдельных ситуаций (тест-кейсов).

 

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

 

Вам, тестировщику, надо продумывать ситуации, которые могут быть созданы с вашим объектом тестирования посредством каких-то действий. Записали рассказ о том, как создать какую-то ситуацию (искусственным образом, естессно) — вот и получился тест-кейс. И это почти всегда НЕ набор из входных и выходных данных, это рассказ о действиях, в ходе которых иногда используются какие-то входные данные, а иногда нет, но тест-кейс от этого в тыкву не превращается.

 

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

 

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

 

Пример — Залогиниться в почту, в браузере.

 

Что изменится после выполнения этой задачи (после создания этой ситуации)? Много чего:

1. Исчезнет форма логина.
2. появится указание имени залогиненного юзера
3. появится список папок
4. появится список писем
5. появится возможность создавать [а также читать, удалять, кликать, даблкликать, перенаправлять, игнорировать] письма
6. … много ещё всякого

Действие было одно — залогиниться. А результат вон какой многочленный.

 

А можно то же самое передать одним результатом: юзер залогинился.

 

Какой способ правильнее? Как правильно сформулировать ожидаемый результат?

 

Очень рекомендую не зацикливаться на одном только лекторе (но для Баранцева сделайте исключение).

 

А утверждение о том, что такое может быть только (!) в чек-листах — ложное, порождённое этим принудительным сведением явления к «набору из входных и выходных данных». По возможности, избегайте таких суждений.

 

Например, вы сможете протестировать консервную банку с тушёнкой с тестами типа «какие-то входные данные»? В чём будет выражаться ваш набор из входных и выходных данных в отношении банки? Тут надо какие-то действия делать, а не пихать в банку входные данные… Надо последовательно продумать ситуации использования этой банки/ПО, затем последовательно создавать эти ситуации и сравнивать наблюдаемый результат с ожидаемым.

[astenix]

Кстати, по-испански тест-кейс называется намного лучше чем по-русски или даже по-английски: Caso de prueba, и обратно это переводится как «прецедент».

 

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

 

Об этом даже в ихней испанской википедии очень понятно написано:

 

Un caso de prueba (o test case) es, en ingeniería del software, un conjunto de condiciones o variables bajo las cuales un analista determinará si una aplicación, un sistema software (software system), o una característica de éstos es parcial o completamente satisfactoria.

 

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