Гыть, да он уже вполне успешно провалилсяи тогда "секретный план" успешно провалится :)
Просто лень матУшка
На самом деле все решает собеседование.
52 публикаций создано CVD1 (учитываются публикации только с 25 сентября 2023)
Отправлено автор: CVD1 05 декабря 2010 - 19:01 в Тест-дизайн и ручное тестирование
Гыть, да он уже вполне успешно провалилсяи тогда "секретный план" успешно провалится :)
Отправлено автор: CVD1 07 декабря 2010 - 07:13 в Тест-дизайн и ручное тестирование
Отправлено автор: CVD1 06 декабря 2010 - 18:26 в Тест-дизайн и ручное тестирование
Отправлено автор: CVD1 05 февраля 2011 - 13:18 в Тест-дизайн и ручное тестирование
Хотелось бы прокомментировать. На мой взгляд это не баг, потому что хелп не работает из-за устаревания программы. Листбоксер был разработан достаточно давно и, естественно, поддержка его не осуществляется. Формат хелп файла в виндовс за это время изменился. Поэтому мы имеем проблему, которую авторы ошибок в данную программу не закладывали. Эту ситуацию можно исправить, подгрузив соотвествующий файл с сайта Майкрософт....У меня вообще Help не работает! К какому приоритету можно отнести этот баг? 1-2?
Отправлено автор: CVD1 19 февраля 2011 - 07:51 в Тест-дизайн и ручное тестирование
Пару слов по поводу "старости" хелпа, это не баг, потому что пользователь может самостоятельно исправить эту проблему, воспользовавшись сервисом на Microsoft.com. То есть, определенную поддержку листбоксеру как win приложению обеспечивает MS. Это специфическая проблема и не стоит все остальные найденные ишью пропускать через призму "старый-не старый?".А этап установки тоже тестить?
А то я попробовал при установке все подвигать, поотменять в итоге установка зависла =) 1 Баг? или тоже проблема в старости?
Отправлено автор: CVD1 18 февраля 2011 - 19:29 в Тест-дизайн и ручное тестирование
Установку, удаление тестировать обязательно. Там есть даже 2 дистрибутива (с dll и без), установку которых тоже надо протестить.А этап установки тоже тестить?
А то я попробовал при установке все подвигать, поотменять в итоге установка зависла =) 1 Баг? или тоже проблема в старости?
Отправлено автор: CVD1 21 декабря 2010 - 18:33 в Личный рост, карьера, развитие
Согласен на 100 процентов.почему если я работал 5 лет тяпкой она мне должна осточертеть? Почему я не могу от нее тащиться? Почему я как специалист по тяпкам не могу искать работу по причинам отличным от того что мне тяпка надоела?
Я недоумеваю не насчет того что бабло не работает (хотя это утверждение слишком... общее, потому как много случаев когда оно отлично работает). Я недоумеваю из-за того что подход к описанной ситуации весьма однобокий
Отправлено автор: CVD1 19 декабря 2010 - 19:17 в Личный рост, карьера, развитие
Отправлено автор: CVD1 23 декабря 2010 - 10:11 в Личный рост, карьера, развитие
Отправлено автор: CVD1 21 декабря 2010 - 18:35 в Личный рост, карьера, развитие
Ничего, что я влезаю? Куда устроились?P.S. До того собеседования я к сожалению или счастью не дошла - устроилась на работу раньше. Но вопрос все равно интересен. Мало ли, мож еще пригодится.
Отправлено автор: CVD1 24 декабря 2010 - 08:11 в Личный рост, карьера, развитие
Отправлено автор: CVD1 22 декабря 2010 - 10:21 в Про тестирование обо всём подряд
Отправлено автор: CVD1 07 декабря 2010 - 19:01 в Тест-дизайн и ручное тестирование
Воспринял ваши реплики всерьез и ответил только по той причине, что топик стартер вроде как не очень опытный пока.Я, если честно, не понял зачем вы написали свои догадки, или вы и топик-стартер один и тот же человек?
Отправлено автор: CVD1 07 декабря 2010 - 09:46 в Тест-дизайн и ручное тестирование
Это тривиальная ситуация. Используются аттрибуты бага приоритет (priority) и сложность исправления (severity).Он сказал это подумав, как программист, с точки зрения которого spelling errors - это мелочь.
Отправлено автор: CVD1 05 декабря 2010 - 20:41 в Тест-дизайн и ручное тестирование
разговор получается как у слепого с глухим :)
В ход пошли термины "пользователькие сценарии", "user scenarios", "use cases", "user stories", и я подозреваю, что понимание этих терминов участниками обсуждения весьма сильно различается.
Не пытайтесь оперировать терминами, у большинства из них нет единого толкования.
Поясняйте всё, желательно на примерах.
Отправлено автор: CVD1 05 декабря 2010 - 18:48 в Тест-дизайн и ручное тестирование
Да. Но... зависит от ситуации. В самом крайнем случае это минимальная точка опоры, если совсем фигово.Ребята, спасибо за отклик ) но "света в конце туннеля" пока не вижу... Можете рассказать, конкретно вы используете use cases в процессе тестирования?
Отправлено автор: CVD1 05 декабря 2010 - 18:14 в Тест-дизайн и ручное тестирование
Предполагается, что требования известны, одновременно ведется разработка функционала и тестовой документации в рамках текущей итерации. С позиции зрелости приложения, смысл в BUS появляется, когда весь необходимый функционал разработан. Имеется в виду итерационный процесс разработки, когда функционал наращивается постепенно. По моему опыту это после 10-11 месяца из 24.1. На какой стадии разработки ПО пишутся пользовательские сценарии
Во-время, уточнения требований и создания основной тестовой документации ?
Вопрос кажется некорректным. BUS это логически, сценарно связанная последовательность Test Cases.2. Какова их эффективность в сравнении с тестовыми случаями?
Собственно, разработка и переход к BUS вызваны недостатком времени и попытка минимизировать этот риск (ограничение).Судя по всему, мелкие дефекты так и останутся на ПМЖ в конечном продукте, однако предполагается выиграш во времени, потраченном на тестирование. Оправдано ли это?
Тестовая документация (у нас) основывается на спецификации функциональных требований, содержащей use cases. Также BUS и пр. пишутся на основе знаний и опыта, здравого смысла, понимания предметной области, специфики использования софта.3. Предполагает ли использование юзер кейсов полного отказа от привычной тестовой документации (тест плана, чек листа, тестовых примеров)?
Тест менеджер, в идеале полностью интегрированный с функц. требованиями, SVN и тд. ;-)4. Оптимальная структура и где/как хранить? (uml диаграммы, MS Excel, mind maps)?
Если есть ресурсы, то зашибись. Но вообще-то лучше это делать опытному участнику тестировочной команды. Тестеры должны шарить свои доки, а тест-менеджер должен их тасовать, так как в идеале каждый тестер должен уметь прогонять полный набор смок тестов, ориентироваться в софте на 100% и грамотно осуществлять тест анализ функц требований, которые могут быть локальными, неполными, не учитывающими все взаимосвязи, зависимости в сложном софте. Это постоянный риск на определенном этапе разработки. Это как минимум.5. Кто должен проходить пользовательские сценарии?
Непосредственно ответственный qa специалист или возможно приглашать другого qa, который с "незамыленным взглядом" сможет увидеть то, что человеку знающему ПО в деталях уже неподвластно?
На обоих ;-)6.На каком этапе должны выполняться? (регрессионное тестирование или тестирование новой функциональности)
Я бы сказал, что пересечения нет. Exploratory testing дополняет, обеспечивает более полное покрытие критических функций в случае локальных или неполных требований. В моей практике Use Cases всегда локальны.7. Каково пересечение exploratory testing(о котором говорил Майкл Болтон) и use cases?
Отправлено автор: CVD1 05 декабря 2010 - 18:13 в Тест-дизайн и ручное тестирование
Для меня переход к пользовательским сценариям произошел естественным образом как результат наращивания функционала в течение почти 2 лет работы над проектом. Побудительной причиной, потребителем стали ежемесячные демонстрации результатов итерации заказчику и внеплановые демонстрации функционала представителям заказчика. В первые месяцы функционал был, так сказать, кусочно непрерывным, но постепенно он дополнялся и наконец позволил реализовать важные последовательности действий пользователя.был переход от написания тест планов и прохождения тестовых случаев к выполнению пользовательских сценариев, решили внедрить в рамках нашей компании user scenarios
Отправлено автор: CVD1 05 декабря 2010 - 21:05 в Тест-дизайн и ручное тестирование
Отправлено автор: CVD1 06 декабря 2010 - 15:55 в Тест-дизайн и ручное тестирование
В своих двух предыдущих постах я пытался раскрыть именно эту тему. Видать, не очень удачно. Но факт есть фактИдея использования пользовательского сценария возникла с целью объединить в группы высоко приоритетные тесты, для прохождения их в первую очередь и выявления поломок при регрешене в первую очередь
Идея не новая, умные люди мыслят одинаково. Чтобы она перестала быть сырой, давайте тестировщикам на прогон тесты, созданные другими, и ставьте задачу дополнить эти тесты. Проводите митинги на эту тему, брейнстормы, чтобы вырабатывался единый командный подход. Также брейнсторм можно проводить перед написанием тест доков при тестовом анализе. И новичков подтянете, и единое информационное поле создадите.Так же возникла еще одна идея, которая скорее близка к юзабилити тестингу ввести такого понятия как "qa ревизор" (условно).. Когда тестировщик проекта пишет use cases и выдает request другому тестировщику, занятому на другом проекте, которым со свежим взглядом/восприятием проходит данные сценарии и может оценить насколько функциональность удобна/понятна + может обладать (специалист) большим опытом и увидеть дефекты, который основной тестировщик упустил..
Идея сырая - еще непонятно, какие временные затраты могут повлечь подобные ревизии и насколько это принесет пользы..
Но тем не менее, предлагаю обсудить ;-)
Отправлено автор: 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?
Отправлено автор: CVD1 07 декабря 2010 - 07:11 в Тест-дизайн и ручное тестирование
Андрей сказал это, хорошо подумав. Ответственный программист должен быть заинтересован в том, чтобы выдать качественный продукт, то есть получить как можно быстрее информацию о самых серьезных багах.Это, Андрей Дмитриев, видимо, не подумав ляпнул.
Пользователь хочет быстрее получить качественный продукт, хорошо удовлетворяющий потребности. Тестировщик должен знать предметную область и потребности пользователя и на основе этого знания и опыта в первую очередь прогонять наиболее востребованные, важные пользовательские сценарии.Возникает резонный вопрос: а при чем тут пользователь?
Отправлено автор: CVD1 20 декабря 2010 - 07:38 в Тест-дизайн и ручное тестирование
Скажите, пожалуйста, что это такое?psr в 7ке
Отправлено автор: CVD1 20 декабря 2010 - 08:10 в Тест-дизайн и ручное тестирование
Отправлено автор: CVD1 29 октября 2010 - 08:00 в Управление тестированием
За несколько лет работы тестировщиком само собой развилось качество натуры проверять все. Если не могу что-либо проверить или не знаю как, становится недоверчиво или некомфортно ;-)тестировщиков что-то существенно отличает от других представителей ИТ-сообщества (да и не только ИТ)?
Community Forum Software by IP.Board Русификация от IBResource
Лицензия зарегистрирована на: Software-Testing.Ru