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

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

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.