Перейти к содержимому

Публикации CVD1

52 публикаций создано CVD1 (учитываются публикации только с 29 марта 2023)



#82444 Вопрос про классы эквивалентности на CD

Отправлено автор: CVD1 23 декабря 2010 - 10:11 в Личный рост, карьера, развитие

Думаю, да. Но it depends ;-)



#82401 Pesticide Paradox

Отправлено автор: CVD1 22 декабря 2010 - 13:59 в Портал Software-Testing.Ru

Понял вас ;-)



#82378 Визуальные подтверждения багов

Отправлено автор: CVD1 22 декабря 2010 - 10:21 в Про тестирование обо всём подряд

Я стараюсь всегда помещать скриншот для наглядности за исключением совсем тривиальных случаев. Видео делал давно, когда не хватало словарного запаса для описания.



#82364 Pesticide Paradox

Отправлено автор: CVD1 22 декабря 2010 - 07:26 в Портал Software-Testing.Ru

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

Есть банальная мысль: как интерпретировать ситуацию, когда каждый раз при выдаче новой версии надо удостовериться, что важный функционал работоспособен, набор тестов не должен меняться и это не пестицид, а великолепная стабильность? Или я как капитан очевидность, но не в ту степь?
Это еще нигде не обсуждалось?



#82344 Вопрос про классы эквивалентности на CD

Отправлено автор: CVD1 21 декабря 2010 - 18:35 в Личный рост, карьера, развитие

P.S. До того собеседования я к сожалению или счастью не дошла - устроилась на работу раньше. Но вопрос все равно интересен. Мало ли, мож еще пригодится.

Ничего, что я влезаю? Куда устроились?



#82342 Вопрос про классы эквивалентности на CD

Отправлено автор: CVD1 21 декабря 2010 - 18:33 в Личный рост, карьера, развитие

почему если я работал 5 лет тяпкой она мне должна осточертеть? Почему я не могу от нее тащиться? Почему я как специалист по тяпкам не могу искать работу по причинам отличным от того что мне тяпка надоела?

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

Согласен на 100 процентов.



#82334 Обсуждение второй встречи клуба MSTC

Отправлено автор: CVD1 21 декабря 2010 - 16:29 в Московский клуб тестировщиков

Не все, я тугодум :fool:



#82331 Обсуждение второй встречи клуба MSTC

Отправлено автор: CVD1 21 декабря 2010 - 15:48 в Московский клуб тестировщиков

Большое спасибо организаторам и докладчикам. Весьма полезно, хотя и не идеально.
Давайте еще.
Если не забуду и не поленюсь, напишу отзыв подробнее.
Ps: По-моему я поставил рекорд - был единственным в зале не владельцем ноутбука.
:crazy:



#82207 Инструменты для воспроизведения багов

Отправлено автор: CVD1 20 декабря 2010 - 08:10 в Тест-дизайн и ручное тестирование

Спасибо, я так и подумал ;-)



#82202 Инструменты для воспроизведения багов

Отправлено автор: CVD1 20 декабря 2010 - 07:38 в Тест-дизайн и ручное тестирование

psr в 7ке

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



#82194 Вопрос про классы эквивалентности на CD

Отправлено автор: CVD1 19 декабря 2010 - 19:17 в Личный рост, карьера, развитие

Познавательная тема. Интересно было бы узнать у Miaka результат собеседования.



#81962 Вторая встреча тестировщиков в Москве

Отправлено автор: CVD1 15 декабря 2010 - 15:53 в Московский клуб тестировщиков

В Москве беспорядки, встреча не будет отменена?



#81419 Use cases: КАК и ЗАЧЕМ

Отправлено автор: CVD1 07 декабря 2010 - 19:01 в Тест-дизайн и ручное тестирование

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

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

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



#81349 Use cases: КАК и ЗАЧЕМ

Отправлено автор: CVD1 07 декабря 2010 - 09:46 в Тест-дизайн и ручное тестирование

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

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

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



#81335 Тестовое задание "ListBoxer".

Отправлено автор: CVD1 07 декабря 2010 - 07:13 в Тест-дизайн и ручное тестирование

Поддерживаю предложение :acute:



#81333 Use cases: КАК и ЗАЧЕМ

Отправлено автор: CVD1 07 декабря 2010 - 07:11 в Тест-дизайн и ручное тестирование

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

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

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

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



#81304 Тестовое задание "ListBoxer".

Отправлено автор: CVD1 06 декабря 2010 - 18:26 в Тест-дизайн и ручное тестирование

Кто же просит о помощи за два дня до сдачи? Халява приди? Прям обязательно кто-то имеет готовый план. По законам Мерфи такое маловероятно...



#81303 Use cases: КАК и ЗАЧЕМ

Отправлено автор: CVD1 06 декабря 2010 - 18:20 в Тест-дизайн и ручное тестирование

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

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

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

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

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

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

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



#81294 Use cases: КАК и ЗАЧЕМ

Отправлено автор: CVD1 06 декабря 2010 - 15:55 в Тест-дизайн и ручное тестирование

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

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

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

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



#81254 Use cases: КАК и ЗАЧЕМ

Отправлено автор: CVD1 05 декабря 2010 - 21:05 в Тест-дизайн и ручное тестирование

anka_ua
Я правильно понял, что вы не в Москве? А то было бы интересно обсудить вашу ситуацию на встрече клуба тестеров.



#81250 Use cases: КАК и ЗАЧЕМ

Отправлено автор: CVD1 05 декабря 2010 - 20:41 в Тест-дизайн и ручное тестирование

разговор получается как у слепого с глухим :)
В ход пошли термины "пользователькие сценарии", "user scenarios", "use cases", "user stories", и я подозреваю, что понимание этих терминов участниками обсуждения весьма сильно различается.

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


Поддерживаю, корректная терминология, term definition снимет все вопросы и тема исчерпает себя. :acute:



#81244 Тестовое задание "ListBoxer".

Отправлено автор: CVD1 05 декабря 2010 - 19:01 в Тест-дизайн и ручное тестирование

и тогда "секретный план" успешно провалится :)

Гыть, да он уже вполне успешно провалился :acute:
Просто лень матУшка :acute:
На самом деле все решает собеседование.



#81243 Use cases: КАК и ЗАЧЕМ

Отправлено автор: CVD1 05 декабря 2010 - 18:48 в Тест-дизайн и ручное тестирование

Ребята, спасибо за отклик ) но "света в конце туннеля" пока не вижу... Можете рассказать, конкретно вы используете use cases в процессе тестирования?

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

У нас, к примеру, use case и (basic) user scenario разные вещи. Причем, use case это термин и сущность, которую можно обнаружить в спеке, а user scenario это мой личный тык скыть термин, для внутреннего употребления в тест тиме и тест доках. Мы парни простыя, на кохфыренцыи не ездим и книг не читаем, познаем на опыте.. :crazy:



#81241 Use cases: КАК и ЗАЧЕМ

Отправлено автор: CVD1 05 декабря 2010 - 18:14 в Тест-дизайн и ручное тестирование

Вот мои ответы на вопросы:

1. На какой стадии разработки ПО пишутся пользовательские сценарии
Во-время, уточнения требований и создания основной тестовой документации ?

Предполагается, что требования известны, одновременно ведется разработка функционала и тестовой документации в рамках текущей итерации. С позиции зрелости приложения, смысл в BUS появляется, когда весь необходимый функционал разработан. Имеется в виду итерационный процесс разработки, когда функционал наращивается постепенно. По моему опыту это после 10-11 месяца из 24.

2. Какова их эффективность в сравнении с тестовыми случаями?

Вопрос кажется некорректным. BUS это логически, сценарно связанная последовательность Test Cases.

Судя по всему, мелкие дефекты так и останутся на ПМЖ в конечном продукте, однако предполагается выиграш во времени, потраченном на тестирование. Оправдано ли это?

Собственно, разработка и переход к BUS вызваны недостатком времени и попытка минимизировать этот риск (ограничение).

3. Предполагает ли использование юзер кейсов полного отказа от привычной тестовой документации (тест плана, чек листа, тестовых примеров)?

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


4. Оптимальная структура и где/как хранить? (uml диаграммы, MS Excel, mind maps)?

Тест менеджер, в идеале полностью интегрированный с функц. требованиями, SVN и тд. ;-)
Это бесплатный Testlink или дорогой SilkCentral.
Структура стандартная, стандарты разные, начиная от action/expected result и заканчивая неформальным описанием последовательности действий.

5. Кто должен проходить пользовательские сценарии?
Непосредственно ответственный qa специалист или возможно приглашать другого qa, который с "незамыленным взглядом" сможет увидеть то, что человеку знающему ПО в деталях уже неподвластно?

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


6.На каком этапе должны выполняться? (регрессионное тестирование или тестирование новой функциональности)

На обоих ;-)

7. Каково пересечение exploratory testing(о котором говорил Майкл Болтон) и use cases?

Я бы сказал, что пересечения нет. Exploratory testing дополняет, обеспечивает более полное покрытие критических функций в случае локальных или неполных требований. В моей практике Use Cases всегда локальны.



#81240 Use cases: КАК и ЗАЧЕМ

Отправлено автор: CVD1 05 декабря 2010 - 18:13 в Тест-дизайн и ручное тестирование

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

Для меня переход к пользовательским сценариям произошел естественным образом как результат наращивания функционала в течение почти 2 лет работы над проектом. Побудительной причиной, потребителем стали ежемесячные демонстрации результатов итерации заказчику и внеплановые демонстрации функционала представителям заказчика. В первые месяцы функционал был, так сказать, кусочно непрерывным, но постепенно он дополнялся и наконец позволил реализовать важные последовательности действий пользователя.
Приложение сложное, многопользовательское, с различными ролями пользователей, позволяет реализовать множество случаев и сценариев использования (тестирования).
Процесс разработки достаточно динамичен и требуется регулярное регрессионное тестирование (smoke testing в первую очередь).
Также есть потребность в автоматизации регрессионного тестирования и нагрузочном (автоматизированном) тестировании.
Существует определенная текучесть тестировочных кадров.

Таким образом, перечислены предпосылки для использования так называемых Basic User Scenario (BUS, термин мой).
BUS не отменяют и не заменяют use cases, test cases и т.д., они позволяют сосредоточиться на критически важном функционале и быстром прогоне соответствующих тестов.
BUS это естественный способ приоритизации тестовых усилий в условиях недостатка ресурсов.