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

Публикации CVD1

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



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

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

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



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

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

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



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

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

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

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



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

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

...У меня вообще Help не работает! К какому приоритету можно отнести этот баг? 1-2?

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



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

Отправлено автор: CVD1 19 февраля 2011 - 07:51 в Тест-дизайн и ручное тестирование

А этап установки тоже тестить?

А то я попробовал при установке все подвигать, поотменять в итоге установка зависла =) 1 Баг? или тоже проблема в старости?

Пару слов по поводу "старости" хелпа, это не баг, потому что пользователь может самостоятельно исправить эту проблему, воспользовавшись сервисом на Microsoft.com. То есть, определенную поддержку листбоксеру как win приложению обеспечивает MS. Это специфическая проблема и не стоит все остальные найденные ишью пропускать через призму "старый-не старый?".



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

Отправлено автор: CVD1 18 февраля 2011 - 19:29 в Тест-дизайн и ручное тестирование

А этап установки тоже тестить?
А то я попробовал при установке все подвигать, поотменять в итоге установка зависла =) 1 Баг? или тоже проблема в старости?

Установку, удаление тестировать обязательно. Там есть даже 2 дистрибутива (с dll и без), установку которых тоже надо протестить.
Листбоксер работает на Windows 7, так что если что-то отвалилось при инсталляции, ИМХО, баг.



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

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

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

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

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



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

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

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



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

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

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



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

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

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

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



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

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

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



#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:



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

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

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

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


Поддерживаю, корректная терминология, term definition снимет все вопросы и тема исчерпает себя. :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 это естественный способ приоритизации тестовых усилий в условиях недостатка ресурсов.



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

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

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



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

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

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

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

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

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



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

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

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

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

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

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



#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?

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

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



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

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

psr в 7ке

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



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

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

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



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

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

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



#79369 В чём отличия тестировщиков от других профессий?

Отправлено автор: CVD1 29 октября 2010 - 08:00 в Управление тестированием

тестировщиков что-то существенно отличает от других представителей ИТ-сообщества (да и не только ИТ)?

За несколько лет работы тестировщиком само собой развилось качество натуры проверять все. Если не могу что-либо проверить или не знаю как, становится недоверчиво или некомфортно ;-)

Не сказал бы что это мессианство ;-) Иногда паранойя, иногда полезное качество.