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

[anka_ua]

Объясню, почему у нас возникла идея использования пользовательских сценариев (если я ошибаюсь в терминологии, прошу быть гуманными)) она а) не совсем прозрачна в принципе б)я в области чуть более чем полгода, посему ссылаюсь на свою неопытность)

В рамках доклада Андрея Дмитриева: "Тестирование ПО: по другую сторону баррикад. Взгляд разработчика" прозвучал тезис, что программисты таки рады, если сначала обнаруживаются критические баги, а не low, связанные с spelling errors и пр..

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

Двигаясь по тест плану, тестировщик, что встретил - то и выписал..

Также, принято, в рамках одного теста проверять одну минимально неделимую функциональность..

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

Идея возникла и с ней ряд вопросов.. часть которых была сформулирована на старте..

Так же возникла еще одна идея, которая скорее близка к юзабилити тестингу ввести такого понятия как "qa ревизор" (условно).. Когда тестировщик проекта пишет use cases и выдает request другому тестировщику, занятому на другом проекте, которым со свежим взглядом/восприятием проходит данные сценарии и может оценить насколько функциональность удобна/понятна + может обладать (специалист) большим опытом и увидеть дефекты, который основной тестировщик упустил..
Идея сырая - еще непонятно, какие временные затраты могут повлечь подобные ревизии и насколько это принесет пользы..
Но тем не менее, предлагаю обсудить ;-)

[CVD1]

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

В своих двух предыдущих постах я пытался раскрыть именно эту тему. Видать, не очень удачно. Но факт есть факт

Так же возникла еще одна идея, которая скорее близка к юзабилити тестингу ввести такого понятия как "qa ревизор" (условно).. Когда тестировщик проекта пишет use cases и выдает request другому тестировщику, занятому на другом проекте, которым со свежим взглядом/восприятием проходит данные сценарии и может оценить насколько функциональность удобна/понятна + может обладать (специалист) большим опытом и увидеть дефекты, который основной тестировщик упустил..
Идея сырая - еще непонятно, какие временные затраты могут повлечь подобные ревизии и насколько это принесет пользы..
Но тем не менее, предлагаю обсудить ;-)

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

[anka_ua]

CVD1, насчет "давайте тестировщикам на прогон тесты, созданные другими, и ставьте задачу дополнить эти тесты."

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

"Также брейнсторм можно проводить перед написанием тест доков при тестовом анализе."

А как насчет проектов, на которых занят один qa специалист? Отрывать от процесса других участников команды?


Возвращаясь к теме топика, хотелось бы понять различие между use cases и use scenario..

"Use Case is a series of steps an actor performs on a system to achieve a goal."

Что такое use scenario?

[LeshaL]

Возвращаясь к теме топика, хотелось бы понять различие между use cases и use scenario..

"Use Case is a series of steps an actor performs on a system to achieve a goal."

Что такое use scenario?

Откуда вы берете такие определения?
Вот тут описание понятия, которое соответствует моему пониманию: http://en.wikipedia.org/wiki/Use_case
Там же есть описание что такое http://en.wikipedia....i/User_scenario

[CVD1]

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

Нет так нет. Решать вам. Я считаю, что на это надо тратить время во имя повышения эффективности тестирования (полноты и корректности).

А как насчет проектов, на которых занят один qa специалист? Отрывать от процесса других участников команды?

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

"Use Case is a series of steps an actor performs on a system to achieve a goal."
Что такое use scenario?

Как вам такое: сценарий использования это логически связанная последовательность случаев использования?
В простом или частном случае сценарий вырождается в случай использования.
В общем или сложном случае последовательность действий пользователя достаточно громоздка для описания одним случаем использования и требует их объединения в сценарий.
Также, для реализации случая использования может потребоваться выполнить сценарий использования.

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

[Clauster]

Объясню, почему у нас возникла идея использования пользовательских сценариев (если я ошибаюсь в терминологии, прошу быть гуманными)) она а) не совсем прозрачна в принципе б)я в области чуть более чем полгода, посему ссылаюсь на свою неопытность)

В рамках доклада Андрея Дмитриева: "Тестирование ПО: по другую сторону баррикад. Взгляд разработчика" прозвучал тезис, что программисты таки рады, если сначала обнаруживаются критические баги, а не low, связанные с spelling errors и пр..

Это, Андрей Дмитриев, видимо, не подумав ляпнул.

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

Двигаясь по тест плану, тестировщик, что встретил - то и выписал..

Также, принято, в рамках одного теста проверять одну минимально неделимую функциональность..

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

Возникает резонный вопрос: а при чем тут пользователь?

Идея возникла и с ней ряд вопросов.. часть которых была сформулирована на старте..

Так же возникла еще одна идея, которая скорее близка к юзабилити тестингу ввести такого понятия как "qa ревизор" (условно).. Когда тестировщик проекта пишет use cases и выдает request другому тестировщику, занятому на другом проекте, которым со свежим взглядом/восприятием проходит данные сценарии и может оценить насколько функциональность удобна/понятна + может обладать (специалист) большим опытом и увидеть дефекты, который основной тестировщик упустил..
Идея сырая - еще непонятно, какие временные затраты могут повлечь подобные ревизии и насколько это принесет пользы..
Но тем не менее, предлагаю обсудить ;-)

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

А вообще, идеального рецепта не существует, вам придется самой ломать голову, ведь только вы знаете специфику своего проекта. Успешный чужой опыт вряд ли сработает, т.к. он в свое время сработал в совершенно другом контексте и вряд ли у вас он такой же. Вместо того, чтобы внедрять чьи то идеи, услышанные на докладе, лучше проанализируйте свой процесс, чего вам реально не хватает или что не работает и боритесь с этим, а потом так же всем будете об этом рассказывать на семинарах :)

[CVD1]

Это, Андрей Дмитриев, видимо, не подумав ляпнул.

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

Возникает резонный вопрос: а при чем тут пользователь?

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

[Фрося]

Это, Андрей Дмитриев, видимо, не подумав ляпнул.

Подумав-подумав.
Это я как разработчицей проработавшая много времени говорю.

Да. Сначала - критичные. Потом - второстепенные.

[ch_ip]

В рамках доклада Андрея Дмитриева: "Тестирование ПО: по другую сторону баррикад. Взгляд разработчика" прозвучал тезис, что программисты таки рады, если сначала обнаруживаются критические баги, а не low, связанные с spelling errors и пр..

Это, Андрей Дмитриев, видимо, не подумав ляпнул.

Андрей сказал это, хорошо подумав.

Он сказал это подумав, как программист, с точки зрения которого spelling errors - это мелочь. С точки же зрения выпуска качественного продукта spelling errors бывают очень разные по степени критичности - от Trivial в глубинах пользовательской документации до Critical - в основном меню, информации о компании и т.д. Например, опечатка в копирайте может влететь фирме в копеечку.
В соседней ветке недавно обсуждали пример выпуска продукта с матерным словом в меню, а Алексей Лупан приводил замечательный пример с Баша про поток рекламаций на "шуточное" сообщение об ошибке, которое не отловили при тестировании.

[Фрося]

Он сказал это подумав, как программист, с точки зрения которого spelling errors - это мелочь. С точки же зрения выпуска качественного продукта spelling errors бывают очень разные по степени критичности - от Trivial в глубинах пользовательской документации до Critical - в основном меню, информации о компании и т.д. Например, опечатка в копирайте может влететь фирме в копеечку.

Нюанс есть.
Программисту spelling errors убрать как правило - не сложно, не трудоемко.
По времени не сильно затратно.

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

Программисту-то тоже время свое планировать надо.

[CVD1]

Он сказал это подумав, как программист, с точки зрения которого spelling errors - это мелочь.

Это тривиальная ситуация. Используются аттрибуты бага приоритет (priority) и сложность исправления (severity).
То есть misspell bug may have Blocking priority, Minor severity.

Вообще-то, уходим от темы.

[Clauster]

Это, Андрей Дмитриев, видимо, не подумав ляпнул.

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

Я правильно понимаю, что для вас не существует разницы между критичностью и серьезностью ошибки? Вам сложно представить ситуацию, в которой ошибка правописания может быть критичной?

Возникает резонный вопрос: а при чем тут пользователь?

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

Я, если честно, не понял зачем вы написали свои догадки, или вы и топик-стартер один и тот же человек?

[Clauster]

Это, Андрей Дмитриев, видимо, не подумав ляпнул.

Подумав-подумав.
Это я как разработчицей проработавшая много времени говорю.

Да. Сначала - критичные. Потом - второстепенные.

И что, spelling error не может быть критичной? На мой взгляд, критичность грамматических ошибок довольно высока. Это я как разработчиком, тестировщиком и саппортом проработавший много времени говорю.

[CVD1]

Я, если честно, не понял зачем вы написали свои догадки, или вы и топик-стартер один и тот же человек?

Воспринял ваши реплики всерьез и ответил только по той причине, что топик стартер вроде как не очень опытный пока.

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

[Clauster]

Я, если честно, не понял зачем вы написали свои догадки, или вы и топик-стартер один и тот же человек?

Воспринял ваши реплики всерьез и ответил только по той причине, что топик стартер вроде как не очень опытный пока.

Ну а я на полном серьезе задал вопрос ТС, смайликов там нема. Я вижу, что опыта мало, потому и спрашиваю, почему они обычные чек-листы называют пользовательскими сценариями.

[Clauster]

Я, если честно, не понял зачем вы написали свои догадки, или вы и топик-стартер один и тот же человек?

Воспринял ваши реплики всерьез и ответил только по той причине, что топик стартер вроде как не очень опытный пока.

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

А я смотрю вы довольно толстый тролль

[Clauster]

..

[anka_ua]

Мы не называем чек листы пользовательскими сценариями... эт так, на всякий случай..

Идея всего топика, услышать об опыте использования use cases в тестировании...

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

В любом случае, я благодарна всем принявшим участие в дискуссии, и сейчас готовлю материал, который будет обсужден нашей qa тимой в рамках круглого стола (Сразу замечу, что коллектив у нас состоит из сильных qa, а вести круглый стол я вызвалась, так как для меня
то новый и интересный опыт)

С всеобщего позволения, я выложу приготовленный материл ДО и ПОСЛЕ круглого стола на ваш суд :-)

К критике отношусь вполне спокойно, потому замечания о неверное/новой и пр трактовке общеизвестных терминов не боюсь :)

Подытожив, скажу, все огромное спасибо за высказанное мнение

[LeshaL]

В рамках доклада Андрея Дмитриева...

Это, Андрей Дмитриев, видимо, не подумав ляпнул.

Андрей сказал это, хорошо подумав.

Он сказал это подумав, как программист, с точки зрения которого spelling errors - это мелочь...

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

С точки же зрения выпуска качественного продукта spelling errors бывают очень разные по степени критичности - от Trivial в глубинах пользовательской документации до Critical - в основном меню, информации о компании и т.д. Например, опечатка в копирайте может влететь фирме в копеечку.
В соседней ветке недавно обсуждали пример выпуска продукта с матерным словом в меню, а Алексей Лупан приводил замечательный пример с Баша про поток рекламаций на "шуточное" сообщение об ошибке, которое не отловили при тестировании.

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

[Clauster]

Мы не называем чек листы пользовательскими сценариями... эт так, на всякий случай..

Идея всего топика, услышать об опыте использования use cases в тестировании...

Но вы то назвали. Дело в том, что терминология в тестировании ещё не совсем устоялась, поэтому так много разногласий. Набор тест-кейсов это не юзкейс и не пользовательский сценарий.