30 ноября 2016

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

Разгребаю скопившееся летом. 
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.


16 ноября 2016

Напочитать: Автоматизация тестирования 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.

31 октября 2016

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

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-тестирования.

17 октября 2016

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 первые (насколько мне известно) кто ступил на этот путь. Молодцы, чо.

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

08 августа 2016

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



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


21 июля 2016

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




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


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

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

Про простоту


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

20 июня 2016

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


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

Место

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


Организация

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

Доклады

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

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

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

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

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

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

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



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

Часть 1


Часть 2



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

16 июня 2016

Напочитать: Автоматизация тестирования: 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 + интегрционные тесты  и все как мы любим.

10 июня 2016

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

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


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

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

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

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

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

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

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

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

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

07 июня 2016

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


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


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

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