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

Действительно ли сертификация так важна для тестировщиков? Я работаю в Украине и у меня ни разу не попросили ни одного сертификата. Но, говорят, что она требуется в США – без нее там никуда. Мой знакомый тестировщик из Штатов рассказывал, что у них без сертификации вполне возможно работать, а вот в Европе или в Канаде – уже точно никуда. Так зачем же сертификация тестировщикам?

Продолжение статьи «Тестерские конференции Европы или повод пошопиться?»

Уже писали ранее о том многообразии городов захваченных тестерами в пределах нашей бывшей родины (ныне СНГ), которые появляются пачками после очередной SQA Days. А теперь я решил заглянуть дальше, за границы СНГ и спросить, а есть ли жизнь на Марсе? И решил значит поискать в интернете, а какие вообще «качественному» человеку качественные конференции стоит предложить?

Я использую C для научных расчётов. А в этом случае, стоит крепко подумать, а надо ли вам вообще C?

Язык C нужен только в случае, если в ваших расчётах очень критична производительность или критичен доступ к железу. Во всех остальных случаях, я очень рекомендую высокоуровневые языки типа Ruby или Python (почти что стандарт языка для научных расчётов, очень много научных пакетов разного толка от математики до биологии) или, что лучше, сразу научные пакеты типа Sage (надстройка над python с возможностью использования символьных вычислений и очень много чего ещё, а также с возможностью подключения других математических пакетов, в случае, если возможностей Sage не хватает, прямо внутри Sage программы; о Sage, кстати, писали на хабре).

Для Python же, если производительность важна и вы не готовы вылизывать C-код до совершенства, есть Cython (авторы которого являются также авторами Sage), который компилирует почти питоновский код в C-код, достигая очень высоких показателей производительности.

Так что на этом этапе призываю вас ещё раз: подумайте, прежде чем использовать C для научных или иных расчётов! Иначе, поехали!

Итак, вы всё-таки решили использовать C. В этом случае надо организовать рабочую тестовую среду, а именно:

• Модульное (unit) тестирование
• Автоматический запуск тестов, при изменении кода

Tsung — это распределенная система нагрузочного тестирования, написанная на Erlang'е. Заявлена поддержка HTTP, WebDAV, SOAP, PostgreSQL, MySQL, LDAP and XMPP/Jabber. В этой статье я опишу как протестировать обычный web сайт на нагрузку.

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

Далее о том, как все это дело автоматизировать.

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

TDD на примере UrlBuilder

В этой статье я хотел бы на простом, но жизненном примере рассказать о применении техники разработки через тестирование. Главный плюс такого подхода, на который я хотел бы обратить внимание — в момент начала разработки мы уже знаем, что мы должны разработать, и имеем вполне конкретный критерий работоспособности кода.

Продолжается полномасштабная подготовка знакового релиза 0.3.14 (0.PI) операционной системы ReactOS. В связи с чем разработчики обращаются к сообществу с просьбой принять участие в тестировании свежих билдов.

Координационный центр операции располагается на форуме разработчиков.

Что требует внимания тестеров:

I Работа на реальном железе

• сетевые карты
• USB мыши и клавиатуры
• управление питанием — включение выключение через «пуск» и по аппаратной кнопке.

II Неподтвержденные баги

В багтрекере проекта накопилось серьёзное количество неподтверждённых или имеющих некорректное описание багов. Необходимо провести тестирование свежих билдов и по результатам подтвердить или опровергнуть соответствующие баги.

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