- Форум тестировщиков
- → Публикации CVD1
Публикации CVD1
52 публикаций создано CVD1 (учитываются публикации только с 10 мая 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 в Личный рост, карьера, развитие
Согласен на 100 процентов.почему если я работал 5 лет тяпкой она мне должна осточертеть? Почему я не могу от нее тащиться? Почему я как специалист по тяпкам не могу искать работу по причинам отличным от того что мне тяпка надоела?
Я недоумеваю не насчет того что бабло не работает (хотя это утверждение слишком... общее, потому как много случаев когда оно отлично работает). Я недоумеваю из-за того что подход к описанной ситуации весьма однобокий
#82334 Обсуждение второй встречи клуба MSTC
Отправлено автор: CVD1 21 декабря 2010 - 16:29 в Московский клуб тестировщиков
Не все, я тугодум
#82331 Обсуждение второй встречи клуба MSTC
Отправлено автор: CVD1 21 декабря 2010 - 15:48 в Московский клуб тестировщиков
Большое спасибо организаторам и докладчикам. Весьма полезно, хотя и не идеально.
Давайте еще.
Если не забуду и не поленюсь, напишу отзыв подробнее.
Ps: По-моему я поставил рекорд - был единственным в зале не владельцем ноутбука.
Давайте еще.
Если не забуду и не поленюсь, напишу отзыв подробнее.
Ps: По-моему я поставил рекорд - был единственным в зале не владельцем ноутбука.
#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 в Тест-дизайн и ручное тестирование
Это тривиальная ситуация. Используются аттрибуты бага приоритет (priority) и сложность исправления (severity).Он сказал это подумав, как программист, с точки зрения которого spelling errors - это мелочь.
То есть misspell bug may have Blocking priority, Minor severity.
Вообще-то, уходим от темы.
#81335 Тестовое задание "ListBoxer".
Отправлено автор: CVD1 07 декабря 2010 - 07:13 в Тест-дизайн и ручное тестирование
Поддерживаю предложение
#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 в Тест-дизайн и ручное тестирование
В своих двух предыдущих постах я пытался раскрыть именно эту тему. Видать, не очень удачно. Но факт есть фактИдея использования пользовательского сценария возникла с целью объединить в группы высоко приоритетные тесты, для прохождения их в первую очередь и выявления поломок при регрешене в первую очередь
Идея не новая, умные люди мыслят одинаково. Чтобы она перестала быть сырой, давайте тестировщикам на прогон тесты, созданные другими, и ставьте задачу дополнить эти тесты. Проводите митинги на эту тему, брейнстормы, чтобы вырабатывался единый командный подход. Также брейнсторм можно проводить перед написанием тест доков при тестовом анализе. И новичков подтянете, и единое информационное поле создадите.Так же возникла еще одна идея, которая скорее близка к юзабилити тестингу ввести такого понятия как "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 снимет все вопросы и тема исчерпает себя.
#81244 Тестовое задание "ListBoxer".
Отправлено автор: CVD1 05 декабря 2010 - 19:01 в Тест-дизайн и ручное тестирование
Гыть, да он уже вполне успешно провалилсяи тогда "секретный план" успешно провалится :)
Просто лень матУшка
На самом деле все решает собеседование.
#81243 Use cases: КАК и ЗАЧЕМ
Отправлено автор: CVD1 05 декабря 2010 - 18:48 в Тест-дизайн и ручное тестирование
Да. Но... зависит от ситуации. В самом крайнем случае это минимальная точка опоры, если совсем фигово.Ребята, спасибо за отклик ) но "света в конце туннеля" пока не вижу... Можете рассказать, конкретно вы используете use cases в процессе тестирования?
У нас, к примеру, use case и (basic) user scenario разные вещи. Причем, use case это термин и сущность, которую можно обнаружить в спеке, а user scenario это мой личный тык скыть термин, для внутреннего употребления в тест тиме и тест доках. Мы парни простыя, на кохфыренцыи не ездим и книг не читаем, познаем на опыте..
#81241 Use cases: КАК и ЗАЧЕМ
Отправлено автор: CVD1 05 декабря 2010 - 18:14 в Тест-дизайн и ручное тестирование
Вот мои ответы на вопросы:
Тест план, чек лист, тест примеры, BUS - все это используется по ситуации, догмы нет. Что от вас требуют, то и пишите. Если ничего не требуют, вааще лафа.
Это бесплатный Testlink или дорогой SilkCentral.
Структура стандартная, стандарты разные, начиная от action/expected result и заканчивая неформальным описанием последовательности действий.
Предполагается, что требования известны, одновременно ведется разработка функционала и тестовой документации в рамках текущей итерации. С позиции зрелости приложения, смысл в BUS появляется, когда весь необходимый функционал разработан. Имеется в виду итерационный процесс разработки, когда функционал наращивается постепенно. По моему опыту это после 10-11 месяца из 24.1. На какой стадии разработки ПО пишутся пользовательские сценарии
Во-время, уточнения требований и создания основной тестовой документации ?
Вопрос кажется некорректным. BUS это логически, сценарно связанная последовательность Test Cases.2. Какова их эффективность в сравнении с тестовыми случаями?
Собственно, разработка и переход к BUS вызваны недостатком времени и попытка минимизировать этот риск (ограничение).Судя по всему, мелкие дефекты так и останутся на ПМЖ в конечном продукте, однако предполагается выиграш во времени, потраченном на тестирование. Оправдано ли это?
Тестовая документация (у нас) основывается на спецификации функциональных требований, содержащей use cases. Также BUS и пр. пишутся на основе знаний и опыта, здравого смысла, понимания предметной области, специфики использования софта.3. Предполагает ли использование юзер кейсов полного отказа от привычной тестовой документации (тест плана, чек листа, тестовых примеров)?
Тест план, чек лист, тест примеры, BUS - все это используется по ситуации, догмы нет. Что от вас требуют, то и пишите. Если ничего не требуют, вааще лафа.
Тест менеджер, в идеале полностью интегрированный с функц. требованиями, SVN и тд. ;-)4. Оптимальная структура и где/как хранить? (uml диаграммы, MS Excel, mind maps)?
Это бесплатный Testlink или дорогой SilkCentral.
Структура стандартная, стандарты разные, начиная от action/expected result и заканчивая неформальным описанием последовательности действий.
Если есть ресурсы, то зашибись. Но вообще-то лучше это делать опытному участнику тестировочной команды. Тестеры должны шарить свои доки, а тест-менеджер должен их тасовать, так как в идеале каждый тестер должен уметь прогонять полный набор смок тестов, ориентироваться в софте на 100% и грамотно осуществлять тест анализ функц требований, которые могут быть локальными, неполными, не учитывающими все взаимосвязи, зависимости в сложном софте. Это постоянный риск на определенном этапе разработки. Это как минимум.5. Кто должен проходить пользовательские сценарии?
Непосредственно ответственный qa специалист или возможно приглашать другого qa, который с "незамыленным взглядом" сможет увидеть то, что человеку знающему ПО в деталях уже неподвластно?
На обоих ;-)6.На каком этапе должны выполняться? (регрессионное тестирование или тестирование новой функциональности)
Я бы сказал, что пересечения нет. Exploratory testing дополняет, обеспечивает более полное покрытие критических функций в случае локальных или неполных требований. В моей практике Use Cases всегда локальны.7. Каково пересечение exploratory testing(о котором говорил Майкл Болтон) и use cases?
#81240 Use cases: КАК и ЗАЧЕМ
Отправлено автор: CVD1 05 декабря 2010 - 18:13 в Тест-дизайн и ручное тестирование
Для меня переход к пользовательским сценариям произошел естественным образом как результат наращивания функционала в течение почти 2 лет работы над проектом. Побудительной причиной, потребителем стали ежемесячные демонстрации результатов итерации заказчику и внеплановые демонстрации функционала представителям заказчика. В первые месяцы функционал был, так сказать, кусочно непрерывным, но постепенно он дополнялся и наконец позволил реализовать важные последовательности действий пользователя.был переход от написания тест планов и прохождения тестовых случаев к выполнению пользовательских сценариев, решили внедрить в рамках нашей компании user scenarios
Приложение сложное, многопользовательское, с различными ролями пользователей, позволяет реализовать множество случаев и сценариев использования (тестирования).
Процесс разработки достаточно динамичен и требуется регулярное регрессионное тестирование (smoke testing в первую очередь).
Также есть потребность в автоматизации регрессионного тестирования и нагрузочном (автоматизированном) тестировании.
Существует определенная текучесть тестировочных кадров.
Таким образом, перечислены предпосылки для использования так называемых Basic User Scenario (BUS, термин мой).
BUS не отменяют и не заменяют use cases, test cases и т.д., они позволяют сосредоточиться на критически важном функционале и быстром прогоне соответствующих тестов.
BUS это естественный способ приоритизации тестовых усилий в условиях недостатка ресурсов.
- Форум тестировщиков
- → Публикации CVD1
- Политика Конфиденциальности
- Правила форума ·