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

Публикации Undi

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


#83160 Новая рассылка портала Software-Testing.RU

Отправлено автор: Undi 17 января 2011 - 09:37 в Портал Software-Testing.Ru

С этого года мы хотим обновить рассылку нашего портала Software-Testing.RU и сделать её стильной и максимально актуальной. Новым редактором будет Виктория Птицына.

Т.к. мы ценим Ваше время, то ставим своей целью: собрать самую свежую и интересную информацию в области тестирования и обеспечения качества.

Мы планируем делать рассылку раз в две недели. Каждый выпуск будет содержать:

  • ссылки на лучшие статьи и слайдкасты в области обеспечения качества;
  • обзор лучших публикаций в блогах тестировщиков;
  • активные обсуждения форума Software-Testing.RU;
  • информацию о мероприятиях в области тестирования;
  • обзоры деятельности региональных клубов;
  • информацию о различных скидках для наших подписчиков.
Мы хотим, чтобы данная рассылка была полезна нашим читателям, поэтому мы будем сотрудничать со всеми конференциями, тренерами по тестированию, чтобы наши подписчики получали скидки на все мероприятия в области тестирования. Нам уже удалось договориться о первых скидках!

Итак, представляем Вашему вниманию первый выпуск обновленной рассылки.

Если Вы заинтересовались и хотите получать дальнейшие выпуски, просто перейдите по ссылке и подпишитесь!

Мы будем очень стараться, чтобы рассылка была Вам полезной. А для этого потребуется и Ваша помощь! Все Ваши пожелания, вопросы и отзывы направляйте, пожалуйста, на адрес info@software-testing.ru.



Читать дальше


Будет ли в рассылке информация о вакансиях?
На форуме люди из разных городов и далеко не всем интересны вакансии (особенно программистов) в Москве. Сделайте рассылку, на которую бы не приходили сообщения из раздела "работа".



#83158 особенности тестирования в зависимости от технологий и языка программи

Отправлено автор: Undi 17 января 2011 - 09:31 в Тест-дизайн и ручное тестирование

Уважаемые коллеги, поделитесь, пожалуйста опытом.
Недавно на собеседовании меня спросили, каковы особенности тестирования приложения в зависимости от того на каком языке оно написано и какие технологии использовались?
Инфы в интернете я не нашла (может не там смотрела). :unknw:

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



Есть особенности в управлении мотоциклом, грузовиком и вертолетом? :)
При тестировании сайта, портала, инет-магазина нужно проверять под разными браузерами, разными версиями, разными локалями и т.д.
Всего этого нет, например, в приложениях для банков, где на нескольких сотнях компьютеров абсолютно одинаковая среда.
Отдельная и абсолютно другая область - тестирование приложений для мобильных устройств (телефонов, планшеток и т.д.) Там вообще другие требования и другие условия.
Довольно специфично тестирование биллинговых систем.
Еще вариант - программы для бортовых компьютеров автомобилей. Их тоже тестируют :)
Конечно, особенности тестирования в зависимости от языка разработки тоже есть, но, как уже написали, их область применения - тестирование белого ящика и автоматизация тестирования (в некоторых случаях).



#83138 Если у Вас высокая квалификация, то почему Вы все еще тестировщик?

Отправлено автор: Undi 16 января 2011 - 21:08 в Личный рост, карьера, развитие


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


Вот это и обидно, что "каждый постулат в отдельности - глупость", а мнение социума на протяжении довольно длительного времени не меняется. Те же разговоры были и 5 и 10 лет назад :-(
Есть какие-то предложения как повысить престижность профессии, чтобы действительно толковые люди не "попадали в тестирование случайно", а осознанно шли именно в эту профессию?


Плюс такого кривобокого отношения к тестированию есть - "случайно" чаще идут в программисты, а не в тестировщики. Т.е. у человека может быть талант к чему-то абсолютно другому, но ему каждый день внушают, что программист - это круто и высокооплачиваемо, потому надо идти туда. Другой вопрос - почему случайных людей без навыков, без образования, без понимания и т.п. БЕРУТ тестировщиками?

Мнение социума в данном случае формируют люди из ИТ.
Люди не из ИТ вообще не понимают разницу между сисадмином, программистом, тестировщиком и т.д. Часто слышу "помоги починить компьютер, ты же программист" или "сделай мне сайт, ты же с компьютерами работаешь".
Люди, близкие к ИТ, могут понять, что вэбер не сделает программу для мобилки, а дот.нетчик может не разбираться в макросах ворда. Но при этом они упорно не хотят понимать, что в тестировании тоже могут быть разные направления. Это хорошо демонстрируют описания вакансий. Насколько часто нужен программист, который бы разбирался в pascal, С++, java, HTML и Oracle одновременно? А насколько часто от тестировщика требуют владение всеми возможными средствами автоматизации, навыками ручного тестирования, знание баз данных, умение писать скрипты? Ведь нет даже терминологии, позволяющей отличить тестировщика, специализирующегося на мобильных устройствах от тестировщика клиент-серверных приложений.

Другая сторона медали (престижности тестирования) - где сейчас Панкратов и где у него тестирование? :)



#83137 Если у Вас высокая квалификация, то почему Вы все еще тестировщик?

Отправлено автор: Undi 16 января 2011 - 20:35 в Личный рост, карьера, развитие

Из профессиональных программистов получаются отличные тестировщики. Лучшая команда тестирования, которую я встречал, была в Luxoft. Это были маститые программисты из одного академического НИИ с опытом 20-30 лет. Они не осваивали новые программистские технологии, но исключительно эффективно ломали то, что было сделано на их основе.

(с) "Лекции по управлению программными проектами" С. Архипенков http://citforum.ru/S...enkov_lectures/


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



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

Отправлено автор: Undi 24 декабря 2010 - 12:42 в Про тестирование обо всём подряд

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


1. Как Вы сами видите, скриншот не спасает от программистов, которые не читают шаги воспроизведения :) Даже со скриншотом баги возвращаются, так что картинки - не панацея.
2. На самом деле всё работать может потому, что исправлена другая ошибка, которая ликвидировала эту. Или потому, что у программиста другое окружение (другая версия ОС, браузера, офиса и т.п.) Возможно, Вы не указали что-то в описании или программист не прочитал.
3. Скриншот не поможет исправить баг, если нет описания (говорю о UI). Даже если разработчику показать картинку, он не сможет исправить, если на его компьютере баг не воспроизводится. Либо же ему нужно будет самому проводить тестирование, что не хорошо.
4. Часто при разработке не-коробочных продуктов предъявляются требования к окружению. Например, у пользователей стоит лицензионная Vista и заказчик не собирается ее менять на Windows 7, а Вы тестируете на Windows 7. Но это самый простой пример.

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



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

Отправлено автор: Undi 24 декабря 2010 - 12:24 в Про тестирование обо всём подряд

Гугль зло. Там написано что можно сделать через кастом филд. Проблема в том что кастом филдов в FogBugz можно сделать весьма ограниченное количество и если их поставить под версию, то не влезет что-то еще.

По умолчанию поле отсутствует, так что...


И как это относится к обсуждаемой теме?
Вы утверждали, что FogBugz версионность не поддерживает. Вам ответили, что версионность отслеживать в FogBugz можно.
Если у Вас другие приоритеты и Вы не хотите настраивать версии - это уже другая тема.
Еще примеры будут?



#82479 Тестеры - зануды?

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

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


Останусь при своем мнении. Подсказывать новичкам можно и нужно, не только на форуме, но и в рабочее время :)
Я еще помню то время, когда книги о тестировании разных авторов отличались кардинально, а о Канере только слышали, но достать его книгу было почти нереально. Потому всегда стараюсь помочь и показать. Но...
1. Главное в любой профессии - желание заниматься именно этим делом, а не Устроилась почти нечаянно. Такие люди только отнимают время, портят мнение о профессии и рано или поздно уходят. Так почему бы не помочь человеку определиться пораньше, чтобы не было мучительно больно (с)?
2. ВСЕ ТЕСТЕРЫ - ЗАНУДЫ .... то ли это дурацкое занятие. Это что, вопрос о тестировании?
3. мне не повезло с колективом и работаю около полугода тоже напрягает. Не нравится - меняй работу. Крепостное право давно отменили.
4. Использование верхнего регистра отбивает желание что-то объяснять. Не зря этот метод не любят ни на одном форуме.



#82480 Тестеры - зануды?

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

тестер vs тестировщик - это просто политика. Должность может называться как угодно



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

Отправлено автор: Undi 23 декабря 2010 - 20:39 в Про тестирование обо всём подряд


например?

FogBugz. Могу еще привести, если нужно.


А вот здесь написано, что версии билдов есть http://support.fogcr...gbugz.4.91588.8 (первая попавшаяся ссылка из гугла) и здесь тоже: http://rpmsoftware.c...dex.php/FogBugz



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

Отправлено автор: Undi 23 декабря 2010 - 20:31 в Про тестирование обо всём подряд

Эмм.. регрессионное тестирование вроде ж никак не связано с багами, описанными тестировщиками на предыдущем цикле.. :dirol:


Смотря что понимать под регрессионным тестированием: http://www.protestin...regression.html



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

Отправлено автор: Undi 23 декабря 2010 - 09:04 в Про тестирование обо всём подряд

А мне кажется, что скриншот - это ещё одно доказательство, что проблема реально существует... Нет? ) Не всегда это нужно, но иногда они спасают...


можете привести пример такой ситуации? просто что-то из Вашего опыта



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

Отправлено автор: Undi 23 декабря 2010 - 09:01 в Про тестирование обо всём подряд

Не любой багтрекер)


например?



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

Отправлено автор: Undi 23 декабря 2010 - 09:01 в Про тестирование обо всём подряд

Недавно столкнулась с мнением что видеозапись или скриншот есть следствие неправильно локализованного бага, так вот я с этим мнением согласна только частично :)
Попрошу мнения на этот счет.


1. тестировщики пишут баги не только для того, чтобы потом проводить регресс-тестирование. По этому описанию в баге должен разобраться девелопер. А тут пошел какой-то абсолютно однобокий разговор. Нужно писать так, чтобы было понятно и разработчику, и любому другому тестировщику.
2. если баг неправильно локализован, скриншот тоже не поможет. Не надо путать две разные проблемы.
3. есть тестирование интерфейса, тестирование веб-приложений в разных браузерах, тестирование юзабилити и много чего еще, где ни описание, ни логи не помогут. Бывают приложения с огромным количеством информации на одной странице и гораздо быстрее найти о чем речь по скриншоту, чем считать клеточки или столбики (да, это не юзабилити интерфейсы, но они есть).
4. и самое главное - по скриншоту можно увидеть как менялось приложение от версии к версии, гораздо быстрее, чем по описанию понять актуален баг или уже не актуален.
Время - деньги. Нужно описывать баги так, чтобы проблему быстро и просто можно было воспроизвести. Если в логи пишется какая-то фраза, которую разработчик скопирует и по ней найдет проблему - нужны логи. Если ошибка с отображением чего-то - нужен скриншот. Но универсального решения быть просто не может.



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

Отправлено автор: Undi 23 декабря 2010 - 08:41 в Про тестирование обо всём подряд

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


Любой багтрекер позволяет фиксировать номера версий (билдов). Соответственно, тестировщик отмечает в какой версии баг найден, разработчик отмечает в какой версии баг исправлен. Можно ввести какое-то количество билдов, за которое баг должен быть закрыт (например, 5). Т.е. если баг наден в версии 2.4, а в 2.9 он не исправлен, его нужно перепроверить на версии 2.9 и внести изменения в описание шагов воспроизведения и в номер версии. Главное - не запускать этот процесс и не иметь давно висящих багов в принципе.



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

Отправлено автор: Undi 23 декабря 2010 - 08:33 в Про тестирование обо всём подряд


Функционал, который фигурирует в описании изменился, пройтись по стэпам и увидеть проблему не удаётся "сходу".

Если функционал настолько изменился, то нужно тестировать его заново. Разве не так?


Не надо путать функциональное тестирование и регресс-тестирование. Здесь речь идет о регрессионном тестировании. "Тестирование заново" не является аргументом для закрытия старых багов.



#81109 Итерационное тестирование

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

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


Вот это главная Ваша ошибка!
Нельзя соглашаться ни под каким предлогом на исправление ошибок "прямо в тесте".
Разработка - отдельно, тестирование - отдельно.
Собрали версию для тестирования, дали ей номер, передали в тестирование.
Далеее Вы проводите смоук-тесты.
Если тесты завалились, отдаете версию обратно на доработку.
Если тесты пройдены успешно, тестируете дальше.

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



#79817 Как заказчик определяет качество тестирования, и делает ли он это

Отправлено автор: Undi 11 ноября 2010 - 08:07 в Управление тестированием

как вы договариваетесь с заказчиком относительно оценки качества вашей работы (как он якобы будет оценивать)

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

Смотрит заказчик полученные документы или нет - бывает по-разному.

как заказчик определяет качество тестирования на самом деле

У многих крупных заказчиков есть свои ИТ-отделы, которые отвечают за приемку.
Часто бывает, что приемочное тестирование заказывают сторонней компании (я сама сейчас в таком проекте участвую).
Хотя бывает и так (особенно в гос.секторе), что программа никого не интересует. Деньги распилены, откаты получены. Заказчик не оценивает не только качество тестирования, но не пользуется программой вообще :)
Для маленьких программ заказчик чаще всего конечный пользователь, т.е. фактически он увидит лично качество тестирования.



#79691 Тестеры - зануды?

Отправлено автор: Undi 09 ноября 2010 - 10:33 в Личный рост, карьера, развитие

вон из профессии! :)
работайте лучше по специальности



#79598 Что надо чтобы стать тестировщиком?

Отправлено автор: Undi 05 ноября 2010 - 12:29 в Личный рост, карьера, развитие

а про мову, я українець ,доречі зі Львова, навчаюсь в універі де вчився Бандера і Шухевич, як шо це важливо для тебе, і цим горджуся,тому тяжко розмовляти по-російські і для мене її знання не головне!!!!
це перше

хотів почути рекомендації для початківця, а отримав купу фігні


Не надо путать грешное с праведным. У Вас есть компьютер. Вы решили заняться работой, которая требует установки различных программ (что тестирование, что программирование).
Что помешало проверить текст в любом редакторе? Или религия не позволяет установить проверку русского языка на свой компьютер?

Писати на російськомовний форум також ніхто не силував. Чому б не попитати в рідному універі або в Могилянці?
До речі, у Вас будуть певні проблеми з навчанням. Бо книжки всі російською. Можна ще замовити англійською зі штатів.
Рекомендації для початківця: заходиш на http://www.developer....ua/company-db/ шукаєш компанії у Львові, розсилаєш резюме, чекаєш, розсилаєш резюме і так поки хтось не візьме до себе :)
Теорія - це дуже добре, але без практики вона нічого не варта



#79338 Тестирование проекта

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

Да тебе ещё повезло крупно. Я в 60% сначала получаю программу, потом сам на неё SRS пишу, потом с этогол SRS план, потом тесты, а потом сам эти тесты выполняю.Плюс ещё приходится рекомендации по исправлению ошибок вёрстки писать со ссылками на источники доп информации. + если баг забористый и требует доработки - приходится для програмистов писать требования к реализации доработки.

но ведь ты получаешь программу....а у меня только srs....и не понятно как там все реализовано О_О

Если по SRS не понятно как будет реализовано - то это не очень хорошее SRS мне таккажется...


Как будет реализована какая-то фича (кнопочками, меню, комбобоксом или еще чем-то) тестировщика на этом этапе не волнует. "Как" - это проблемы разработчиков и их документации. Задача SRS - описать ЧТО должно быть, а не как. Например: "сумма должна отображаться в окне". А в каком гриде она будет отображаться - это к девелоперам и дизайнерам.
Тесты пишутся по SRS в идеальном случае, до первой версии продукта. Это позволяет во-первых получить тесты и сразу по ним тестировать, во-вторых максимально покрыть функциональность тестами без привязки к реализации.


у меня только srs....и не понятно как там все реализовано

Слова программиста, а не тестировщика :) Вам нужно тесты писать или в коде разбираться? :)

alexdfry, а не дали ли Вам задачу про стороны треугольника? :) очень уж любят ее на собеседованиях.
Вот здесь в средине текста есть описание: http://window.edu.ru...2txt?p_id=22383



#78933 Issue Document - need help! срочно

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

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


Как показывает мой опыт в таких случаях оптимально группировать по страницам. Т.е. бага1:
subject: "Орфографические ошибки на странице "бла-бла".
Description: слово "ааа" заменить на "ббб", слово "ййй" заменить на "ааа".
И не забываем про скриншоты.

Почему:
1. Так проще описывать
2. Разработчик или дизайнер будет исправлять по страницам (формам)
3. Проще проводить регресс-тестирование



#78728 помогите

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

я бы первое что в калькуляторе сделал, это сначала поделил бы что нибудь на ноль, потом возвел 99999999999999999,99999999999999999 в степень 999999999999999999999999999, попытался вместо числа подсунуть строку, а там дальше уже как настроение....


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



#78418 Тестер - тупая работа?

Отправлено автор: Undi 30 сентября 2010 - 09:35 в Личный рост, карьера, развитие

Но мне интересно тестировать программу только первые 2-10 раз, а затем повторение всех действий необходимых для успешного финиша начинает конкретно надоедать, писать тест кейсы я тоже не люблю.
Я хочу узнать. В моей компании нет процесса тестирования как такового, нет критериев для оценки работы, нет QA лида, нет мотивации для тестеров, нет каких либо программ повышения квалификации. Я хочу понять, необходимость заниматься одним и тем же день ото дня - это обязательно для тестера или это проблема тестирования в моей компании?


А вставать утром каждый день, ехать на работу по одной и той же дороге не надоедает?
2 месяца на проект - это очень мало, у Вас постоянно новая работа! Есть проекты, которые длятся десятилетиями :) Есть проекты, где одни и те же тесты нужно прогонять под 10-20 окружениями. По-моему дело тут вовсе не в работе тестировщика, а в чем-то личном либо субъективном