Показаны сообщения с ярлыком Тестирование. Показать все сообщения
Показаны сообщения с ярлыком Тестирование. Показать все сообщения

вторник, 7 июня 2022 г.

RQA HH тренды май 2022

 Вот и май "будто корова языком слизала" пролетел. Не опять, а снова смотрим на тренды на HH.ru. +/- ситуация стабилизировалась в плане вакансий, роста нет, но и падение количества приостановилось. На что стоит обратить внимание - продолжает расти конкуренция, увеличивается количество резюме и соискателей. Всего - 33/1 резюме, 29/1 соискателей всего, и 27/1 резюме и 23/1 соискателей в Москве. Самое время сделать ревизию своих навыков и опыта. 





Мини-видео с трендами:


Продолжаем наблюдать! 





суббота, 21 мая 2022 г.

The State of Testing 2022 - часть 3 (заключительная)


Завершаю краткие выжимки исследования. 

Любимый вопрос на собеседовании - кем себя видите через 5 лет. Просто оставлю тут картинку.


Также советую посмотреть в отчете, что ищут при найме руководители.

Резюме (перевод с мини комментариями).

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

Тестировщики становятся частью Agile команд, количество тестировщиков уменьшается, увеличивается степень автоматизации, ведь нужно все делать быстрее. Что хочется видеть - так это проактивную позицию тестировщиков в обеспечении качества в компаниях. (я бы сказала, не только тестировщиков, а всех всех всех участников процесса разработки ПО, качество - это ответственность каждого).

Продакшн среда - наш основной источник обратной связи о качестве, содержащий ценную информацию для улучшения наших продуктов. (200%)

Тестировщики должны быть активными участниками CI процесса, интегрировать тестирования непрерывно и с самого начала. (300%)

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

И еще раз где можно посмотреть отчет: https://www.practitest.com/state-of-testing/


суббота, 7 мая 2022 г.

The State of Testing 2022 - часть 1

Как говорится, "лучше поздно, чем как тогда", посмотреть на результаты опроса по статусу тестирования. Это уже 9й по счету отчет от компании PractiTest (я когда-то тоже хотела ежегодный делать, но прокрастинация победила ;)) - The State of Testing 2022



Отчет можно найти вот тут: https://www.practitest.com/state-of-testing/

Из интересного:
  • 10% респондентов из России и Восточной Европы.
  • 61% опрошенных имеют более 10ти лет опыта.

Краткие выжимки ниже.

Про зарплату.  С годами опыта растет и ЗП. Топ 3 региона по ЗП: Штаты и Канада, Австралия и Новая Зеландия, Азия и Средний Восток.

Много ли тестировщиков. Очень похоже на то, что многие компании уходят от отдельных подразделений тестирования в компании. В команде обычно 2-5 тестировщика.

Изучение тестирования. Как говорится Just Do It (и таких 57%). 48% пользуются материалами на Youtube (тоже люблю образовательный контент). 47% курсы и сертификация.

CICD. "Забавная картина" % активного участия в CICD тестировщиков чуть упал, а тех, кто не участвует остался на том же уровне (возможно увеличилось количество респондентов).

Когда тестируют НЕ тестировщики. За три года увеличился объем респондентов, у которых все тестирование делают выделенные тестировщики (с 10% до 18%). Похоже наигрались с хайпом, что не должно быть отдельных тестировщиков.

(продолжение следует... )

понедельник, 18 апреля 2022 г.

SQADays 30



Осталось совсем немного до юбилейной конференции.


22-23 апреля в Москве пройдет 30я конференция по вопросам качества программного обеспечения. Есть варианты посещения как offline, так и online.


Конференция, как всегда, охватит широкий спектр профессиональных вопросов в области обеспечения качества, ключевыми из которых являются:

  • Методики и инструменты тестирования ПО;
  • Автоматизация тестирования ПО;
  • Подготовка, обучение и управление командами тестировщиков;
  • Процессы обеспечения качества в компании;
  • Управление тестированием и аутсорсинг;
  • Совершенствование процессов тестирования и инновации.

Развиваемся и общаемся!

среда, 8 сентября 2021 г.

Кому интересной работы?

 Вы давно мечтали попасть в game-индустрию? Делюсь возможностью! Хватайте и дерзайте!

ВОЗМОЖНОСТЬ №1

ВОЗМОЖНОСТЬ №2




воскресенье, 13 декабря 2020 г.

State of Testing 2021



Приглашаю всех принять участие в опросе от PractiTest «State of Testing». Чем больше людей примут участие, тем интереснее и тем полезнее для нас с вами будут результаты. Давайте поможем коллегам определить:

• Успешные практики и методологии;

• Навыки, которые позволяют быть востребованным на рынке труда;

• Лучшие места скопления профессиональных «знаний»

• Вызовы и тренды, чтобы быть во все оружии!


Делай добро, бросай его в воду! https://qablog.practitest.com/state-of-testing/



суббота, 12 декабря 2020 г.

HH тренды в ИТ - декабрь 2020

Доброго, солнечного, морозного, выходного! Представляю вам последнее отслеживание трендов вакансий на HH.ru в этом году! В следующем году в январе будет новый baseline для 2021.


По 2020 однозначно можно сказать, что количество вакансий в ИТ растет, всеобщая цифровая трансформация дает о себе знать. Как говорил один из моих начальников: «хорошо, когда работа есть». Желаю вам интереса в работе каждый день! 


В инсте чуть больше графиков ;) 


четверг, 3 декабря 2020 г.

World Quality Report 2020-2021

 


Если вы вдруг, как и я, пропустили выход World Quality Report 2020-2021, самое время — это исправить). WQR20-21

Основные выводы:

  1. Ожидается, что все будет быстро, качественно и, желательно, не очень дорого. И этот тренд устойчиво продолжается

  2. AIи MLпока не оказывают высокое влияние, но ожидание остается.

  3. Бюджет QAтеперь тяжело выделять в отдельную сущность, тк все больше QAинтегрировано во всю компанию.

  4. Автоматизация тестирования растет, все больше команд успевают писать автотесты за спринт. Что радует ;)

  5. Тестовое окружение все больше мигрирует в облака.

  6. Влияние короны. Цифровая трансформация ускорилась. Распределенный agile наше все. Мониторинг качества в реальном времени имеет большое значение!

Рекомендации:

  1. QA– это часть всей компании, чаще обращайтесь к пользователям, что для них работает, что предоставляет неудобства. Делайте статус видимым, дащборды наше все.
  2. AI. Продолжаем изучать, концентрируемся на том, что важно, подбираем инструменты, формируем стратегию.
  3. Бюджеты. Расходуем с умом. Эффективность наше все! Будьте готовы платить больше за талантливых специалистов.
  4. Автоматизация, автоматизация и еще раз автоматизация!
  5. Тестовое окружение. Используем центр экспертизы. Считаем ROI. Управляем.
  6. Корона. Берем лучшее, не рассматриваем как повод сократить расходы. Безопасность!

среда, 11 ноября 2020 г.

Стандарты управления качеством. Часть 1

 


Под управлением качеством продукции понимают деятельность, направленную на достижение уровня качества, удовлетворяющего проектно-конструкторским, контрактным и иным требованиям.

Стандартизация позволяет обеспечить требуемые характеристики продукции и услуг, такие как, качество, эргономичность, безопасность, надежность, эффективность и взаимозаменяемость. Когда продукция соответствует ожиданиям, это воспринимается как должное и никто не задает вопрос роли стандартизации. Однако, именно стандартизация гарантирует качество и безопасность производства и продукции. 

Стандарты, в зависимости от объекта стандартизации, содержания разрабатываемых и предъявляемых требований, разделяют на следующие:

  • основополагающие;

  • на продукцию, услуга;

  • на процессы;

  • на методы контроля, испытаний, измерений, анализа.

пятница, 30 октября 2020 г.

Lesson 12. Never be the gatekeeper!


К сожалению очень часто тестировщиков ставят в позицию хранителей ворот. 


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


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


Хорошей пятницы и отличных выходных! 


Сюрприз от Atlassian

 


Вот уже как больше недели прогремела новость от Atlassian. Заранее этот широко известный вендор предупредил, что скоро останется только опция подписки (Data Center – если хотите хостить самостоятельно, Cloud – если хотите, чтобы вендор хостил для вас).  Первоисточник: https://www.atlassian.com/blog/announcements/journey-to-cloud.


Тема, конечно, весьма неприятная, т.к. server лицензия у ребят всегда стоила гораздо приятнее, чем все остальное добро. И если вы хотите до 24го года прожить по старой цене, бегом делать renew, ибо в феврале 2021 цена изменится. И удобно, что можно сразу по старой купить, приблизившись по максимуму до 2024  (хотя что-то подсказывает, что на это и был капиталистический расчет ;)). Покупать можно на 24 месяца максимум. Интересный нюанс, в новых ценах теперь на renew Cloud цена гораздо ниже, чем на первую покупку (так всегда было с server). https://www.atlassian.com/licensing/future-pricing/cloud-pricing/pricing-tables


Считайте, делайте выводы – планируйте.

понедельник, 12 октября 2020 г.

О проверках и бизнес-ценности

 Доброго понедельника и отличного настроения!

Хочу поделиться интересной статьей Василия Касимого "О проверках и бизнес-ценности".

Приятного прочтения и отличной недели!


P.S.

Альтернативные форматы блога:

Инстаграмм: https://www.instagram.com/russiaqa.ru/

Телеграмм: https://t.me/russiaqa

Russiqa.ru



вторник, 15 сентября 2020 г.

Понятие качества продукции

 




О качестве много слов не бывает, да и прописные истины не бывает лишним повторить…


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


Качество продукции является частным случаем понятия качество. Качество продукции – это критическая оценка потребителем степени соответствия ее свойств, показателей качества, индивидуальным и общественным ожиданиям, обязательным нормам в соответствии с ее назначением. Таким образом, качество продукции связано с понятием свойство продукции и полезность продукции. Объективные стороны объекта (например, технический уровень продукции) определяют свойства. Полезность – способность продукции приносить пользу и удовлетворять конкретного потребителя. 


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


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


Почему качество важно для потребителя? Почему качество важно для производителя? Связка стоимости и качества определяет для пользователя необходимость приобрести продукт. Связка качества и стоимости продукции играет важную роль в определении конкурентоспособности на рынке.


Альтернативные форматы блога:

Инстаграмм: https://www.instagram.com/russiaqa.ru/

Телеграмм: https://t.me/russiaqa

Russiqa.ru



понедельник, 24 августа 2020 г.

 

Доброго утра 35й недели 2020 года!



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


Хорошего настроения и отличной недели!


Альтернативные форматы блога:

Инстаграмм: https://www.instagram.com/russiaqa.ru/

Телеграмм: https://t.me/russiaqa

Russiqa.ru

 

 

 


понедельник, 15 июня 2020 г.

ИТ вакансии: тестируем тренды

Всем доброго понедельника! 

В одном из подскастов специалист HR говорила, что несмотря на кризис, ИТ специалисты будут востребованы. Стало интересно протестировать сию гипотезу👹 Решила провести эксперимент и следить за рынком труда через сайт HH. Делюсь с вами первыми результатами. 


Подробности вот ТУТ.










Всем отличного настроения и хорошей недели!

воскресенье, 10 мая 2020 г.

9 полезных инструментов тестирования с открытым исходным кодом


Какие инструменты нужны для ремонта - Строительный портал ...
Всем привет!

И снова перетряхивая дела давно ушедших дней, вытаскиваю на свет и стряхиваю пыль, короткий обзор инструментов всегда полезен, детали по ссылке: КЛАЦ.

Автор заметки: Виталий Крюков.

Берегите себя, оставайтесь дома, развивайтесь!

Хорошего дня,  коллеги!

понедельник, 29 марта 2010 г.

Бах: Становясь экспертом в области тестирования

Оригинал статьи тут.

Обзор: Стать экспертом в области тестирования – это путь постоянного развития. Наличие концепции развития очень помогает направлять свои усилия. Джеймс Бах, весьма известная личность в области тестирования, делится своим взглядом на «экспертность» и предлагает стремящимся к статусу эксперта решить задачу.


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


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


Я считаю себя хорошим тестировщиком. Я могу ошибаться на этот счет. Спросите меня лет через пятнадцать. Что я знаю точно, так это то, что я работаю в направлении достижения статуса эксперта. Как я себя заставляю двигаться вперед? Мне помогает личная концепция. Всем кто желает получить статус эксперта, нужна концепция «экспертности», это двигает нас, ставит высокие стандарты, однако должно быть достижимым за жизнь.


Личная концепция.

Я могу тестировать все, при любых условиях, за любое время…


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


Давайте добавим:

… в степени относительно…

  • Моего положения в процессе
  • Моих познаний о соответствующей технологии
  • Моего желания преуспеть


Это позволяет сделать концепцию более реалистичной, но все еще выходящей за пределы. Где же тут стандарт качества? Конечно же, я могу сделать все что угодно, если дозволено делать это плохо. Можно ли следовать данной установке и тестировать хорошо, если кто-то спросит вас протестировать атомный реактор за 5 минут? Чтобы решить эту проблему, добавим еще несколько утверждений:


…Такие как..

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


Теперь концепция в сфере реальности, хотя и является вызовом.


В данном видении экспертизы, «Я могу протестировать» означает «Я могу хорошо выполнять работу тестировщика». Это измеряется человеческим стандартом: поведение лучших экспертов, которых можно найти. С этим стандартом в голове, как эксперты отреагируют на задачу тестирования ядерного реактора за 5 минут? Ответ: люди, которых я уважаю, начнут с использования самого великого инструмента в арсенале тестировщика – «задавания вопросов об ограничениях задачи». Самым лучшим в течение пяти минут будет спросить «Что тут происходит?» или что-то в этом роде. Ну а в данном конкретном случае, «Вы сбрендили?», что хорошо отражает абсурдность ограничения.


В принципе, основной смысл использования концепций в создании привычки при взгляде на каждый продукт задавать вопросы: «Как я буду это тестировать? А что если надо будет тестировать без требований? А что если выделенное время будет вдвое меньше?».


Учитывая выше написанное, вот вам задачка. Шесть лет назад, я написал небольшую виндовую программу как пример для упражнений на занятиях по тестированию. Я использую эту программу и по сей день. Я даю студентам 15 минут на ее тестирование. А если я дам вам всего 3 минуты на ее оценку, что вы будете делать? Мне в голову приходит 4 ответа, которые могут дать эксперты в тестировании…


Подумайте об этом. А тут мой ответ: http://www.satisfice.com/answer1.htm.


Об авторе: Джеймс Бах – основатель компании Satisfice, Inc., занимающейся консалтингом и обучением в области тестирования. Пионер развивающихся дисциплин: Достаточное качество и исследовательское тестирование, Джеймс специализируется на тестировании в хаотических условиях. Джеймс является соавтором (с Кемом Канером и Бретом Петтихордом) книги: Lessons Learned in Software Testing.


Отсебятина: В принципе, по жизни очень полезно знать «Что я хочу? Как выглядит это? Как я буду этого добиваться?». Сложные вопросы, кто-то их задает себе и не знает ответа, кто-то знает ответ, а кто-то и не мучает себя такими вопросами. Желаю Вам задавать вопросы, знать ответы или хотеть их найти :)

вторник, 2 февраля 2010 г.

Lessons Learned in Software Testing


Эту книгу можно смело считать очень ценным приобретением для любого специалиста, занимающегося тестированием. В настоящее время книга доступна только на оригинальном языке (вы еще не знаете английский в достаточной мере для чтения книг? Ай-яй-яй, это серьезное упущение). Хоть «уроки» и были изданы в 2001 году, это нисколько не умаляет ценность её содержания.

Книга написана в виде пронумерованных уроков (да-да, тех самых выученных авторами). Авторы предлагают нашему вниманию 11 глав (всего 293 урока):

  1. Роль тестировщика.
  2. Думать как тестировщик.
  3. Техники тестирования.
  4. «Защита» ошибок.
  5. Автоматизация тестирования.
  6. Документирование тестирования.
  7. Взаимодействие с программистами.
  8. Руководство проектом тестирования.
  9. Руководство группой тестирования.
  10. Карьера в тестировании.
  11. Планирование стратегии тестирования.

Кем Канер, Джеймс Бах и Брет Петтихорд являются представителями школы контекстно-ориентированного тестирования, подходы и принципы которой применяются в «уроках».

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

Сами авторы считают, что книга будет полезна тем:
· Кто тестирует программное обеспечение;
· Кто руководит тестированием;
· Кто хоть как-то соприкасается с тестировщиками в своих проектах.

Итого, если у вас эта книга есть – заглядывайте иногда в нее, если нет – приобретите.

Хочется немного перефразировать фразу из «физики нереального»: «Умным быть – модно!» в «Читать умные книги – полезно!».

P.S.:
книга на амазоне.

P.P.S.: а во тут наши коллеги перевели несколько уроков!

четверг, 12 ноября 2009 г.

Для начинающих: Анализ граничных значений aka Boundary Analysis


Что же это такое, анализ граничных значений? Да-да, техника написания сценариев тестирования. Этот подход очень тесно связан с разбиением на классы эквивалентности, т.к. именно классы являются источником тех самых границ!
Почему может быть полезен данный подход? Как в коде задаются ограничения? Ага, обычно знаками больше, меньше, равно. И ошибку можно «накодить» (практически, можно нашкодить :)) запросто, поставить не то значение в выражении, не тот знак. Вернемся к нашим карандашам (см. Разбиение на классы эквивалентности), в зависимости от заказанного количества карандашей различается стоимость:
  • 1 – 100 – 10 руб. за карандаш;
  • 101 – 200 – 9 руб. за карандаш;
  • 201 - 300 – 8 руб. за карандаш и т.д. С каждой новой сотней, цена уменьшается на рубль.

Максимально можно заказать – 1000 штук. Анализ граничных значений очень интересуют границы интервалов значений, на то он и «анализ граничных». Используя метод эквивалентного разбиения, были выделены следующие классы:

  1. Невалидное значение: >1000 штук;
  2. Невалидное значение: <=0;
  3. Валидное значение: от 1 до 100;
  4. Валидное значение: от 101 до 200;
  5. Валидное значение: от 201 до 300;
  6. Валидное значение: от 301 до 400;
  7. Валидное значение: от 401 до 500;
  8. Валидное значение: от 501 до 600;
  9. Валидное значение: от 601 до 700;
  10. Валидное значение: от 701 до 800;
  11. Валидное значение: от 801 до 900;
  12. Валидное значение: от 901 до 1000.

Самое время взяться за граничные значения этих самых классов. Нужно брать не только само граничное значение, но и отступать на шаг вверх/вниз (на самый, самый малюсенький из возможных шажков). Для выше написанных классов получаем:

  1. 999; 1000; 1001;
  2. 1; 0; -1;
  3. 99; 100; 101;
  4. 199; 200; 201;
  5. 299; 300; 301;
  6. 399; 400; 401;
  7. 499; 500; 501;
  8. 599; 600; 601;
  9. 699; 700; 701;
  10. 799; 800; 801;
  11. 899; 900; 901;
  12. аналогично классу №1.

Итак, получаем по 3 значения для границ, а также берем по одному значению из «тел» классов эквивалентности, итого: 33 + 12 = берем для проверки 45 значений. М-м-м-м-м, это больше 12, но гораздо меньше 1000. Да еще и проверяем не только валидные значения, но и невалидные! Но это только две техники из… продолжение следует…

среда, 7 октября 2009 г.

Selenium: пробуем "на зуб" вместе

Автоматизация тестирования, применяемая по месту, по времени и по теме весьма и весьма полезна. А если инструмент автоматизации бесплатный, мммм… «ни в сказке сказать, ни пером описать».

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

Используя надстройку над Firefox Selenium IDE, записываем и воспроизводим тесты. IDE позволяет экспортировать тесты во множество различных языков (включая Ruby, PHP, java, perl, C# и Python). Меня интересует связка Firefox-Selenium-JAVA. Почему? А не скажу, корыстные цели у меня :). Если будут появляться интересные моменты, буду описывать.

Самое главное, как это все добро запускать! А очень просто. Мне помогла вот эта
инструкция. Однако переменные среды я менять совсем не хотела, и один разработчик подсказал мне простой обходной путь (сама я в JAVA полный чайник, вот и мучаю знакомых ассов :)). Ниже мой вариант инструкции:

  • Скачиваем Selenium IDE & RC, устанавливаем (RC просто распаковываем, место расположения запоминаем). Все что нужно, перезагружаем.
  • Открываем Firefox. Разворачиваем меню «Инструменты» и о чудо! Видим подменю «SeleniumIDE». Кликаем дрожащей рукой уверенно и радостно. Если SeleniumIDE не видим, то, либо не установили, либо Firefox не перезагрузили.
  • И вот ОНО, «фриварное» чудо, перед нами. Уже записывающее, между прочим. Дабы остановить/начать необходимо нажимать кнопку с красным кругом :). Предлагаю посмотреть, как ЭТО работает на следующем примере:
  • Проверяем, что SeleniumIDE пишет (красная кнопка нажата).
  • В адресной строке Firefox пишем: wikipedia.org.
  • На заглавной странице в выпадающем меню выбираем язык: English.
  • В строку поиска вводим: testing. Жмем ввод.
  • На странице результата поиска кликаем по: Software testing.Заканчиваем запись.
  • Видим следующее в Selenium IDE:


  • Полюбовались? Попробуем нажать на кнопочку play? Вау, оно живое! Порадовались? Ну хватит, хватит, давайте продолжать. В IDE в меню файл выбираем Export Test Case As->Java(Junit)-SeleniumRC. Я использую имя: TrySelenium.java. Пойдем посмотрим, чего там на экспортировалось?

package com.example.tests;

import
com.thoughtworks.selenium.*;
import java.util.regex.Pattern;

public
class TrySelenium extends SeleneseTestCase {
public void setUp() throws
Exception {
setUp("http://wikipedia.org/", "*chrome");
}
public void
testTrySelenium() throws Exception {
selenium.open("/");
selenium.select("language", "label=English");
selenium.type("searchInput", "testing");
selenium.click("go");
selenium.waitForPageToLoad("30000");
selenium.click("link=Software
testing");
selenium.waitForPageToLoad("30000");
}
}

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

import com.thoughtworks.selenium.*;
import junit.framework.*;
import java.util.regex.Pattern;

public class TrySelenium extends SeleneseTestCase {
public void setUp() throws Exception {
setUp("http://wikipedia.org", "*chrome");
}
public void testTrySelenium() throws Exception {
selenium.open("/");
selenium.select("language", "label=English");
selenium.type("searchInput", "testing");
selenium.click("go");
selenium.waitForPageToLoad("30000");
selenium.click("link=Software testing");
selenium.waitForPageToLoad("30000");
}
public static Test suite(){
return new TestSuite(TrySelenium.class);
}

public static void main(String args[]){
junit.textui.TestRunner.run(suite());
}
}

  • Надеюсь, JVM у вас в наличие? Будем считать, что да. Запускаем selenium-server. Открываем терминал, перемещаемся в папку, куда распаковали зипник с Selenium RC. Выполняем: cd selenium-remote-control-1.0-beta-1/selenium-server-1.0-beta-1 (Циферки зависят от скачанной версии!). И запускаем: java -jar selenium-server.jar. Можно запускать и в интерактивном режиме, но пока не трогаем. Смотрим, что не ругается, и радуемся, радуемся. А если ругается, текст ошибки «в зубы» и на просторы Интернета… Добились запуска? А кто бы сомневался.
  • Пришло время компилировать и запускать java-код. Инструкция (см. выше) предлагает поменять переменные среды, как сказано ранее, идем в обход. В папке, где обитает наш java файлик создаем директорию lib, в нее переписываем следующее добро: 1) Отсюда …/selenium-remote-control-1.0-beta-1/selenium-java-client-driver-1.0-beta-1/selenium-java-client-driver.jar; 2)Junit у Вас есть? Нет, ну так качаем, качаем. Отсюда в папку lib добро копируем …/junit-4.6/junit.jar.
  • Открываем еще один терминал, компилируем: javac -cp lib\selenium-java-client-driver.jar;lib\junit-4.6.jar TrySelenium.java. Ошибки не выпрыгнули? Хорошо! Выпрыгнули? Читаем, вникаем, в java-файл возвращаемся, исправляем, компилируем, повторяем, пока не перестанут выпрыгивать ошибки!
  • И вот он! Момент истины. Запускаем наше творение: java -cp .\;lib\selenium-java-client-driver.jar;lib\junit-4.6.jar TrySelenium. Ура! Оно живое! Браузер открывается, в поле текст запроса вводится… А если ошибка вываливается? Опять же читаем, понимаем, ищем решение! А потом радуемся, радуемся, что «каменный цветок» выходит!

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