Напосмотреть: GTAC 2016

Каждый год я подаю заявку на GTAC и каждый год получаю отказ.
Я уже даже привык.
Но каждый год отсматриваю доклады.

Итак, мой личный рейтинг с GTAC 2016
1. How Flaky Tests in Continuous Integration - собственно говоря гугл решил привлечь математика к проблеме моргающих тестов. Словил несколько инсайтов, буду курить тему дальше.



2. Automating Telepresence Robot Driving - лидар, пластиковый стаканчик и другие трюки для тестирования системы телеприсутствия. В этом докладе нет большой технической жести, но именно так выглядит тестирование будущего (или будущее тестирования ? ). Таких доклады вдохновляют работать дальше.



3. Using Test Run Automation Statistics to Predict Which Tests to Run - доклад о том на какие ухищрения приходится идти когда запуск тестов длиться долго, а тестировать все равно нужно. В принципе ничего нового, гугл о таких практиках у себя рассказывал еще в 2012 году, но поражает масштаб - словить проблемы запуска всех тестов с которой гугл борется на масштабе 3,5 миллионов тестов и 125 миллионов выполнений тестов в сутки можно и на 30 000 тестов.  Понятно, что Unity  - не Google, финансовая и ресурсная база разные, но кто ж вам гарантирует что вы не окажетесь в подобной ситуации с 10000 тестов. It depends (c)




Ну и еще пара интересных докладов:
Finding Bugs in C++ Libraries Using LibFuzzer  - отличный рассказ про методики фаззинга, теоритическая часть очень понравилась.
OpenHTF - The Open-Source Hardware Testing Framework - ребята из гугла продолжают биться за автоматизацию, в том числе и на железе. Python (не, ну а что еще можно запихнуть в железяку? ), SL4A (про который Сергей Высоцкий рассказывал еще в далеком  2013 в Киеве), плагины.



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

Anyway GTAC остается самой значимой (лично для меня) конференцией  в мире в области автоматизированного тестирования.




Сайт конференции 
Плейлист со всеми докладами.

Напочитать: про уродов и людей

1. Старая и довольно подробная презентация про культуру Netflix от самого Reed Hastings.

2. Как правильно негативно фидбечить подчиненных - спорно по ряду моментов, но тем не менее.
3. Про недостаток скуки у подростков  и что из этого выходит.
4. Про наказания и как с этим быть менеджеру.
5. Серотонин снижает восприимчивость отрицательных явлений, эндорфины вызывают эйфорию бегуна и другое интересное про нейромедиаторы (1,2,3)
6.  Замечательная Camilla Fournier об обратной стороне (сторонах) инженерных организаций.



И ковыряя ее выступление наткнулся на описание карьерное лестницы инженера в ее компании.(тут вот еще документик и поясниловка, очень интересно да).

7. Об синдроме самозванца (impostor syndrome )


Ну и в качестве десерта мысль от Хенрика Книберга

Here’s the thing. Suppose you introduce a change X to your workplace, and then business improves noticably. That doesn’t mean X caused the business to improve. Well, MAYBE it did. Or perhaps business improved for other reasons, and X was actually detrimental, and business would have improved even more without it. So did things work out well because of the great X, or despite the lousy X? You’ll never know, unless you could rewind the clock and play out the same scenario without X. Correlation doesn’t imply causation.

So people like me who work with organizational change, we are in the business of pseudo-science. We get customer feedback and anecdotal evidence, but we can’t actually prove that we are doing any good, it’s just opinions and observations and guesswork. I think that’s fine, but let’s be honest about it 🙂

Напочитать: Про разработку

Разгребаю скопившееся летом. 

1. Отличный доклад с обзором проблем распределенных систем.
2. В очередной раз про Property-Based Testing 
3. Как писать интеграционные тесты с ElasticSearch и LDAP рассказывает Micha Kops. Вообще, надо сказать, что его учетка на Bitbucket вызывает во мне чувство, которое можно передать только одной картинкой. Но молодец, да.

4. Отрелизили 20 версию Guava, в  которой появилась кучка нового, в том числе и пакетик с классами про графы.
5. Весьма интересный и крайне простой инструмент  - Architectural Decision Records. Только я бы не оформлял каждое  решение в отдельный документ, их надо слегка смантически структурировать.
6. Пространный набор предъяв к Docker. Обоснованно, чо.
7. О том как тестировать код с RxJava - тут.
8. Отличная байка от Тагира Валеева про лямбды и анонимные классы.
9. Тяжелая наркомания про генерацию исходного кода или диалекты Java - recaf
10. Рассказ про нюансы ProtoBuf
11. Бенчмарк (несмотря на то что Шипилев не велит) 114 алгоритмов хэширования.
12. Rocket Data и Falcor - два очень интересных проекта под IOS и Android от LinkedIn и Netflix соответственно которые представляют собой Middle-Tier для данных  в мобильных приложениях.
13. В Google уже совсем охуели в атаке перестали заморачиваться на тему вопроса "зачем оно надо?" и захерачили еще один фреймворк для DI - Tiger.
14. Yahoo (жив, курилка) заопенсорсил Pulsar - своя Kafka с преферансом и куртизанками.

Ну и напоследок - философское :

Probably the biggest problem is the state-space. Software is highly non-linear and discontinuous, unlike for example a bridge, or most other physical objects. If you change or remove a single bolt from a bridge, it is still the same bridge and its characteristics are largely the same. You need to remove quite a number of bolts for that to change, and the effects become noticeable before that (though they do get catastrophically non-linear at some point!). If you change one bit in a piece of software, the behavior is completely unpredictable. It could be the same, it could just crash, it could quietly corrupt data. That's why all those corner cases in the layers matter so much. Again, coming back to the bridge, if one beam has steel that has a slightly odd edge-case, it doesn't matter so much, you don't have to know everything about every beam, as long as they are within rough tolerances. And there are tolerances, and you can improve your odds by making things with tighter tolerances than required. Again, with software it isn't really the case, discrete problems are much harder than continuous ones.

Напочитать: Автоматизация тестирования 18+

1. Запускать тесты c использованием Sikuli на гриде - Sterodium.
2. European Testing Conference озвучила даты и выложила видео с прошлого года.
3. Два очень похожих доклада про верификацию распределенных систем. Взгляд скорее академический, чем прикладной. Но интересно. Ines Sombra и Caitie McCaffrey.
4. JSONAssert - неплохо, но я бы стал пользоваться JSON Schema.
5. Facebook открыл то о чем они говорили еще в 2013 - инструмент для screenshot-based testing под iOS.
6.  Аналог BrowserMob Proxy только написан на Go и от Google - martian, и апишечка для управления ей в комплекте.
7. Продолжая тему управляемых проксей, мой (пусть уже бывший) коллега Николай Мазуркин запилил  проект NetCrusher - управляемая прокси на чистой джаве для интеграционного тестирования.  Тредик с доп.информацией и срачиком на фейсбучке.
8. Специфика тестирования IOS в исполнении LinkedIn
9. Зарелизился Watir 6.0 - интересно кто-то им (еще) пользуется интенсивно ?
10. Опыт Facebook о тестировании производительности клиентского кода. TL;DR: замокать и запроксировать все нахер и радоваться что находите регрессию на последней миле и пофигу что мультипликация ошибки может дать сильно больше.
11. Be prepared to allocate at least one week a quarter per test to keep your end-to-end tests stable in the face of issues like slow and flaky dependencies or minor UI changes - говорит нам Гугль.
12. Артем Кошелев про docker для тестирования на Android устройствах и фильтрацию устройств и эмуляторов.
13. Про то как в Netflix тестируют на реальных устройствах.
14. Про то как в Badoo патчили Selenium
15. LinkedIn опенсорснул  TestButler - тестовый агент который помогает жить на Android легче и веселее.
16. Цитирую
There, tests must demonstrate stability for at least one week before being promoted.
...
Once a test has demonstrated its reliability, it is promoted into one of two sets. The first set, BVSBlocker, contains tests that indicate whether a build is even worth further testing. A build which fails Blocker isn’t deployed to a testing environment, because either games aren’t starting or there are multiple severe crash bugs affecting the game. Its counterpart, BVSCore, is our core set of functional tests, including tests for every champion ability. - и другое про автоматизацию тестирования самой популярной игры 2016 на мобильных  устройствах от Riot Games.

Ну и на десерт - чем тестировщики в гуглях занимаются:

To give you an idea of what TEs (Test Engineers - прим.ред.) do, here are some examples of challenges we need to solve on any particular day:

• Automate a manual verification process for product release candidates so developers have more time to respond to potential release-blocking issues.

• Design and implement an automated way to track and surface Android battery usage to developers, so that they know immediately when a new feature will cause users drained batteries.

• Quantify if a regenerated data set used by a product, which contains a billion entities, is better quality than the data set currently live in production.

• Write an automated test suite that validates if content presented to a user is of an acceptable quality level based on their interests.

• Read an engineering design proposal for a new feature and provide suggestions about how and where to build in testability.

• Investigate correlated stack traces submitted by users through our feedback tracking system, and search the code base to find the correct owner for escalation.

• Collaborate on determining the root cause of a production outage, then pinpoint tests that need to be added to prevent similar outages in the future.

• Organize a task force to advise teams across the company about best practices when testing for accessibility.

Напосмотреть: Технический

1. Social hacking в действии или почему если вашу компанию захотят взломать - взломают.

2. Что такое machine learning и нейросети в примерах и картинках

3. Подробный рассказ о том что такое JUnit 5 (Lambda)


4. Артем Ерошенко про приготовление облачных тестовых стендов


5. Выученные уроки от Netflix про микросервисы. В принципе ничего нового, просто концентрированно. (А вот тут можно посмотреть откровения от Uber чтобы  понять что бывает когда учишься только своих  ошибках)

6. О том что интересного можно нарыть в вашем репозитории с кодом, коммитах и прочем.
MINE SOCIAL METRICS FROM SOURCE CODE REPOSITORIES from Øredev Conference on Vimeo.

7. Роман Поборчий о реальных и фундаментальных проблемах A/B-тестирования.

Badoo TechLeads Meetup

В субботу, 15 октября в Москве прошел Badoo TechLeads Meetup.
Я хотел было проанонсировать это событие, но на момент когда начал писать анонс регистрация уже была закрыта, так что он был бы излишним.

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

Место 

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

Организация 

Все хорошо, ничего особенного сказать не могу.

Доклады 

"Мобильный веб: назад в будущее" Виталий Шароватов,Руслан Байрамкулов
Ребята рассказали о том как они ускоряли релизы в мобильном вэбе. Опыт лично мне был довольно близок, да и проблематика у нас с ними схожая.

"Багфиксинг процесса разработки в iOS: взгляд с двух сторон", Екатерина Николаенко, Катерина Трофименко

Интересный рассказ про модификацию процесса релиза iOS приложений. Очень удивила роль "Багфиксера", но потом вспомнил про целый "Stabilization team" в Facebook :).
Вообще  чем больше наблюдаю эпопею развития мобильный приложений, тем чаща на поверхность всплывают вот какие мысли:
1. Мобильные приложеньки - это тот же самый десктоп из 90-х, когда софт писали на болванку/дискеты и он ехал к потребителю, где ставился в совершенно непонятном и незнакомом окружении.
2. Инструментальные средства разработки мобильных приложений конечно эволюционируют, но до иниструментов отладки и диагностикти web-a и server-side им как до китая раком очень далеко. И ждать чудес не стоит - либо начинать строить инструменты сами, либо пользоваться webview, со всеми вытекающими отсюда.
3. Проблематика расширяющейся матрицы устройств - одинковая у всех, особенно в контексте Android и китайских телефонов. Думается мне что вендоры скоро подрежут открытость платформы.


“Технологии vs коммуникации: что важнее?", Альгис Фатеев
Доклад о неизбежной эволюции процессов в Avito.
Отличные формулировки мыслей - "занимайтесь своими процессами сами, если не хотите чтобы ими занимались аудиторы от акционеров".
Мне кажется многим организациям не хватает как раз той самой сборной аудиторов от акционеров, которая регулярно бы трясла их.


Был еще четвертый доклад, но я его не слушал - по ряду объективных причин.

Итоги

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

Презентация тут, видео воспоследует.

Напочитать: Психо

1. О том, что геймдеэв потерял всякую совесть и страх и манипулирует людьми.
2. Зачем вам нужна девочка на телефоне и что хотят все эти люди - социнжиниринг для атак на  офис.
3. Иерархия оказалась вредна для кооперации в группе - да,ладно ?!?!?
4. Тут пошла волна выступлений,  подкастов и статей  про то как быть программисту-тестировщику в возрасте. Тренд собственно туда и идет - отрасль взрослеет, как ни крути.
5. Зак Холлман, который раньше был в GitHub говорит нам следующее -

But look around: how many small, less-than-50-person startups are doing work like that? The dirty secret is most startups for the first few years are glorified CRUD apps, and finding well-rounded and diverse people who can have the biggest impact tend to be the ones who are comfortable wearing a lot of hats.

ну и далее, о том почему Startup interviewing is fuked.  И, да, бложек Зака попал в реестр блокировки РосКомПозора , но я думаю вы справитесь :)
6. О том что нужно нанимать личность, а не сборник навыков/ответов на вопросы.
7. Эффект IKEA - люди склонны переоценивать стоимость если они вложили туда немного своего труда.
8. О том что такое внутренние коммуникация и зачем оно надо.
9. То чаво не может быть - Open Salary. Очень интересно если кто-нибудь еще накидает ссылок на эту тему.
10. Google открыл свой курс для менеджеров.
11. Сет Годин про то что нужно делать/делают маленькие команды на ежедневной основе.
12. Как оценить что угодно методом Ферми.
13. Паттерны холакратии - посмотрите на свою орг.структуру в контексте этого, может чего узнаете.
14. Почему большинству студентов пиздец на рынке труда
Ну и самое главное - Бертран Рассел, о важном

Пассивное принятие знаний учителя легко даётся большинству молодых людей. Оно не подразумевает усилий независимого мышления и кажется разумным, ведь учитель знает больше учеников. К тому же, это способ завоевать благосклонность учителя. Однако привычка пассивного принятия имеет катастрофические последствия для дальнейшей жизни. Она заставляет людей искать себе лидера и принимать в качестве лидера любого, кто обосновался в этом положении. Она порождает власть церквей, правительств, партий и прочих организаций, посредством которых простых людей обманным путём заставляют поддерживать старые системы, губительные для страны и для них самих. Если бы целью было научить учеников думать, то вместо того, чтобы заставлять их принимать готовые выводы, образование осуществлялось бы по-другому: было бы меньше спешки в объяснении, больше обсуждения, больше возможностей для учеников выражать свои мысли. И, в первую очередь, было бы стремление возбудить любовь к интеллектуальному поиску.

Напосмотреть: North, Dan North

Английский язык для меня не родной (с чего бы это!), поэтому слушать низкопробные и дохлые доклады на английском у меня долго не получается.
 К тому же английский, по моему стойкому убеждению, является самым информационно-емким языком - то что на русском будет звучать как сложноподчиненное предложение в английском умещается в три слова.
Живых  докладчиков на английском языке тоже есть, но те кто делает это регулярно на системной основе - мало.
Один из таких - Dan North (@tastapod).
За последние две недели из разных источников я посмотрел три его видео и все они хороши.


Про то почему Agile не скалируется и что из этого следует

Про паттерны delivery

Про простоту


Ну и в качестве вишенки на вершине тортика - Dave Thomas про то почему у всех аллергия на слово Agile

Мероприятие: QA Meetup в Нижнем Новгороде

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

Место

Нижний Новгород, Центр Международной Торговли.
Площадка хорошая, центра города, отличный вид из окна. Погода дала жару, поэтому даже мне совесть не позволяет предъявить претензии к кондиционерам.

Организация

Все хорошо, все вовремя.

Доклады

Наталья Чуфырина рассказала про то как учить людей автоматизации и как это делают они. Полезно, особенно в ряде моментов которые изучил своим лбом и на своей шкуре.

Юлия Сомова про микросервисы которые помогают автоматизации тестирования Почты@Mail.Ru. Слушая доклад Юли я пришел к мысли? что спустя какое-то время любая большая (ну или значимая) автоматизация тестирования становится похожей на соседей по отрасли.

Алексей Халайджи про автоматизацию тестирования IOS - хорошо и с инсайтами.

Максим Богуславский - про то как взращивать в себе автоматизатора. Годно.

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

Был еще один докладчик, но его выступление я смотрел с "другой стороны баррикад".

Слайды презентации

Clouds, API and why you should care as a tester? from Nikita Makarov

Видео - спасибо киностудии Boguslavsky Films и главному режиссеру, сценаристу и видеооператору Максу Богуславскому за то, что попытался сделать из моего выступления блокбастер :) . Видео остальных докладов будет позже.

Часть 1


Часть 2



Код лежит на гитхабе
https://github.com/kronar/testcontainers-eval

Напочитать: Автоматизация тестирования: Disruptor

Два доклада про тестирование в LMAX  вдохновили.

Потому и  Disruptor.

1. Адовый рассказ про то как делать Continuous Delivery на биржеквых проектах от LMAX.

2. Продолжение темы, только более философское, но тоже от выходца из LMAX.

3. Про автоматизированное тестирование CRIU и суровый линуксовый жесткач
4.  Подборка статей от пользователя @irony_iron на хабре про автоматизацию очень сурового системного тестирования - антивирусы и перезагрузки, инсталляторы, автологины в винду. Очень хардкорно!
5. XPath, JsonPath... теперь GPath - очередная path-нотация для JSON. Но в RestAssured.
6. Про то как скалировать тестирование на Robot Framework под Docker - презентация, видео, код
7. Про Jenkins Workflow - с картинками и примерами.
8. Log4J теперь говорят не тормозит.
9. Almost 16% of our tests have some level of flakiness associated with them! This is a staggering number; it means that more than 1 in 7 of the tests written by our world-class engineers occasionally fail in a way not caused by changes to the code or tests - и другие интересности от Google как они борятся с  flaky tests. Спойлер: все банально!!!
10. Про автоматизацию тестирования c мобильными устройствами , но не теми про которые вы подумали.
11. Маленький хак для тех кто использует Spring Test.
12. Гойко Аджич про то как сократить издержки на большие тестовые наборы - на самом деле тэги по функциональности, отсутствие зависимостей при запуске тестов, выделение утилитарного слоя кода, хорошие имена для тестов.
13. Про то как взять и упороться функциональщиной из Java8 в Selenium-тестах - с примерами и картинками.
14. Очень полезная вещь - Jenkins-у можно править конфиги удаленно, сам несколько раз пользовался.
15. PowerShell и Jenkins.
16. Github выпустил Spectron 3.0 - тестовый фреймворк для своего поделия Electron (Desktop приложения на node.js) написанный поверх  CrhomeDriver и WebDriverIO.
17. Maven + JUnit + интегрционные тесты  и все как мы любим.

Книга: Уильям Детмер. Теория ограничений Голдратта.

Собственно давно я не писал обзоров на книги.
Тому была масса причин: во-первых, пачка книжек купленная у МИФа (Кэрол Дуэк и Осознанность) оказались полным фуфлом, где авторы размазывают одну мысль на 400 страниц, а во-вторых, хотелось хорошего, "тяжелого", чтива, с хардкором, мыслями, так чтобы котелок кипел.
Вот собственно и достал с полки ту книгу, которая стояла в списке на прочтение еще с момента отзыва на нее Макса Дорофеева.


Итак, если вы не читали "Цель" и "Цель-2" Голдратта и/или не знакомы с Теорией Ограничений, то нырять в эту книжку вам не стоит вообще - ни в скафандре, ни без него.
Как я писал ранее, во втором томе "Цели" Голдратт обрисовал практические случаи применения тех или иных инструментов, но не расскзаал методику, видимо оставляя для себя возможность заработать не только на книге, но и на тренингах.

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

Итак, "мыслительные инструменты" Голдратта по факту состоят из 5 деревьев которые нужно  последовательно применять при проведении изменений:

1. Дерево текущей реальности - чтобы понять что менять
2. Диаграмма рзарешения конфликтов - чтобы понять конфликт интересов который не позволяет провести изменения 
3. Дерево будущей реальности - чтобы проверить куда приведут изменения и приведут ли они туда куда нужно, какие еще последствия будут
4. Дерево перехода - позволяет ответить на вопрос "что еще нужно для того чтобы все получилось?" и определить с какими препятствиями вы столкнетесь.
5. План перехода - пошаговый план проведения изменений, вытекающий из предыдущих 4 пунктов. 

Читая книгу, меня не покидало ощущение того, что я все это уже где-то видел и даже делал.
Не, ну на самом деле: дерево текущей реальности - это Root-Cause Analysis как ни крути, диаграмма разрешения конфликтов - это суть есть mind-map, только выстроенный по определенной семантике.

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

Собственно наверное рафинированным смыслом книги и является - вложить в голову читателю две вещи:

1. Стандартный менеджерский фреймворк "Что менять? На что менять?  Как провести изменения чтобы все не разлетелось к херам ну и результаты тоже было бы неплохо поиметь ?"
2. О чем нужно еще подумать при ответе на каждый вопрос из п.1 

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

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

Итого
Читать - стоит.
Голдратту за "мыслительные инструменты" - 4 с минусом - мог бы и сам с нормальными примерами расписать.
Детмеру и российскому изданию - 3 с минусом - только потому, что тренинги стоят сильно много денег.

Анонс: 17 июня - QA Meetup в Нижнем Новгороде

17 июня в Нижнем Новгороде будет проходить QA Meetup.


Адрес:  г. Нижний Новгород, Ковалихинская, д.8, Центр Мировой Торговли, Медиа Страйк Холл (10 этаж)

А ну и да, спойлер доклада, как обычно

Они учат тестировщиков программировать

История и причины возникновения научной дисциплины
критически важны для понимания самой дисциплины.

Н.М. Светлов, первая лекция по Теории Систем и Системному Анализу.

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

Вы знаете кто такой Бэри Боэм? 

А про спиральную модель разработки ПО ? 

Это все было задолго до всяких Lean/Minimal Viable Product, а идеи-то те же.

Так вот, разработка Боэма и тестирование Бейзера - это одна история нашего тестирования, да и вообще всего IT.
Точнее даже первая, которую в контексте тестирования начал Джерри Вайнберг в 1958 году:

We made the first separate testing group that I know of historically (I’ve never found another) for that Mercury project because we knew astronauts could die if we had errors.We took our best developers and we made them into a group. It’s job was to see that astronaut's didn’t die. They built test tools and all kinds of procedures and went through all kinds of thinking and so on. The record over half a century shows that they were able to achieve a higher level of perfection (but it wasn’t quite perfect) than had ever been achieved before or since.


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

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

И тестировали этот коммерческий софт тогда в том числе и те, кто вышел из околовоенки.
Именно этим я объясняю лично себе, то количество "незаменяемого" софта написанного на COBOL/FORTRAN и прочем - это хороший софт написанный для коммерции, но с критериями качества, унаследованными от "военки".
Вообще весь второй этап  можно охарактеризовать одним словом - специализация.
Потому, что тогда нужно было делать много сравнительно похожего софта, это было массовое производство, с присущей ему специализацией и конвеером.
Нужно рисовать много UI, нужно много администрировать БД, нужно писать много технической документации.
И специализация людей для каждого этапа - дело вполне себе логичное и даже эффективное.

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

Так вот, собственно говоря, причем здесь "Они учат тестировщиков программировать" ??

А вот, на мой взгляд, ситуация из которой выросло тестирование в первом этапе нашей истории - когда мы делаем высокорисковые проекты, с совершенно непонятным результатом, в совершенно неизвестном домене, где все во что ни плюнь - пипец (!!!), инновации!!!! -  она структурно идентична той ситуации которая сейчас, на третьем этапе нашей истории, наблюдается на рынке, когда все хотят автоматизацию тестирования, чтобы тестировщики валидировали продуктовые идеи, умели читать логи и мониторить продакшен,да еще и в юзабилити разбирались.
С той лишь разницей, что тогда были системы ПВО/ПРО / межконтинентальные ракеты/ Буран , а теперь AirBNB/ беспилотные автомобили/Amazon Prime, который доставляет покупки дронами.

Это все, кстати, и не про тестировщиков тоже - у погромистов (опечаток тут нет) те же самые попабольки - давайте, вы, погромисты, будете знать как это все разворачивается в продакшене, как и где и из чего сделан CI, построите мониторинги, будете работать с метриками с продакшена, запускать A/B тесты на живых пользователях и при этом не требовать прибавку к зарплате на ношпу и анальгин (виски вам может еще наливать???) за то что это типа не ваша работа.
Термин full-stack developer шагает по сайтам для поиска работы.
Потому что в большинстве случаев сейчас не нужно "хорошо, но только вот это", нужно "нормально, но все", так чтобы взлетело, а там посмотрим что пользователи скажут, подкрутим.

Тестировщиков учат программировать, програамистов тестировать и все это в угоду одному - скорости бизнеса.

Все разговоры и выступления типа Testing is Dead/Testing is not Dead - это все стандартная пропаганда молодой поросли, чтобы побыстрее вытеснить старую плесень ну или нечто сродни рыку молодого льва в саванне, когда старших нет рядом и никто не может дать по башке.

Тестирование не живо, и не мертво.
Оно просто эволюционирует, равно как и вся отрасль.
Не надо делать из этого трагедии, нужно делать выводы и строить планы.
Планы развития.
Планы развития себя.

Совершенствоваться не обязательно. Выживание — дело добровольное. © Эдвард Деминг.

P.S. откопал в просторах интернетов вот такую вот летопись. 

Конференции: goto; Conference Стокгольм

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

Место 

Швеция, Стокгольм, здание Мюнхенской пивоварни.
По утверждениям аборигенов - это самая большая и самая крутая площадка в городе, там проводят свои мероприятия  Oracle и Microsoft.
Вид с балкона на центр Стокгольма с другой стороны пролива конечно отличный, но площадка так себе. Основная проблема, как и в большинстве мест - вентиляция. Мероприятие было рассчитано на 200-300 человек, и если бы был аншлаг, то дышать было бы нечем совсем.

Организация 

Может конечно я уже зажрался посещая конференции типа CodeFest и Joker/JPoint, может особенности национального менталитета и иные cultural references, но организация страдала по мелочам то тут, то там.
В нагрузку к кофе от кейтеринга ребята поставили еще одну привозную кофеварку с двумя баристами, у которых за два дня так и не удалось попить кофе, обед организован весьма странно, несмотря на избыток места. WiFi как и на любой нормальной конференции должен лежать, но работал скрипя и падая.

В общем и целом - на 4 балла из 5.

Доклады

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

День первый

Adrian Cockcroft про простоту и сложность систем - открывающий keynote. Очень хорошо, глубоко и с мыслью как и положено быть keynote-докладам.

Ian Missingham про то что есть AWS Lambda и как его надо использовать - это могло бы быть просто хорошим выступлением евангелиста AWS Lambda , но live-demo пусть даже и с минимальным написанием кода обработчика нажатия кнопки на отдельном устройстве - это бесценно и замечательно продает концепцию Internet of Things.

Ken Sipe про то зачем вам Mesos - опять же технический евангелист Mesos, с очень хорошо подвешенным языком и попыткой Live Demo. За рассказ - 5, за проваленное demo - 2, итого 3+.

Madny Waite про то как пользоваться Kubernetes - лично меня уже поражает как 2 или 3 человека из Google могут ездить с одним и тем же выступлением по разными конференциям и показывать один и тот же пример развертывания nginx в облаке. Позор жеж.

Rodrigue Schaefer про то как Zalando (это магазин шмоточный) себя на микросервисы пилили и для чего это. Отличное, но совершенно не техническое выступление - оно про бизнес, про то что это дает.

Adrian Mouat про небезопасность Docker и что с этим делать - доклад который нужно разобрать на цитаты, положить на полочку, а если у вас уже есть Docker в продакшене - нарезать на таски в  джиру.  Очень приземленно и практически, с примерами и картинками.

Adam Tornhill про то что творится с кодобазами - отличный доклад ро скрытые связи в кодовых базах и последствия этого. Статья Адама недавно вышла на InfoQ, а также есть выступление на схожую тему.

Afterparty

Ну тут надо сказать сыграли те же cultural references - 3/4 участников конференции дружно встали и вышли, так как никакого afterparty им нафиг не надо, лечь бы пораньше спать.
Остались спикеры да и то не все, и часть участников. Расстраиваться нечему - небольшое количество народа позволило пообщаться с Эдрианом Кокрофтом и Рэнди Шупом за кружкой пива и поеданием бекона. В качестве развлекухи организаторы пригнали какого-то фокусника, но я видел что он залип в какой-то компании которая общалась на тему Docker-контейнеров - у него afterparty точно удалось. Вообще, за доступ к телам докладчиков после первого дня организаторам стоит поставить отдельный плюсик.

День второй

Организаторы видимо посчитали, что интересные доклады должны быть в первый день, во второй был почти один sales bullshit.

Fred George про то что микросервисы ускоряют бизнес - уже не свежее , но все равно слушается приятно.

Tom Wilkie -  о проблемах мониторинга,визуализации и трассировки облачных инфраструктур. Все сказанное - оно очень правильное, а вот все показанное никак не внушает веры в то что это можно натянуть более чем на 100 сервисов.  А ну и да - хипстерский Go.

Steven Borelli про то как Cisco запилило свой облачный шедулер поверх творчества HashiCorp - этот доклад как нельзя лучше иллюстрирует то количество hype-а и buzz-a  вокруг облачных  технологий, которое сейчас есть на рынке - все пытаются снять пенку, даже Cisco.

Andrew Phillips про то что не тестированием единым сыт должен быть разработчик, метрики с продакшена тоже смотреть надо. Скрытый product-placement Dynatrace.

Мысли 

Собственно говоря, вся конференция рассказывает нам о том что идея облаков прижилась,теперь решаются практические задачи по ее внедрению в реальный бизнес. Облачные шедулеры типа Kubernetes, Mesos, Nomad - то самое ядро, которого не хватало. При том все игроки рынка расчитаны на средний маштаб оперирования  - до 100 сервисов и оперирования через  публичные облака типа Amazon/DigitalOcean. Бизнесу это все продается под соусом того, что вам не нужно ждать пока ваши инженеры поставят/настроят сервера - идите и делайте бизнес, ставьте эксперименты. будьте быстрее конкурентов,а мы (облачные вендоры) вам уже помогли, давайте уже платите деньги - Ian Missingham очень хорошо проиллюстрировал это на примере вот этого вот проекта, где David Guetta собирал сэмплы миллиона голосом для гимна чемпионата европы по футболу,а Amazon им в этом помогал. Стоимость инфраструктуры на амазоне в этом случае была просто копеечной по сравнению с развертыванием реального железа, особенно в контексте краткосрочного и контекстного проекта.

Стокгольм

Стокгольм оставил у меня впечатление чего-то среднего между Ригой, Вильнюсом и Таллином, но только с инфраструктурой Вены, что ли.
Очень спокойно, чистый и свежий воздух за счет того что море рядом (зимой наверное вообще очень свежо), спокойные люди на улицах. Мне повезло с погодой.
Ну и да - цены. Цены в Стокгольме просто конские. Проезд на автобусе от Арланды до Стокгольма - 12 евро (для сравнения в Вене 4-8, автобус - 8), кружка пива - от 6 евро, стрит-фуд - в районе 10.

Если еще раз и поеду на goto Conference, то в другую локацию.

Напосмотреть: Иди ты на ...

Очень много с goto Conf. 

Да и сам я в Стокгольме на goto Conference.

1.  О том как масштабировать системы деплоймента

2. О хорошей концепции 4К - классы, компонены, контейнеры, контекст - Simon Brown
3. О том насколько на самом деле софт дырявый и почему все так этого боятся
4. О том что такое техническое лидерство

5. Андрей Себрант о том что такое Data Science/Cognitive Science куда мы все катимся

6. Александр Прохоров о русской модели управления - его книжка давно стоит у меня в списке на прочтение, но не факт что я прочитаю ее после этого видео - слишком уж мне кажется ретроспектино-объянимой его теория. Но посмотреть стоит, хотя бы чтобы решить для себя - читать или нет.


И да, отчет с самой goto Conf воспоследуэ...

Безалкогольное пиво, резиновые женщины и Maven без XML

Все написанное ниже не претендует на сколь-нибудь значимую долю объективности и является едва оформленным потоком сознания, коий  нашел выход в лоно этой уютной днявочки лишь через мое редкое импульсивное графоманство. Даже более - без прекрасных  выступлений Баруха, Антона и Жени, равно как и отличного доклада Саши и Кирилла ничего этого бы не написалось. Ребята, спасибо вам за вдохновение: если чо - ругать можете идти в комменты. 


Сейчас Maven не ругает только ленивый.
Хотя нет - даже ленивый ругает.

Если посмотреть внутрь всей этой критики, то по сути все сводится к 3-4 пунктам:

1. XML
2. Скачивает тысячи гигабайт зависимостей
3. Невозможность написать что-то свое быстро, невозможность ad-hoc кастомизации сборки
4. Принципы резолвинга зависимостей
    

Начнем с последнего - принципы резолвинга зависимостей - про это вот тут вот написал один очень неглупый Барух. Мне дополнить сюда нечего - maven не идеален, под это дело понаставили всяких костылей типа enforcer-plugin, в Gradle кстати тоже их есть (читать с момента про Fine-tuning the dependency resolution process) и думаю еще будет. Почему я так думаю?  Потому что проблема транзитивных зависимостей или попросту dependency hell просто так вот не решается - тут надо что-нибудь умное придумать с монадами, haskell-ом и страшной математикой.

Едем дальше, вверх по списку - невозможность написать что-то свое быстро, невозможность налету кастомизировать билд под свои нужды.
Ну тут, имхо, все очень  правильно и хорошо. Почему?
Потому что :

1. 99.95% Java проектов на этой планете относятся к категории bloody enteprise (кровавый ынтырпрайз), поставляя из себя стандартный JAR/WAR/EAR, который замечательно собирается maven уже много лет, запускается в Jetty, ставится в app server и далее по списку. Gradle это тоже все наверное умеет, иначе нафиг оно вообще надо.
   
   Android приложения я сюда даже относить не буду - Google прописал gradle как официальный build tool для своей платформы и спорить с этим конечно можно ( а ведь до того как это было maven-ом и android собираали, дада) , но наверное не за чем.
   
   К слову, оставшиеся 0.05% от общей численности Java проектов на планете я отношу к проектам с уникальной природой, которым позволительно как пользоваться и не maven/пользоваться gradle / вообще написать свой build tool типа bazel от Google.  
2. Если вам нужно что-то кастомизировать для своего проекта, то для этого во всех инструментах сборки есть плагины. Отличне maven от gradle в том, что в случае с gradle вы можете написать плагин в коде самого проекта и подключить его. Ну или вынести в отдельный проект, как того требует maven.
   
   Плагины можно писать и там, и там.  Тестировать их тоже можно  и в maven, и в gradle, с той лишь разницей что в maven харнесс для тестирования плагинов внешне напоминает окаменевшее говно мамонта, а в gradle testkit пока еще не устаканился - его переколбашивают с каждым релизом, поэтому у меня вызывает ассоциации с ... не буду говорить с чем. Если же хочется очень быстро нагавнокодить скриптец в билд файле - то идите уже в пункт 3 данной части повествования.
3. Волшебный Groovy и желание творить. Пфф.... ну что сказать, давайте сначала. Вы серьезно думаете, что все инженеры в вашей команде хорошо разбираются в том как устроена сборка их  проекта ? Нет, даже так - вы УВЕРЕНЫ что все инженеры в вашей команде хорошо разбираются в том как устроена сборка проекта ?  Подозреваю, что среди читателей моего уютненького найдутся и те кто ответит  положительно на оба вопроса. Но, en masse, это, по моим наблюдениям, не так.  По моим наблюдениям 3/4 девелоперов не вникают туда. Соответственно их кастомизации на времени сборки проекта и качестве его результата могут отразится вполне однозначно с совершенно неоднозначными последствиями и временем их устранения.  Проще говоря - иметь возможность говнокодить в файлах сборки должны компетентные люди. Вот тут еще один  неглупый  Барух  про это хорошо разложил. Некомпетентным там делать нечего, пусть идут и пишут плагины, еще лучше плагины с тестами. 

Ладно, задержались тут, давайте дальше - maven скачивает полинтернета.
Каждый раз когда я такое слышу у меня в голове начинает пищать модем 56К - да, я настолько стар, что помню когда они впервые появились, потому что до этого были 32К.
Я еще помню интернет по карточкам. (А еще выход Windows 95, оригинальные D-Track и Carmageddon. Какой же я старый.)

Короче - большинство из вас живет в странах с хорошим интернетом, maven и gradle кэшируют скачанные зависимости весьма неплохо, а при наличии в середине между вами и центровыми репозиторями прокладки в виде Nexus/Artifactory проблема как бы сводится минутам к 5 за которые вы успеете хотя бы один раз грязно обругать maven перед коллегами на кухне за чашкой кофе и пойдете себе дальше работать.  Пустое это.

И вот мы добрались до вершины нашего тортика и вишенки на нем - XML.

Хипстеры при виде XML

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

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

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

Не нравится XML - ок, maven умеет не только XML.

Рецепт наступления счастья:

1. Идем сюда, читаем статью http://www.infoq.com/news/2015/03/maven-polyglot 
2. Ставим себе и на сервер CI версию Maven 3.3.1 и старше.
3. Идем на гитхаб
1. Если вы любите YAML, то идем сюда и можем увидеть там такое вот
   
   
   Ну а если заинлайнить плагины, то еще компактнее
   
   
2. Если вам не надо YAML, а хочется чего-то еще - то вам вот сюда.
3. Сравниваем с оргинальным  pom.xml, который приложен  у меня в проекте.
4. Впендюриваем это все себе в проект живем дальше спокойно, с maven.

Вместо послесловия

Когда то давно, в 2006-2007 годах я работал в аутсорсинге и переходя с проекта на проект видел везде одно и тоже - файл build.xml и папочку /lib с заботливо сложенными бинарями внутри.

После того как я попал на проект с maven жить стало легче, стандартнее и веселее.
Maven по сравнению с Ant дал очень много - он дал стандарт и создал целую экосистему вокруг себя.

Конференции: Отсмотрено: Selenium Camp 2016

Опять же - сам не участвовал в этом году, доклады отсмотрел.

Те, что заинтересовали меня :
1. Effective UI tests scaling on Java  - отличный доклад, который раскрывает спектр разнообразия граблей в том случае если вы хотите запускать тесты параллельно. Все по делу. Сергей даже про нас вспоминал :)
2. Grid Router – scalable and fault tolerant solution for grid - Михаил Левин рассказал о том как они в короткие сроки сделали инструмент для раздачи Selenium Grid-ов всем страждущим.
3. Gathering metadata to help test better - очень интересный доклад про то какие метаданные можно собирать из автотестов и куда их потом девать.

Конференции: JPoint 2016

Сходил.

Место проведения, как и в прошлом году, Radisson Славянская, организаторы JUG.ru, поэтому проходится по этим пунктам не буду - все было сделано хорошо.

Доклады

Первый день

Владимир Красильщик про логгирование - хорошо.

Олег Шеляев про монады - вот почему про монады нельзя рассказать без математики и haskell? Ну ведь можно же.

Алексей Зиновьев про Hadoop - очень живо и обзорно.

Антон Архипов, Барух Садогурский, Евгений Борисов с битвой инструментов сборки - смотрел с интересом. Maven по прежнему наше все :) .

Евгений Борисов  про Spark - лучший доклад конференции, имхо.

Максим Дорофеев про воспитание внутренних обезьян - как всегда живо, хотя уже и заезжано.

Афтерпати в Stereo Hall с выступлением Animal Джаз.

Второй день

Keynote-доклад Евгении Тимоновой - может быть мои ожидания были завышены, но для keynote такой уровень не подходит никак. Вяло, тоскливо, без учета специфики аудитории и с кривыми слайдами.

Виктор Гамов про JCache - хорошо, а сеесия в экспертной зоне еще лучше.

Антон Архипов про то как делать профилировщики - хорошо, но Антон глубоко копнул.

Александр Тарасов, Кирилл Толкачев про расширение сознания границ возможного с использованием Gradle. C одной стороны очень приятно наблюдать как ребята делают доклады в паре, да еще и с live-coding, а с другой стороны все равно фанатом или даже активным пользователем Gradle я не стану - слишко много Groovy  магии :).

Егор Бугаенко про то, что ORM - это обидно. Я познакомился с творчеством этого докладчика через легендарный 105 выпуск подкаста "Разбор полетов" и рекомендую всем и каждому когда будут записи докладов посмотреть, а пока нет - послушать подкаст. Однако атмосферы того, что происходило в зале запись не передаст. До сих пор остается загадкой - то ли это у всех участников конференции настолько крепко прошиты enterprise-шаблоны, то ли докладчик настолько тонко решил постебаться.

Закрывающий keynote от Tim Berglund о том чему разработчики софта могут научится у киноиндустрии. Мысль на самом деле не новая - не помню кто высказал ее первой - Брукс или ДеМарко+Листер. Однако Тим с примерами и картинками провел экскурс в глубину этой мысли.

В общем и целом JPoint удался. Лучшей конференции по  Java в Москве нет.

Конференции: GTAC 2015

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

Итак, что понравилось лично мне.

Uber Challenge of Cross-Application-Cross-Device Testing - очень давно думал над подобного  рода штукой -мультипользовательское тестирование.  Реализацию этой штуковины я себе представлял несколько иначе, чем показали, но тем не менее идея явно имеет право на жизнь.

Effective Testing of a GPS Monitoring Station Receiver - адовый рассказ от Lockheed Martin про то как тестировать  наземную станцию мониторинга GPS.

Chromecast Test Automation и  Chrome OS Test Automation Lab - не могу разорвать эти рассказы друг от друга. Подходы достаточно похожи, вплоть до использования RF Chambers (камеры изолирующие наводки, чтобы герметизировать работу с WiFi-роутером). Очень порадовала инфраструктура конфигурационного тестирования Chromebook - очень круто.

GTAC по прежнему рулит.
В 2016 году он будет рулить в Калифорнии.

Напочитать: К Дню Космонавтики

1. JUnit-QuickCheck и Property-based testing - очередной buzzword или что-то выйдет?
2. EqualsVerifier - для тех, кто хоть раз  налетал с equals в Java
3. tempus-fugit для тестирования многопоточного кода в Java
4. DepAn от Google - инструмент для анализа и манипулирования зависимостями в проекте.
5. Jinq - это типа LINQ для Java.
6. JGiven - очередной BDD инструмент на Java
7. testcontainers - если лень самому стартовать контейнеры для тестов, в том числе Selenium
8. SonarCube+Gradle+Docker - как все это вместе сделать написано здесь.
9. Мистический паттерн Screenplay и как он натягивается на Serenity. Естественно от создателей Serenity.
10. Native Memory Tracker и как docker c java дружит. Или не дружит.
11. Caffeine - модные кэши, Guava style
12. Типа быстрый сканеер classpath - тут
13. Peter Lawrey о библиотеках для High Performance кода
14. Очень странная штука для всяких извратов в тестировании.

Ну и что бы хоть что-то про космонавтику - 10 заповедей NASA для написания кода.

Ну и да - с праздником всех причастных и имсочувствующих.

Напосмотреть: 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 трансформировали сами себя для выпуска мобильных приложений.

Тестирование: Java: Самый быстрый хак

Уже давным давно вышла Java8, но мир намного многограннее, чем думают в Oracle и многим требуется писать код основного проекта на 6 и 7 версиях Java.
А вот писать тесты в таком проекте очень хочется, и хочется лямбд, функциональных интерфейсов и вот этого всего.

Выход есть и вот он:
1. Ставим java8 на ваш сервер CI и локально
2. В pom.xml прописываем вот такую вот конфигурацию плагина для компиляции
2.1 Если вы уже успели вляпяться в богомерзкий gradle, то пробуем так - у меня завелось 3. Улыбаемы и пашем машем!

Напочитать: про тестирование в 7 строчек

1. О попытках  придать ума процессу Fault-Injection Testing в Netflix.

2. О том что такое SecurityManager в Java и как им можно повалить половину приложения. Про повалить не написано, но вы уж сами дофантазируете, да ?

3. Реализация expected exceptions в JUnit никогда не вдохновляла, но вот тут покусились даже на нее.  И чем !!! Лямбдами! Кстати да, JUnit5 (в оригинале JUnit Lambda) уже вышел в aplha-версии и лежит уже в Maven Central

4. Google выпустил EarlGrey для автоматизации тестирования IOS.

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

6. headless-браузер на чистой джаве может быть не только убогим html-unit - есть еще и jBrowserDriver.

7. Ну и в качестве вишенки на тортик - Сергей Мартыненко о стратегии тестирования:
Подготовка стратегии тест-ния под высокориско-ный, высокодох-ный прое from Vlad Orlikov on Vimeo.

Напочитать: 11 друзей менеджера

1. Роман Сергеевич Ивлиев о том, что ничего не происходит.
2. Эффект Даннинга-Крюгера и как оно у нас.
3. Почему скрам-мастер/тимлид/менеджер иногда такой задрот зануда ?
4. Эта статья попала в менеджерский выпуск исключительно по одной причине - когда к вам придет увольняться ваш очередной самый ценный сотрудник ткните его мордой  в ссаный тапок эту статью.
5. Как суки капиталисты-эксплуататоры шведы менеджмент в Вятке поднимали или еще одна история о том как самобытная русская культура лени и раздолбайства разрушена бизнес-процессами большой корпорации.
6. 50 оттенков удаленной работы от Мартина Фаулера. А вот тут еще немножко сублимаций на эту тему от Etsy.
7.  Булочный протокол от CRISP по обработке запросов от клиентов. Не для ленивых и раздолбаев,
8. Интересная тема - о профессиональных наказаниях в ИТ.
9. Очень хорошая подборка от Camille Fournier про менеджмент в стартапах.
10. О мутации программиста в менеджеры с точки зрения DataArt - тут.
11. 43 полезных сервиса для управления проектами.

Software Stories: О прходящих девушках

И вот ты пишешь.
Безвестная девочка Катя/Оля/Настя из города О., выпускница местного университета/института/академии, пед.факультета, социолог или психолог по специальности.
Сухое "привет" или "доброе утро", "мне вас рекомендовали", "открыты ли вы для предложений".
И ссылка. Обязательно ссылка. За которой идет глупое и крайне поверхностное описание вакансии. Иногда там бывают всякие слова типа rockstar или ninja. Но елка остается елкой, несмотря на новогодние игрушки.  Сделать хорошее описание вакансии очень трудно - я сам пробовал, и получилось говно. Но дело даже больше в том, что читая вот это вот ты совершенно не понимаешь куда тебя хотят пригласить. Это место абсолютно стерильно.

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

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

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

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

P.S. Я очень бы хотел процитировать  в этом месте Алену Владимирскую, но к сожалению не нашел тот ее пост в закромах фейсбука. Касался он молодых и бойких девочек, которые выпрашивали у нее телефон покойного Ильи Сегаловича. Суть ситуации примерна та же.

Напочитать: Техноништячки

Много по Java, но есть и общеприменительное 

1. Что делать с Kafka если увидел ее в первый раз в жизни.
2. Принципы Chaos Engineerging от Netflix
3. Testing should only be manual to invalidate assumptions, validating assumptions should be automatic и другие интересные сентенции про DevOps.
4. Из чего сделаны распределенные системы - много, длинно, но все по делу, да.
5. Axon Framework чтобы делать у себя CQRS на коленке.
6. Увэ Фридрихсен о том как мы себя обманываем DRY-принципом и Сэнди Метц про то как мы обманываем себя абстракциями в коде.
7. Как хранить деревья в SQL базах. Не, нуачо, вдруг пригодится.
8. Адовый инструмент по анализу дизассемблированного кода от Google - binnavi.
9. Пользуемся ChronicleMap правильно. Это такая off-heap мапа от high-frequency трейдеров.
10. 21 век, докеры, облака, а раскатываение приложений с помощью deb-пакетов не потеряло своей актуальности. Для java тоже.
11. Красивый, асинхронный retry от Томаша Нуркевича. Нафига оно написано здесь.
11. Ну и на закуску

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

Напосмотреть: Smoking Aces

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

1. Гради Буч о том откуда оно все пошло и куда оно все катится


2. Увэ Фридрихсен про паттерны устойчивости

3. Пэтти МакКорд про то чем же на самом деле стоит заняться HR-ам


4. Стивен Карвер о том что на самом деле было с Шаттлами, но больше про то, как тяжело менять менеджмент. Получил столько удовольствия от этого выступления.

Напочитать: Про тестирование

1. Robot Framework теперь и для Android тоже. Слайды и видео.
2. Практический кейс по автоматизации тестирования от Acronis.
3. Шпаргалка по тестированию мобильных  приложений от коллег из Badoo.
4. The checker framework - проверка кода при компиляции. Нечто подобное делал и я сам.
5. О том как эмулировать медленный диск. На Linux, естественно.
6. Про то что такое бэктестинг и для чего такое тестирование необходимо биржевым роботам. У них в блоге на Хабре еще много про это, например вот)
7. Как взять и сделать непонятные отчеты для Selenium тестов. Зато внутри есть все модное - ElasticSearch+Logstash+Kibana и даже Kafka запихали.
8. 3200 заключенных вышли на свободу раньше срока из-за бага.
9. AugmentedDriver от SalesForce для web, android и ios.
10. Жесть про Python+COM+C++ и автоматизацию тестирования. Это вам не Selenium теребонькать!
11. Опыт Twitter по внедрению Fault-Injection Testing.  Примитивненько, но таки это только начало. И еще на ту же тематику от продавцов рекламы.
12. Максим Захаров про грейды. Все по делу, имхо.