Рубрика «тестирование» - 101

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

RoboHornet тестирует производительность JavaScript, DOM, Canvas, SVG, Local Storage и даже анимированных GIF-ов. Сообщество тестировщиков координируют так называемые "стюарды", среди которых — сотрудники Google, Facebook, Sencha, активные участники проектов YUI, HTML5 Boilerplate, jsPerf, jQuery и других. Идея, лежащая в основе RoboHornet, очень проста: любой популярный тест заставляет производителей стремиться к тому, чтобы их браузер показал в нём наилучшие результаты. Если создать и сделать популярным тест, который охватывает все важные аспекты работы веб-приложений, а не только JavaScript, или, например, Canvas — это будет способствовать более сбалансированному развитию браузеров.
Читать полностью »

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

image

Обычно используют два вида автоматических тестов:
Модульное тестирование (тестирование отдельных частей продукта, обычно отдельных функций/методов)
Функциональное тестирование — тестирование некого функционала продукта, при этом продукт воспринимается как единый «чёрный ящик».

Но давайте зададим интересный вопрос — действительно ли нужны оба вида тестирования сразу, и если нет — то какое из них важнее?
Читать полностью »

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

Буквально сегодня мне нужно было быстро проверить верстку сайта в Safari. Под рукой ничего подходящего не оказалось и пришлось как это говорится «гуглить». В результате «гугления» я попал на spoon.net/ и честно признаюсь, что сначала даже не придал особого значения этому сервису. Зарегистрировался и установил плагин.
Читать полностью »

Как выглядит современная юзабилити лаборатория

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

Юзабилити-лаборатория — это несколько помещений, в которых моделируются различные контексты использования услуг «Билайн». У нас три зоны: офис, дом и кафе. Все три зоны снабжены записывающим оборудованием, позволяющим специалистам точно увидеть и зафиксировать, что и как делает пользователь. Во все три зоны выходят «окна» из зала, где сидят наблюдатели — для участников исследования они выглядят как зеркала, для членов рабочей группы, пришедших понаблюдать за ходом исследования, они прозрачны.

Как выглядит современная юзабилити лаборатория
Помещения лаборатории Читать полностью »

Тот кто пройдёт данный тест очень при очень быстро, получит значок ленивца! Не думаю, что на этот тест вы потратите более 30 минут, а если потратите больше — это будет значить, что вы очень упорный и честный человек. Честный в плане того, что в гугл не заглядывали.

Тест на сообразительность

Читать полностью »

Многие слышали про Selenium WebDriver — один из самых популярных инструментов для написания приёмочных/интеграционных тестов.
Selenide: удобные тесты на Selenium WebDriver

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

Поэтому мы решили выделить этот повторяющийся код в отдельную библиотеку. Так на свет появился Selenide.

Читать полностью »

image

Как всем известно, мобильные телефоны не предназначены для работы в условиях повышенной влажности и тем более под водой. Для этих целей существуют специальные водонепроницаемые чехлы и кожухи. Но в последнее время на прилавках магазинов стали появляться модели мобильников, на которых черным по белому написано: "waterproof". А вернее нанесены специальные маркировки типа ip65 или ip68. Эти цифры указывают, насколько и какую агрессивную среду перенесет тот или иной аппарат.

Есть хорошая поговорка: доверяй, но проверяй! Канал GTV решил проверить реальные возможности этих телефонов противодействовать водной стихии и снял несколько познавательных передач из цикла Hi-Testing.

Для краш-теста взяли 2 контрольных и 4 телефона с пометкой «защита от влаги»:

  1. МТС-140 (контрольный)
  2. iPhone 2G (контрольный)
  3. Sonim XP3300 Force
  4. Samsung Galaxy xCover S5690
  5. Sony Xperia Go
  6. Fly OD1

Смотрите первые 3 теста под катом.Читать полностью »

Продолжаем разговор.

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

mtikhon в своей статье «Легкий способ пройти тестирование» прекрасно дополнил тот список «внешними» проблемами, влияющими на результат тестирования. Внешними – в том смысле, что они зарождаются не в отделе тестирования, а в прочих подразделениях, а еще чаще – где-то на стыках подразделений, при взаимодействии отделов. (Я понимаю, что не всегда под тестирование формально выделен специальный отдел. Но это косметическая разница, сути не меняет: тут речь скорее о разделении ролей)
mtikhon’у слегка попеняли в комментариях, что список проблем изложен, а легкий способ их обойти – нет. Он, в свою очередь, уже справедливо отметил, что «способы как правило разнятся очень сильно». Вот на этой мысли я и хочу потоптаться чуть подробней.

Пожалуй, пойду прямо по тем же пунктам.
Читать полностью »

По мотивам поста «Легкий способ провалить тестирование».

Как избежать провалов в тестировании продукта?

1. Тестировщик должен быть в курсе изменений в продукте.

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

Иногда тестирование не приносит нужного результата. То есть работа кипит, фичи проверяются, баги чинятся, даже какая-то статистика собирается, но после релиза оказывается, что продукт напичкан дефектами, как подсолнух семечками, — и пользователи, что характерно, плюются.
Кто виноват? Все виноваты, конечно, — и руководители, и программисты, и аналитики, но они сами пусть учат свои уроки.
Ну и тестировщики.
Тоже.
Виноваты.
Да?
Да. И дело часто не в технических каких-то проблемах, а во вполне человеческих. Нет, бывает, конечно, что восстание машин ломает все планы, или что изначально планы были невыполнимы. Но даже и в не форс-мажорной ситуации у тестировщика достаточно способов провалить тестирование, работая в поте лица.
Читать полностью »


https://ajax.googleapis.com/ajax/libs/jquery/3.4.1/jquery.min.js