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

[Deuterium]

Леди и джентльмены,

Есть ли у кого-нибудь стандарт ANSI/IEEE 829 (Software test documentation)? По всяким разным рассказам, в нем очень много полезного по обсуждаемому вопросу. Очень бы хотелось детально ознакомиться, но в инете не найду никак.
Намыльте, если не жалко, на eug-ms@kis.ru. Как-нибудь сочтемся :rolleyes:

[meridian]

Я говорил только в контексте нашего разговора! :)
Хотя возвращаясь к примерам есть и такие требования, которые в принципе нельзя (просто "должно быть удобно" скажем, а нельзя потому как всегда будет один кому неудобно - и на что опираться?), но такие требования не должы попадать в тестирование, а отсекаться как нетестируемые ещё на этапе проверки требований на тестируемость.

Ребята, я смотрю, вы тут все напутали и сами заблудились в своих рассуждениях...
1. Нетестируемых требований действительно не бывает
2. От клиентов мы получаем никак не требования, а запросы на изменения, которые в свою очередь обсуждаются группой CCB (Change Control Board), в нее кстате входят тестеры, которая и принимает решение, будет данный запрос оформлен как требование ! (а тестеры смотрят его не предмет тестируемости, если невозможно протестировать, то требование не принимается и обсуждается с клиентом дальше)

[Case]

И снова здравствуйте :)

Пример нетестируемого требования.
"Интерфейс должен быть учше чем у системы XYZ."
Вы как тестировщик возьмётесь тестировать такое требование?

Про CCB это скорее ваша методика работы, чем принятая практика.

[meridian]

И снова здравствуйте :)

Пример нетестируемого требования.
"Интерфейс должен быть учше чем у системы XYZ."
Вы как тестировщик возьмётесь тестировать такое требование?

Про CCB это скорее ваша методика работы, чем принятая практика.

Ну по первых, это общепринятая методика работы - создание группы CCB (в моем случае был разработан адаптированный процесс из RUP)
Ну и еще раз повторюсь, что ...Интерфейс должен быть учше чем у системы XYZ. ... это не требование, а запрос клиента на изменение и надо четко различать эти понятия, т.к. запросы могут быть противоречивы, непонятны, нетестируемы и т.п. А требование это то, что ДОЛЖНО быть реализовано.
Поэтому тестировщики и участвуют в принятии решений при создании требований, чтобы такого бреда избежать...
По моему все предельно просто.
:rolleyes:

[Green]

Case привел не совсем точную формулировку. :-)

Требование может быть описано следующим образом:

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

Это вполне реальное требование к системе. Адресовано оно разработчикам интерфейса. Но не может быть протестировано до тех пор, пока система не будет доведена до стадии испытаний. И тестировать его будут не тестировщики. :-)

[meridian]

Case привел не совсем точную формулировку. :-)

Требование может быть описано следующим образом:

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

Это вполне реальное требование к системе. Адресовано оно разработчикам интерфейса. Но не может быть протестировано до тех пор, пока система не будет доведена до стадии испытаний. И  тестировать его будут не тестировщики. :-)

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

Потом, какае ж это ральное требование ? что будут тестировать тестировщики, интерфейс или отриц .отзывы ?

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

[Kaluga]

Пример нетестируемого требования.
"Интерфейс должен быть учше чем у системы XYZ."
Вы как тестировщик возьмётесь тестировать такое требование?

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

[Kaluga]

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

То есть Вы хотите, что бы пользователь сам интерфейс дизайнил и, по возможности, делал другую работу за ВАС?

[Case]

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

Руководствуясь статьями?
Угу - а заказчик говрить, я не знаю что вы тут ЮЗА тестили - но это однозначно хуже.
Заказчик всегда прав, верно?

[Kaluga]

Не проблема. Просто руководствуйтесь тогда его мнением. =)
Так или иначе есть с чем продукт сравнивать.

[Case]

Руководствоваться его мнением при тестировании? Угу - пусть сам тестит лучше.
Про сравнить - сравниваем ужа и ежа:
семантическая - похожесть в пределах 66,6%
колючесть - в предалах 75%

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

Это не тестируемое требование. По крайней мере в приведённой формулировке.

[Kaluga]

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

[Case]

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

[Kaluga]

Хм... А зачем нам формальные методики везде?
Пусть методики будут формальными в формальных вещах.

[Case]

Я про формализм возразил, когда тестирование свелось к интуитивному восприятию тестировщика.
Дизайн, кстати говоря вещь неформальная? (провоцирую)

[Kaluga]

Про дизайн - ХЗ (не провоцируюсь).
А интуицию вы зря недооцениваете. =)

[Green]

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

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

В идеале этот показатель должен приближаться к равномерному не прерываемому процессу на типовом компьютере (в зависимости от скорости процессора, конечно). Вторым критерием является разница между средним временем установки ОС подготовленного и не подготовленного пользователя. И, естественно, каждый из показателей должен превосходить по скорости показатели предыдущих версий.

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

Но это не означает, что данное требование никак не тестируется. Наоборот, оно тестируется и очень тщательно.