Напосмотреть: Trust me, I'm ынженер

Скопилось видео всякого.

1. Марина Широчкина с хорошей обзорной лекцией о тестировании для всяких сторонних неокрепших умов. Это не столько для аудитории моего уютненького, сколько для людей которые будут у вас спрашивать "А тестирование - это как ?"



2. Дмитрий Безуглый с очень плотным набором очень умных мыслей про то куда вы прикатитесь с Agile
20151023BO Драйверы и паттерны организации эффективной разработки ПО from Stas Fomin on Vimeo.

3. О том как еще вы можете издеваться что вы можете сделать со своей Agile командой - Джонатан Расмуссон
Jonathan Rasmusson - 10 things you can do to better lead your agile team from NDC Conferences on Vimeo.

4. Mary Shaw о том что такое инженерия на самом деле и причем здесь софт


5. Время охуительных историй в исполнении Камилы Фурнье про то как переписывать продукты



6. О том как Etsy трансформировали сами себя для выпуска мобильных приложений.

Напочитать: Test... Test me harder!!!

 Уже на этой неделе в Минске состоится SQADays. Ну а пока не наступила - выпуск с сильными уклоном в тестирование.

1. Автоматизированное тестирование JavaFX приложений - с примерами и картинками.
2. Очень многие сейчас увлекаются всякими Chef-ами, Puppet-ами и прочими Ansible-ами. А ведь это все надо тоже тестировать  - инфраструктура как код - это небесплатно.
3. Замечательный набор подсказок для тестировщиков что можно делать с консолью Google Chrome.
4. О непростых взаимоотношениях разных версий Opera и как с ними жить из-под webdriver - Алексей Баранцев.
5. О том как построить схему связей модулей в проекте на PowerShell и Graphviz - тут. Причем здесь тестирование и обеспечение качества - а вот сами должны догадаться!
6. Замечательный, хоть и длинный пост про TDD и что "невсетакпросто" и флейм в комментах.
7. Ребята из LMAX Exchange (это контора, которая дала миру Disruptor, если чо) плюют в морду ребятам из Gooogle, которые говорят что end-to-end тесты - это дорогостоящая фигня.
Плюют обоснованно. От себя могу добавить - обращение с большим массивом end-to-end тестов требует принципиально других инструментов и подходов. Существующие инструменты (Continuous Integration решения, большей частью) не обладают теми свойствами которые нужны для постоянно работы с большим количеством end-to-end тестов (отчеты, логи, анализ запусков на разных окружениях, продолжать можно долго). И либо вы дальше строете/пристраиваете/достраиваете что-то свое (как мы - микросервисы), либо начинаете кричать о том, что end-to-end тесты = ( долго + дорого + хрупко + неэффективно * и вообще говно).  Меняйте mindset.


На SQA Days в Минске я как раз буду рассказывать о том как мы строим и используем микросервисы для наших (в том числе end-to-end) автоматических тестов.

Напочитать: Важнейшим из искусств для нас является YouTube

1. Mob Programming от автора концепции


Mob Programming, A Whole Team Approach from Øredev Conference on Vimeo.


2. Ольга Павлова про обучение. Тончайший, я бы даже сказал прецезионный, троллинг. Умница.



3. Роман Сальников срывает покровы с мощи Chrome Dev Tools. Тестировщикам вэб-проектов обязательно к просмотру.
Роман Сальников, 2GIS | Суперсилы Chrome Dev Tools | FrontTalks 2014 from FrontTalks Conference on Vimeo.

4. Борис Вольфсон про ретроспективы.



Презентация c выступления на slideshare


5. Kristian Karl  о том как команда вписывалась в Continuous Delivery. Отедельно хочу заметить, что ближе к концу видео есть схемка процесса которая четко показывает (да и спикер сам говорит) что delivery pipeline у них начинается уже после того как прошло тестирование.


Testing in Continuous Deployment from Øredev Conference on Vimeo.

6. Евангелись web performance про нововведения на уровне стандартов

Напочитать: Хабарок

В этот раз очень уж много с Хабра скопилось.

1. Мой добрый друг  и коллега Максим Шульга поведал о том как они делают интеграционное тестирование vGate на базе Jenkins и FitNesse.
2. Про то как быть реактивным с Project Reactor и чуть-чуть Java 8.

Going Reactive - High Performance JVM Code with Reactor from JAX TV on Vimeo.
3.  Не помню было или нет, но вот вам штукес, который используется при отладке High-Frequency Trading систем (биржевые роботы то бишь) и позволяет сбрасывать на диск кучу всякого. В связке с предыдущим пунктом может быть  ого-го-го!.

4. Все начаали страдать API. И как следствие все начали думать над тем как его версионировать. Про способы, их преимущества и недостатки - раз и два.
5. Перевод часов случился, так что тем кто еще (а таких поверьте мне много) - курите.
6. Quick Start Guide по Robot Framework - no comments.
7. Продолжая тему Fault Injection которую я поднимал не так давно - ребята из Netflix тоже делают хитрые декораторы.
8. Как сделать расширение для Chrome если вы хипстер.
9. Десктопное приложение с блекджеком и шлюхами с видео и звуком внутри Docker-контейнера - да, можно.

Ну и на гуманитарные темы.
10. Про то как вставить группу тестирования в SCRUM
11. Еще раз про холократию.  - ну не готовы вы еще к этому, и не будете , если не попробуете :) 

А еще вчера вечером я был на CodeFreeze с Борисом Вольфсоном про ретроспективы и думаю что я напишу ряд постов про эту практику.

Что такое Fault Injection с картинками и примерами

Теория.

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

(так выглядят сервисы внутри twitter, источник) 

И вот с этого момента нас начинает интересовать, что будет с нашим приложением А если приложение Б от которого оно зависит ляжет или начнет себя неадекватно вести.
Этим аспектам уделяют мало внимания, в лучшем случае - падение одного приложения потянет за собой крэш всей системы (пользовательской).
Это хорошо и правильно - если вы не видите для себя  другого способа, то пусть будет хотя бы так.

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

1. Естественно у вас такая защита должна быть. А вот всунуть ее в legacy-код или продукт дизайн которого таких возможностей не предусматривал не так просто.
2. Уровень и с которого "падаем" и глубина падения. Если говорить про стандартную трехзвенную архитектуру, то тут фантазии особо разгуляться негде.
   Все намного интереснее  - често говоря просто эта задача актуальнее - когда у вас SOA или микросервисы. Здесь и уровней больше, типы и глубина падения тоже могут быть разными. Про типы хочется написать отдельно - это может быть как и просто генерация исключения для тестирования того что приложение стабильно его обрабатывает, проглатывает и снаружи ничего не видно, так и внедрение более изощеренного поведения - эмуляция неправильной конфигурации приложения, изменение диапазна типовых значений для экспериментов над поведением. Про банальности типа потери соединения с БД во время работы  - молчу.
3. Крушение приложения. Отдельная тема для распределенных систем особенно для тех что занимаются in-memory вычислениями (Storm, Kafka, Mesos, Suro). Что произойдет с блоком данных отправленным на in-memory обработку если обработчик сдох? Крушения опять же могут быть разными, но тут очень много специфики у каждого. 

Довольно теории, перейдем к практике.

Практика.

Для практики я построил на коленке простейшее вэб-приложение на Java (Jetty inside).
Приложение отзывается на три урла.
http://127.0.0.1:9090/doWork - отдает рандомное целое число от 0 до 1000.

http://127.0.0.1:9090/fault?mode=enabled - включает fault-режим
http://127.0.0.1:9090/fault?mode=disabled - выключает fault-режим

После включения режима падения генератор случайных числе начинает отдавать 0 или 1. Это и есть наше падение.
http://127.0.0.1:9090/crash?time=15 - падение приложения через  указанное время (опционально, если не указано, то упадет сразу).

Как оно организовано изнутри.

Внутри все сделал по максимуму просто - интерфейс генератора случайных чисел задекорирован и на уровне декоратора отрабатывает бизнес-логика использования или неиспользования fault-режима.


Код приложения выложен на github.

Хочется более приближенных к реальности примеров - их есть у меня.
Вот например ключи запуска Chromium

Книга: Как тестируют в Google

Предыстория.
Сначала я узнал о том что книжка переводится, потом о том что первые 1000 экземпляров разошлют в QA подразделения по стране, потом попал в гости в Innova к Жене Ткаченко и его коллегам.

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

Пожалуй самый галвный инсайт который я извек из книги - Google настолько продвинулся в области тестирования не сам по себе и не с нуля - это все из Microsoft.

Все три автора книги (Джеймс Уиттакер, Джейсон Арбон и Джефф Каролло) до этого работали в Microsoft. Патрик Коупленд - руководитель направления продуктивности разработки  - тоже 11 лет отпахал в Microsoft. На мой взгляд половина успеха гугла заключается в том, что эти (и другие) люди принесли с собой такую гору экспертизы, какую мало где можно найти.

Книга хорошо переведена и структурирована.
Еще одной замечательной особенностью книги является то, что она приводит мысли в голове в порядок и позволяет им сформулироваться четко и кратко (twitter-формат :))
У меня набежало почти 40 поинтов, кому интересно ознакомится можно тут.

Оценка 7.5/10

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

P.S. это становится хорошей традицией - издавать хорошие книжки на русском, давайте ее продолжать.

P.P.S К сожалению завтра не попадаю на презентацию "Заона малинового варенья" Джерри Вайнберга где я соучаствовал.

Видео - Про тестирование в Agile

Хороший молдавский тренер - это как хороший французский коньяк. 

Только молдавский. 

И тренер.

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

Собственно смотреть вот сюда.
http://testitquickly.com/2013/11/27/tine-nasul-cumsecade/

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

Одна фраза о том, что "тестировщиков в Agile никто не приглашал"  (с) А.Лупан - можно считать самым емким выражением того что происходит вокруг.

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

P.S. Ну вот есть и еще один повод сгонять в Киев.
P.P.S. Леша, у тебя талант.

Полезняшка: YouTube как генератор данных

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

Решение.
Много видео и ссылок на них на YouTube.
А у YouTube есть API.
По шагам.

1. Регаем гугловый акканут.
2. Идем в API Console (https://code.google.com/apis/console)
3. Активируем там YouTube API
4. Получаем ключ для отправки запросов YouTube на поиск видео.
5. Отправляем запросы, получаем результаты. 
6. ????
7. PROFIT!

Пример кода для отправки запросов тут.
Спасибо Гуглу за API - ребята, вы круты.

Мероприятие: SeleniumCamp 2013 в Киеве

В этом году мне представился случай стать докладчиком на SeleniumCamp, я решил им воспользоватся.
Дальше будет мой обзор данного мероприятия, то что я успел увидеть.

Место.

Киев, БЦ "Парус".
От нашего отеля (мы жили в Космополите) добираться было не очень удобно, но это не критично - цены на такси в Киеве демократичные (по сравнению с Москвой и Питером), пробок также не наблюдается.

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

Организация мероприятия.

Тут я могу сказать только одно - XPInjection все сделали отлично.
Все было продумано до мелочей - всегда можно взять программку конференции даже если ее потерял, всегда можно попить кофе и найти бутылку воды, есть место для курения, лаундж для посидеть и поговорить.
По уровню комфорта - конференция оправдывает те деньги, которые за нее просят (чуть более чем полностью).
Организаторы устраивали для докладчиков afterparty после каждого дня конференции - тоже очень приятная и полезная практика.  В первый день я успел его посетить, во второй к сожалению нет - улетал на утро из Киева в 6.00.

Доклады.

Основной печалью конференции было то, что не смог приехать Francois Reynaud, который должен был рассказывать про плагины к Grid.
Дальше буду рассказывать только про те доклады которые успел, посетить.

• Less Selenium, more unit testing , Dima Kovalenko, GroupOn - доклад про то, что если есть возможность тестировать без Selenium-а , то лучше это и делать. Используйте Jasmine, об этом уже не только Дима рассказывал.

• Using Selenium At Google Scale, Daniel Wagner-Hall, Google UK - в принципе интересный доклад.
• Дэниел рассказывал о концепции использования Hermetic Servers - сервер который инкапсулирует внутри себя все тестовое окружение и интеграцию с внешними сервисами. Гораздо более интересной оказалась беседа лично с Дэниелом - больше деталей и подробностей было выведано.

• Test-driven web development with Selenide, Андрей Солнцев, Вадим Герасимов, Codeborne - честно не понял, почему они сделали Selenide именно так, но подход имеет право на жизнь.

• Тестирование безопасности web приложений с использованием Selenium и Zed Attack Proxy (ZAP), Антон Шапин - интересный доклад про Zed Attack Proxy. Раскрыты не все моменты, но буду ковырять сам.

• Getting started with GhostDriver, Ivan de Marino - автор и главный разработчик Ghost Driver интересно рассказывал про то, что есть Ghost Driver и про то, почему он не всегда фиксит баги. В целом следующий релиз Ghost Driver должен быть многообещающим.

• Наш путь от 90 до 6500 тестов. За кулисами, Иван Медведев, СКБ Контур - не знаю было ли это случайно или специально, но Иван отлично разогрел публику на открытии второго дня. Весело, по делу, улыбнул. 

• Single-page vs. Multi-page. Особенности автоматизации тестирования., Татьяна Курносова,  2ГИС. Не совсем понял о чем этот доклад. Точнее даже зачем его было делать.

Общее впечатление от того, о чем рассказывали на конференции сложилось следующее.
На постсоветском пространстве тяжелая беда с квалификацией тех, кто приходит в автоматизацию тестирования.
Судя по темам докладов от "наших" докладчиков - люди которые идут в автоматизацию тестирования у нас не понимают, что это инженерная профессия.
Поэтому и много докладов на тему того, как правильно начать что-то делать - докладов, кстати говоря, хороших.
В странах  "загнивающего империализма" - уже наоборот.
Software Engineer in Test, который объясняет Software Engineer как писать код так чтобы он был тестируемый - в порядке вещей.
При этом сам Software Engineer in Test тесты не пишет, а строит инфраструктуру для того, чтобы команда могла автоматизировать тестирование с наименьшими трудозатратами.

Для себя я сделал вывод, что "мы" и "они" просто находимся на разных этапах зрелости процесса.

В целом - мне понравилось.

Большое спасибо Коле Алименкову и Алексею Солнцеву за отличную организацию мероприятия. Из последних конференций по тестрованию на которых я был - SeleniumCamp была лучшей.

О странном и недостающем

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

JMeter/SoapUI хорошие тулы, но не для Web-приложений.
Потому что web - он асинхронный. Не нужно пытаться это понять, нужно просто запомнить.
Он асинхронный от браузера до сервера, внутри сервера, от сервера до браузера в обратном направлении и уж внутри современного браузера тем более.

Поэтому тестировать производительности web-приложений с помощью JMeter (по факту получать какой-то HTTP Status Code, или даже полноценный ответ) не получится.
А есть еще и JavaScript и event queue внутри браузера.

Но тем не менее очередное поколение юнлингов стремится одним сокрушительным ударом победить такого зверя как Web Application Performance Testing, не понимая что он дан нам всем не для побед, а для просветления внутри себя.

Ну и чтобы уж совсем показательно  - пример перекрестного скрещивания JMeter и WebDriver.

Пара мыслей вырванных из контекста

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

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

Вырваны они были из занимательного чтива от Jez Humble про то почему не может быть такой вещи как DevOps Team.

Link: Автоматизация тестирования мобильных приложений на примере eBay

Вкратце: Автоматизаторы в eBay настолько суровы что смогли заинтегрировать Selenuim Grid как с Android, так и с Apple UI Automation. Называется это все Calabash и iOS Driver, оба выложены на GitHub

Mobile Test Automation at eBay from Dominik Dary

Полезняшка: Сброс кэша Opera с помощью Selenium

Как я уже писал вот тут мне потребовалось иметь возможность сброса кэша всех браузеров.
Вот расковырял как это делать с Opera.

OperaProfile operaProfile = new OperaProfile();
operaProfile.preferences().set("Cache", "Cache Docs", false);
operaProfile.preferences().set("Cache", "Cache Figs", false);
operaProfile.preferences().set("Cache", "Cache HTTPS After Sessions", false);
operaProfile.preferences().set("Cache", "SVG Cache Size", 0);
 
operaProfile.preferences().set("Disk Cache", "Cache Docs", false);
operaProfile.preferences().set("Disk Cache", "Cache Figs", false);
operaProfile.preferences().set("Disk Cache", "Cache HTTPS", false);
operaProfile.preferences().set("Disk Cache", "Cache Other", false);
operaProfile.preferences().set("Disk Cache", "Media Cache Size", 0);
 
operaProfile.preferences().set("OEM", "Operator Cache Size", 0);
 
 
operaProfile.preferences().set("User Prefs", "Automatic RAM Cache", false);
operaProfile.preferences().set("User Prefs", "Cache Directory4", "");
operaProfile.preferences().set("User Prefs", "Cache Style File", "");
operaProfile.preferences().set("User Prefs", "Max Number Cached Bitmaps", 0);
operaProfile.preferences().set("User Prefs", "Operator Cache Directory4", "");
operaProfile.preferences().set("User Prefs", "Strategy On Application Cache", 0);
operaProfile.preferences().set("User Prefs", "Maximize New Windows", 1);

Запуск тестов под различными окружениями с помощью Maven

Зачастую при запуске тестов необходимо иметь возможность быстро настраивать параметры их запуска, а если говорить еще более приземленно - набор тестов зачастую запускается с испльзованием одной из нескольких конфигураций параметров.
В этом месте каждый становиться кто во что горазд - конфигурационные файлы, переменные окружения, пользовательский ввод, и даже наличие отсустсиве определенных файлов на жестком диске (дадад!!! и такое я тоже видел).
Сказать что конфигурационные файлы  - это плохо - нельзя, очень-таки даже хорошо, вот только переключаться между ними не всегда удобно, особенно если запуск происходит на Continuous Integration сервере.
Один из приемов который я нашел для себя - это создание профиля запуска.
Дальше речь будет идти об использовании Maven, однако не думаю что есть сильно большая разница как это делать используя другие инструменты.

Итак Maven славен тем что имеет возможности управления зависимостями проекта, плагинную архитектуру, свойства и ... профили.
ПРофили свборк в Maven  позволяют переопределять массу всяких свойств в зависимости от указанного профиля.
Подробнее - в документации к самому maven.
Суть предлагаемого мною приема состоит в следующем:
В pom.xml определяется набор свойств, одним из которых является путь к файлу с настройками конфигурации.
В pom.xml определяется ряд профилей, которые переопределяют значение указанного свойства в зависимости от нужд.
Вот так  например

Итого имеем:
ряд файлов конфигураций
Ряд профилей
одно (или сколько вам нужно) конфигурируемых свойств
единый механизм конфигурирования вида
mvn clean install -P

C первого взгляда ничем не лучше того что было в самом начале.
Но.... "набор тестов зачастую запускается с испльзованием одной из нескольких конфигураций параметров." - вот это место и можно зафикировать.
В нашем случае фиксация данного места производится с помощью создания ряда job-ов на сервере CI.
И за полгода у нас их не стало более 10.
Хотя конечно у данного способа есть свои ограничения на примемение.

Интеграционное тестирование с JUnit

Преамбула
Делаю доклад+презентацию про автоматизацию функционального тестирования на Java.

Амбула
Имею честь наблюдать некоторую массу мнений насчет того, что вот есть TestNG, который как бы наше все.
И все в нем есть и всем он хорош. И даже DI/IoC поддерживает с Google Guice.
А JUnit.... ну он так, для юнит-тестирования и только. Написан программистами для программистов.

И не соглашусь с этим всем безобразием.
Туго скрутив документацию по JUnit в сигару и выкурив ее я за полдня сваял Proof of Concept
того что DI/IoC тоже может работать в JUnit.

Ну а если покурить сорсы TestNG там можно обнаружить много всего жирного для такого кодового фашиста как я.
Например такое

Об обязанностях и ответственности тестировщика

сегодня вещает Джеймс Бах

A Tester’s Commitments

Наслаждаемся