Предыстория

Недавно одна моя знакомая QA Engineer, которая долгое время работала в вялотекущем проекте, где круг ее обязанностей был строго очерчен, сменила работу и устроилась в свежезапущенный проект. Просидев пару дней без обозначенных сверху заданий, и откровенно заскучав, она пошла к руководству с вопросом «Что мне делать?» на что получила многозначительный ответ «Организуй свою работу». И тут она впала в ступор «А это как?». И правда, как?

Domain Object (рус. «Доменный объект») — один из наиболее популярных подходов к использованию тестовых данных непосредственно в логике скриптов. На данный момент является одним из самых популярных и распространенных approach'ей, благодаря своей простоте, понятности и логичности.

Применим во всех видах автоматизации функционального тестирования (End-to-End, API, Integration), в независимости от проверяемой платформы, будь то Web, Mobile, или Desktop.

ВАЖНО: не стоит путать Domain Object с Data Transfer Object (DTO). Это абсолютно разные подходы, которые применяются в разных сферах.

В чем его суть?

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

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

Если вы уже столкнулись с этой проблемой, и читаете эту статью, пытаясь нагуглить рецепт панацеи, то знайте, что его не существует. Тем более, в вашей голове уже скорее всего возникли инновационные мысли о том, чтобы сымитировать реалистичное поведение пользователя с помощью WebDriver, путём рандомного mouse overing'а элементов, кликов по инпутам, и бережно расставленных Thread.sleep(). Абсолютно точно известно, что этот подход работать не будет, не тратьте свое время попусту.



Получается, выхода нет?

Добрый день, Хабр!

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

Я собираюсь написать несколько статей про новую методологию гибкой разработки Канбан (Kanban Development) в целях подготовки к Scandinavian Agile Conference 2009, где я буду делать один из докладов (кстати, заодно приглашаю всех на конференцию).
Сегодня публикую первую из статей.
Основная задача первой статьи — это как можно проще описать основы Канбан: что это такое, в чем отличие от других гибких методологий и зачем это нужно.
Также я хотел бы собрать как можно больше вопросов и сомнений в комментариях, чтобы ответить на них в следующих статьях, так что пишите всё, что вам непонятно, или что ещё вы хотели бы узнать про Канбан.
Я не то, чтобы большой специалист по этой новой методологии, но мы внутри команды пришли к Канбану самостоятельно и последовательно прошли все этапы мутации от SCRUM до Канбан, так что практический опыт есть.

Добрый день!

Одним из моих профессиональных интересов, как координатора команды тестировщиков, являются методологии разработки программного обеспечения. В настоящее время все большую популярность приобретают так называемые Agile-методологии, в особенности Scrum и Kanban. На «раcпиаренных» терминах играют недобросовестные «тренеры», семинары и сертификации («сертифицированный Scrum-мастер», «сертифицированный Product owner» и т.д.) растут как на дрожжах.

Привет, Хабр! Меня зовут Владимир, мне 28 лет и я наркоман наркоман. Мой наркотик – простота. На простоту я подсел из-за своего перфекционизма, которым меня наградили при рождении.

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

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

Введение

В русскоязычной части Интернета присутствует большое количество статей, посвященных веб-службам на основе SOAP и XML-RPC, но почему-то почти ничего нет про вполне заслуживающую внимания (но менее распространенную) архитектуру RESТ.

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