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

[barancev]

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

[Clauster]

Открою вам тайну: Андрей сказал, что в первую очередь, когда программист отдает что-то в тестирование ему важно узнать работает ли этот функционал или нет, это самое важное. Все остальные ошибки вторичны. Это не значит, что они никому не нужны. И сказал он это не только подумав, и не только как программист, но и обсудив это с тестировщиком, то бишь со мной. И кто был на моем докладе, слушал подобную же мысль: "если программа не работает, то не важно как удобно она не работает". Более того, я слышал такие мысли от других программистов, а некоторые даже в открытую говорили, что их плохо тестируют, потому что сначала сыпется куча поверхостных и нефункциональных багов и люди думают, что все у них хорошо; а потом оказывается, что в логике программы ошибки, но тестировщик этого не видит.

Это очень ценное замечание, спасибо.Куча поверхностных багов это нормально, от них никуда не денешься, иначе они могут впоследствии замылиться. Плохо если серьезные проблемы при этом не обнаруживаются. Обычно такое свойственно для тестирования на уровне багхантинга. Также я допускаю, что имея даже кучу пользовательских сценариев, вскоре программа "научится" их проходить (тот самый эффект пестицида), поэтому предложенный вначале вариант в перспективе будет неэффективным.

Несомненно все это так. Большинство таких проблем решается статическим анализом. Можно даже баги не писать, можно писать - кому как удобнее. Но отвлекать программиста на мелочи, когда в тестируемой области есть реально высокоприоритетные проблемы - не будет хорошо ни тестеру, ни программисту, ни программе. Один из первых уроков в Lessons Learned говорит: find important bugs fast. Собственно об этом и речь.

Все-таки я буду настаивать что подобные мелочи могут быть высокоприоритетными проблемами, это все от контекста зависит конечно. Но урок правильный и я в свое время даже перевел его http://bugsclock.blo.../blog-post.html

[LeshaL]

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

Дело в том, что вопрос вроде как совсем в другом. Автор топика так и не сказала, что конкретно ее итересует - use cases или user scenarios. Судя по приведенному определению - user scenarios.
Т.е. в данный момент я так понимаю вопрос: не лучше ли вместо тест-кейсов руководствоваться пользовательскими сценариями и если времени мало, то проводить тестирование только по ним, а не распыляться на проверку разных разностей в рамках одного сценария.

[barancev]

Дело в том, что вопрос вроде как совсем в другом. Автор топика так и не сказала, что конкретно ее итересует - use cases или user scenarios. Судя по приведенному определению - user scenarios.
Т.е. в данный момент я так понимаю вопрос: не лучше ли вместо тест-кейсов руководствоваться пользовательскими сценариями и если времени мало, то проводить тестирование только по ним, а не распыляться на проверку разных разностей в рамках одного сценария.

С одной стороны верно, хорошо бы выяснить, что имел в виду топик-стартер. Но с другой стороны, на вопросы можно отвечать ответом, а не встречным вопросом :)
Можно сказать, что если требования написаны вот в таком виде (как бы оно ни называлось), то тесты из них можно делать вот так и так.

Вот ты же сам подразумеваешь под словами "тест-кейс" и "пользовательские сценарии" какие-то штуки, которые я может быть называю иначе, а этими словами называю что-то своё. И в результате, ты как-то понимаешь вопрос, но я не понимаю, как ты его понимаешь и понимаешь ли ты его так же, как топик-стартер.

Хм.. Ничё я так написал для первого часа ночи? :)

[barancev]

Добавлю конструктива прямо сейчас, Анна может быть Вам пригодится при подготовке круглого стола. Выложил свою презентацию с РИТ-2010, которая называлась "Дизайн тестов на основе вариантов использования". Хозяева конференции обещали сделать видео, но увы, не сделали. Без моих пояснительных речей, конечно, не всегда понятно, что там на слайдах написано и с какой целью. Но уж не обессудьте, делюсь тем, что есть. А в пятницу я ещё допишу кое-что, про что я на РИТ не стал говорить, но зато рассказывал на тренингах.

[astenix]

Без моих пояснительных речей, конечно, не всегда понятно, что там на слайдах написано и с какой целью.

Наговори на кухне на диктофон хоть десять минут толкований - расшифруем-с, потом текст будет проще всего дополнить, если будет необходимость.

[Фрося]

Тут нашла внятное (для меня) разъяснение, что есть вариант использования и что - сценарий

http://www.intuit.ru...basics/4/2.html

табл. 4.3.

"1. Клиент вставляет кредитную карточку в устройство чтения банкомата"
2. Банкомат проверяет кредитную карточку
3. Банкомат предлагает ввести ПИН-код
"
(это сценарий, ОК?)

Можно тоже самое записать так:
1. Банкомат должен обеспечивать возможность вставки кредитной карты в устройство чтения;
1.1 Банкомат должен обеспечивать проверку кредитной карточки, вставленной в устройство чтения, на соответствие требованиям, предъявляемым к кредитным картам для данного банкомата;
1.2.3 В случае соответствия - банкомат должен вывести сообщение о необходимостии ввода пин-кода
1.2.4 В случае несоответствия ... (какие-то другие действия).

(это НЕ сценарий?)
А теперь, может уважаемые гуру объяснят мне. При тестировании этого несчастного банкомата - какая разница - как именно записаны требования? В форме сценария или нет?

[LeshaL]

Тут нашла внятное (для меня) разъяснение, что есть вариант использования и что - сценарий

http://www.intuit.ru...basics/4/2.html

табл. 4.3.

"1. Клиент вставляет кредитную карточку в устройство чтения банкомата"
2. Банкомат проверяет кредитную карточку
3. Банкомат предлагает ввести ПИН-код
"
(это сценарий, ОК?)

Можно тоже самое записать так:
1. Банкомат должен обеспечивать возможность вставки кредитной карты в устройство чтения;
1.1 Банкомат должен обеспечивать проверку кредитной карточки, вставленной в устройство чтения, на соответствие требованиям, предъявляемым к кредитным картам для данного банкомата;
1.2.3 В случае соответствия - банкомат должен вывести сообщение о необходимостии ввода пин-кода
1.2.4 В случае несоответствия ... (какие-то другие действия).

(это НЕ сценарий?)
А теперь, может уважаемые гуру объяснят мне. При тестировании этого несчастного банкомата - какая разница - как именно записаны требования? В форме сценария или нет?

На мой взгляд да, первое сценарий, второе - нет.
Разница в том, что сценариев больше. Шаги могут быть преставлены местами, повторяться, пропускаться (иметь оговоренные значения по умолчанию) и тд. Взять хотя бы простейшую state машину (ну например жизненый цикл дефекта из 5-ти состояний). Сценариев прохождения от входного состояния NEW до CLOSED будет порядочно, а правил переходов - только по количеству transition links. Проще описать эти правила.

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

[Фрося]

На мой взгляд да, первое сценарий, второе - нет.

ОК.
Мне тоже так кажется.

Т.е. функционирование одного и того же объекта можно описать как сценарий и как НЕ сценарий.
Пусть требования к банкомату написаны в виде НЕ сценария.
Имеет ли смысл тогда использовать (т.е. сначала - сочинить сценарий, а потом уже использовать) сценарий при проведении тестирования банкомата?

[Clauster]

На мой взгляд да, первое сценарий, второе - нет.

ОК.
Мне тоже так кажется.

Т.е. функционирование одного и того же объекта можно описать как сценарий и как НЕ сценарий.
Пусть требования к банкомату написаны в виде НЕ сценария.
Имеет ли смысл тогда использовать (т.е. сначала - сочинить сценарий, а потом уже использовать) сценарий при проведении тестирования банкомата?

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

[LeshaL]

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

Имеет, а как же иначе-то тестировать? В голове-то ведь все-равно возникает некий сценарий действий для каждого конкретного теста.
А вот надо эти сценарии фиксировать где-то и как-то - это совсем другой вопрос.

[Фрося]

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

Имеет, а как же иначе-то тестировать? В голове-то ведь все-равно возникает некий сценарий действий для каждого конкретного теста.
А вот надо эти сценарии фиксировать где-то и как-то - это совсем другой вопрос.

Ок.
Т.е. получается - что сценарий ВСЕ РАВНО пишем. И тестируем по сценарию? (я пытаюсь вернуться к первому посту обсуждения)

[Clauster]

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

Имеет, а как же иначе-то тестировать? В голове-то ведь все-равно возникает некий сценарий действий для каждого конкретного теста.
А вот надо эти сценарии фиксировать где-то и как-то - это совсем другой вопрос.

Ок.
Т.е. получается - что сценарий ВСЕ РАВНО пишем. И тестируем по сценарию? (я пытаюсь вернуться к первому посту обсуждения)

ПИСАТЬ его восе не обязательно, также как и тест-кейсы.