Eng. - be strong and think about others.

Senior engineers!  Just a note - at the very moment you are about to code-up your next shiny, glamorous test automation framework  - think about those middles who will  support and maintain the fruit of your creativity.  Be kind, leave at least couple of notes  on how that "wonderwaffle" is supposed to work!

О наступании на горло собственной песни.

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

Interviews - what do you need them for?

Why do you interview people? What are the final goals of that? I am talking about factual goals, not those one which are declared in your company's  policies. In practice I see quite often that "official" goals are "hire an engineer which would be highly effective and production in this very role/position". Good, sounds great. In fact, when it comes down to concrete interviewers the goasl turn into "show how cool I am, show that those candidates are nothing and do not hire him.". Cruel but true. So, by the end of the day we still have an open position, out candidate writes tons of posts on social media and the only guy who is happy  - that interviewer. He is a hero - defended the Company! Well, as for me, I need an interview to understand whether or not this particular engineer good and suites the requirements, could I learn something from him, is he a fat-learned and generally - "do I want to work with him in the same team?". Simply, keep your coolness for real business.

О целях собеседований.

Вот скажите, зачем собеседовать людей на ту или иную должность? Каковы конечные цели, каковы промежуточные?  И речь не о декларируемых целях, а о фактических. Частенько приходится сталкиваться с тем, что декларируемая цель это нечто в духе "нанять высококлассного инженера который будет максимально полезен работая в данной должности". А вот фактическая цель конкретных исполнителей это "показать какой я весь из себя крутой, показать какой кандидат "никакой",  смешать его с пылью и не принять на работу.". Грубо? Задевает чувства? Зато правда. В итоге - вакансия открыта, кандидат ушёл строчить гневные заметки в уютных бложиках и соц.сетях и лишь собеседовавший ходит выпятив грудь - герой, как же, не допустил, не пропустил в святая святых очередное "ничтожество". Как по-мне, цель собеседования - понять подходит человек или нет, где и в чём может быть полезен его опыт и знания, насколько он обучаем и открыт к обучение и вообще - "я хочу работать с ним или нет?". Показывать свою личную крутость следует на проекте, в деле.

You should read documentation, really - Allure reports + TestNG and run from command line.

 One have to read documentation, no options! It clearly stated that you have to run java process in a special way if you want to get steps, attachments etc info in your Allure report upon running a TestNG based test set.  And no, I had to spend two hours just to re-read the spec and discover that aspectjweaver dependency! And only after that it became clear that here is the way:

aspectjweaver_jar_file_name="$(ls ./lib/aspectjweaver-*.jar | xargs echo)"
java -ea -javaagent:"$aspectjweaver_jar_file_name" -cp "${full_classpath}" org.testng.TestNG ./test_suites/$testXmlName

Документацию надо всё-таки читать - Allure+TestNG и запуск из командной строки.

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

aspectjweaver_jar_file_name="$(ls ./lib/aspectjweaver-*.jar | xargs echo)"

java -ea -javaagent:"$aspectjweaver_jar_file_name" -cp "${full_classpath}" org.testng.TestNG ./test_suites/$testXmlName

Почему я недолюбливаю ключесловный подход в автоматизации, слайды.

См. здесь.

Самотренинг по автоматизации. Локаторы элементов.

Содержание.

Что это?
В плоскости автоматизации тестирования это что-то, что помогает найти элемент на странице или на форме: id, name ... .

Какие локаторы хороши?

• Простые и понятные;
• Устойчивые/гибкие и универсальные;
• Быстрые;
• При необходимости позволяющие задавать сложные условия поиска («3-й сверху во второй таблице слева...»).

Какие бывают?

Проще, лучше, быстрее найти элемент по id или name. Предполагается, что id/name уникально, хотя так и бывает не всегда. Чуть менее надёжно искать по другим атрибутам: классу, типу и т.д.. Сложнее потому что гарантий уникальности много меньше. Более изощрённый подход- использование CSS Selector-ов, а уж совсем вершина вершин - XPath.

Ссылки.

[1] http://www.georgehernandez.com/h/xComputers/XML/XSL/XPath.asp
[2] http://www.w3schools.com/xpath/default.asp
[3] http://www.zvon.org/xxl/XPathTutorial/General_rus/examples.html
[4] Набор шпаргалок. Очень ценно на практике - http://extract-web-data.com/5-best-xpath-cheat-sheets-and-quick-references/
[5] Кое-какие откровения на тему посика элементов в таблицах -  http://autotestgroup.com/ru/blog/85.html
[6] Видеолекция по CSS selector + XPath http://www.youtube.com/watch?v=ahhaMbjqrxM

Самотренинг по автоматизации. Введение в Луний.

Содержание.

Что это?
Луний он же Selenium, он же WebDriver, он же Selenium2.0, он же Selenium WebDriver это:

• Библиотека;
• API для управления браузером;
• Стандарт W3C.

... и с учётом всего этого он/она/оно вовсе не инструмент автоматизации тестирования.

Что умеет?
Довольно много:

• Находить элементы: By.Id, By.Name, By.Xpath, By.TagName, By.ClassName, By.CssSelector, By.LinkText, By.PartionalLinkText;
• Нажимать кнопки, изымать текст, выбирать из списков; 
• Поддерживает: FF, IE, Chrome, HtmlUnitDriver, ... ;
• Ждать: Explicit Waits, Implicit Waits;
• Много чего ещё … .

Достаточно ли этого для автоматизации? Это огромное подспорье, но наш каркас для тестирования требует ещё механизмов структуризации кода, запуска и останова, журналирования, генерации отчётов и т.д. Всё это обеспечивается уже не Лунием, а вещами вроде Maven/Gradle, TestNG/JUnit/NUnit и пр. и пр:

Ссылки

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

[1] http://docs.seleniumhq.org/
[2] http://bugscatcher.net/archives/1232
[3] http://habrahabr.ru/post/152971/
[4]http://refcardz.dzone.com/refcardz/getting-started-selenium-20

[5] http://code.google.com/p/selenium/

[6] http://habrahabr.ru/search/?q=selenium

[7] http://selenium.googlecode.com/svn/trunk/docs/api/java/overview-summary.html

Cамотренинг по автоматизации. Подходы: модельный и гибридный.

Содержание.

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

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

Cамотренинг по автоматизации. Подходы: объектный.

Содержание.

Объектный подход.
 ООП уже многие годы стандарт де-факто в разработке ПО. Объекты в программировании служат отражением объектов реального мира, а объекты в автоматизации отражают элементы тестируемого приложения: формы, страницы, т.е. части графического интерфейса. Однако   "отражают" означает не только наличие таких же полей, но предоставление неких сервисных методов, например logout(). "This reduces the amount of duplicated code and means that if the UI changes, the fix need only be applied in one place."

Пример: класс LoginPage моделирует(отражает) страницу входа в систему. Соответственно этот класс должен обеспечивать доступ к полям "имя" и "пароль" или даже предоставлять метод по авторизации в системе. Очень наглядный пример объектного подхода это шаблон "PageObject".

"За".
+ Структурированное и расширяемое решение, что ведёт к снижению стоимости поддержки;
+ Все "плюшки" ООП.

"Против".
- Надо знать и применять ООП;
- Чрезмерное увлечение программированием может привести к "коду ради кода".

Yet another traffic lights - CI status indicator.

 Nowadays Continuous Integration is popular and almost a “must-have” on a serious project. The only question is - what is your current CI status? How to make it visible? E-mails are good, but let’s be honest, nobody reads all those tons of “build failed/back to normal” messages. There is a need for some funny and unobtrusive way to let anybody know what’s the status in a, say, second. So, we’ve got “Traffic Lights CI status indicator”:

- visible;

- funny;

- it has DIY appearance(look at that fastening adhesive tape all over it!);

- a bit environmental - an old colour music box was reused;

- portable (about 1 kg, it’s really light);

- inexpensive (~25 pounds).

The workflow is simple: homemade client application checks CI status and sends “turn on red and turn off green” like messages to the microcontroller, the microcontroller turns on/off corresponding bulbs. As for the colours: “green” means everything is good, “blue(yellow)” means we’ve got some test(s) failed and “red” means that it’s time to hurry up since something is completely broken. That’s all.