28 апреля 2018

Про Heisenbug и скидочки на него

КДПВ

Решил тут чот порефлексировать на тему Гейзенбага.

Первый раз мы заговорили о конференции про тестирование с Лешей Федоровым летом 2014 года на кухне московского офиса Одноклассников.
А летом 2016 года Леша позвонил и сказал примерно следующее: "Мы тут решили попробовать сделать конференцию про тестирование. Нам нужно хотя бы три человека в программный коммитет ? Ты как, в деле ?"

Я сказал да, и вот на горизонте уже 4 (четвертый, блин!) Гейзенбаг.

Каждый Гейзенбаг отличается от предыдущего. Очень сильно.

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

На самом деле это адовый труд раз в полгода выводить на сцену качественный контент в определенной тематике. Причин тому несколько.
1. Его столько нет. Ну реально, даже у разработчиков нет полностью свежей программной сетки из новых тем и докладов раз в полгода. (Мой коллега, Олег Анастасьев, говорит что только раз в два года на конференциях появляется что-то новое и стоящее внимания.) Исключением, пожалуй, может являться только JavaScript и мир фронтенда :).

2.  Спикеры. Не каждый хочет рассказывать, не каждый кто хочет - может, и уж точно не каждый, кто хочет и может - в силах довести это до конца. Нас (я имею ввиду ПК) часто критикуют за высокие требования к подготовке доклада. Мы к этой критике вдумчиво прислушиваемся. И, действительно, для того чтобы сделать хорошее выступление нужно обладать внутренней мотивацией.

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

Чем еще примечателен грядущий Гейзенбаг ?
Тематикой докладов.
Тестирование меняется и очень хочется рассказать устами спикеров об этом всем.
В этот раз у нас будет два доклада про краудсорсинг и его применение в тестировании (от Оли Мегорской из Яндекса и Насти Семенюк из ВКонтакте), доклад про Model-Based Testing на основе сетей Петри, и про тестирование компиляторов (для любителей хардкора :)). Это конечно не все достойные доклады, это мой личный шорт-лист :).

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

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

Ладно, я тут еще долго могу графоманить.
Всем кто хочет поучаствовать в качестве слушателя и дочитал до этого места - промокод со скидкой PapaMinosPromo.

P.S. А те, кто не будет тормозить могут поиметь с этого промо-кода несколько больше потому что с 1 мая цена поднимется.





17 апреля 2018

Мысли Мудрого Мавроди - МММ


Накипело тут всяких  мыслей, попробую новый формат.


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


Мы не Гугл. Не нужно изобретать свой велосипед, давайте возьмем что-то с рынка, что поддерживаем не мы, внедрим у себя и будем заниматься действительно важными вопросами.
Классная модель мышления, иногда даже работает.
Вам не нужно оперировать в масштабах гугла для того, чтобы столкнутся с проблемами, присущими Гуглу.
Вам нужно лишь НЕ ОБЛАДАТЬ достаточным количеством ресурсов для решения той или иной проблемы и voi-la - вы уже находитесь в положении Гугла, когда нужно креативить чтобы решить проблему.



Каждый построенный велосипед является памятником нахождения локального оптимума, в определенный отрезок времени, исходя из условий среды и требований на этом отрезке.
При изменении условий и требований, каждый неуничтоженный велосипед является памятником невозвратных затрат (sunk cost fallacy).


Увольнение/уход человека - это «землятресение» компаний. 
Невооруженным глазом их можно наблюдать,  когда кто-то уходит/кого-то уходят и люди начинают двигаться вверх, при том не один, а сразу цепочкой.
Для того чтобы видеть «землятрясения» и их последствия необходимо сидеть достаточно высоко и обладать достаточной временной перспективой наблюдений. 
Аналогия с землетрясениями хороша еще и тем что как и в природе предсказывать их пока не научились, и в любой конкретный момент времени конкретно непонятно  - оно будет одно или серия толчков ? 
Смотришь вот так вот со стороны за серией «толчков» - один поскандалил и ушел, второй перевелся в другой отдел/проект, третий просто ушел - и видишь как после  этого начинает буксовать проект или какой-то его кусок. 
Знание о форме тектонических плит, местах  их столкновений и хороший сейсмограф конечно могут позволить верхнему менеджменту снизить потери от землетрясения, но не сделать их нулевыми. В лучшем случае времени и ресурсов хватит на эвакуацию, хотя и это не мало. 


В жизни каждой организации неизбежно наступает период когда менеджеры в ней  превращаются в стратегов.
Менеджер становится стратегом не сразу, не в один день. 
Менеджер делает какое-то дело, его люди делают это дело. 
Дело даже получается, так может повторится даже несколько раз. 
Люди у менеджера учатся, проявляют инициативу.
И в какой-то момент менеджер понимает, что ему больше не нужно делать менеджерскую рутину.  Что он может подумать о ней… о стратегии.
Стратегия, сука, непонятная.
Она вроде бы и есть, а вроде бы и нет. Вот с тактикой все просто - взял кусок работы, нарезал на спринты, ходишь на стендапы, решаешь проблемы команды, получаешь результаты и обратную связь. 
А со стратегией все сложно - ты ее подумал, обсудил, проговорил с людьми. Может быть даже записал на бумажку и придал ей официальный статус.
Но ее нет. Физически ее нет. 
Поэтому стратегу нужно, конечно, подумать эту вот самую стратегию, обсудить ее, проговорить ее и ... идти выполнять. Самому.
И тут собственно и наступает тот самый критичный для менеджера момент - кто-то может ответрнуться (пусть и на время) от этой бездны стратегии, и пойти обратно в окопы, а кого-то засасывает эта метафизическая бездна. 
Это конечно идеализированная картина мира, где только черное и белое, но (!!!)- конченых стратегов нужно отстреливать! 



Для того чтобы произвести организационные изменения одна из частей организации должна получить дополнительную степень свободы или новая отдельная часть организации должна получить эту степень свободы и стягивать деятельность организации к кому-то новому локальному оптимуму. 
Тут есть один нюанс - внутри организации появляется другая организация. Это отдельный пиздец и тема отдельного разговора. 


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


Самыми большими организациями за всю историю человечества всегда были армии.
Ни государство, ни церковь, ни какая бы то ни было другая организация не может оперировать также, как армия. 
Вдумайтесь - по получению соответствующего сигнала откуда-то из штаба целая воинская часть (а это как бы тысячи человек) должна упаковаться, погрузится в технику, собрать все необходимые манатки типа еды, боеприпасов, горючего, встать на марш и двинуться в нужную сторону. Для бронетанковых частей в СССР норматив был 45 минут.
А теперь контрольный вопрос - вы эвакуацию обычного офисного здания по учебной пожарной тревоге когда-нибудь видели ?  Хорошо если за 45 минут все оккупированные клозеты освободятся. 
Если вы хотите что-то улучшить в своей организации - поищите схожий армейский опыт.
Да,опыт этот специфичен, но - его много, есть вариативность кейсов, проверка временем. 


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



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



Есть моменты соприкосновения/столкновения умов. 
Они нужны любой организации, которая что-то делает умами людей.
Каждый такой момент состоит из нескольких компонентов. 
Первый - это состав. Он не случаен, он всегда строго ограничен, всегда присутствуют неслучайные люди, иногда (!!!! ИНОГДА !!!!) к ним можно кого-то добавить. Нельзя просто взять и вставить в этот процесс «чужого» человека. 

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

Третий - место. Это опять же про курилку, любимую переговорку, место в кафе.  Это место где никто не мешает, где безопасно, где нет сторонних факторов отвлечений. 

Владельцы компаний часто фрустрируют на тему того, что "вот раньше когда мы были стартапом на 5 человек, мы в курилке обсудили на троих и за вечер под пивко запилили, а теперь такого в организации нет».  И владельцы часто пытаются вернуть это через  «тимбилдинги» , «хакатоны», «тренинги» и прочие разновидности плясок с бубнами вокруг. Это все конечно не работает. 
Не нужно пытаться вернуть то, что вернуть нельзя. Это нужно воссоздать во множестве таких же мелких масштабов, чтобы внутри вашей организации эти столкновения происходили на местах. 
  

11 апреля 2018

Книга: Роберт Саттон : Не работайте с мудаками.

Собственно читал довольно долго.
Тема не раскрыта.
Почему книга удостоилась столь лестных отзывов - я не знаю, но! Но если действительно все что написано в книге кажется широким массам столь полезными и неочевидными практиками, то мы все в настолько глубокой жопе, что аж прям ой.
Оценка 2/10


22 марта 2018

Напочитать: Отпетое менеджерьё




1. Про то как менеджеру общатся и про то как общаться с менеджером
2. В зависимости от стадии жизненного цикла компании ей нужно нанимать соответствующих людей. В деталях на видео ниже



3. Как правильно душить в себе технаря когда стал манагером.



4. Ну и самая мякотка самой писечки - рассказ Александра Горника про то как они трансформировали Mindbox в бирюзовую сторону и что же это на самом деле.



Любите своих менеджеров. И они будут любить вас.


14 марта 2018

Напосмотреть: Тестовая труба шатать





1. Роман Дворнов о том как сделать screenshot-based тестирование со скоростью unit-тестов



2. Об использовании OpenSTF в реальных проектах (со ссылками на свои плагины)


3. О том почему 100%  покрытие кода плохо


4. О том как шатают трубу занимаются fault-injection testing на Московской фондовой бирже.



5.  Adam Tornhill  в очередной раз про то что можно нарыть из кодовой базы (еще у него и блог оказывается есть )



6. Ребята из Яндекса продолжают ваять свои инструменты тестирования

Гермиона


Автотестер

12 марта 2018

Напосмотреть: Архитектурно-протитипный выпуск

1. Про Тьюринг-полноту Power Point




2. О том как дешево запрототипировать систему используя Google



3. Мой (уже бывший) коллега Гриша Джанелидзе о том как мы запускаем эксперименты вообще и делаем это на мобильных приложениях в частности.



4. Пусть и старый, но совершенно замечательный keynote c Geekout от Тэда Ньюарда про то что же на самом деле подразумевается под профессией архитектора


30 ноября 2017

Напочитать:ТСТРВЩК УПРЛСЯ



1. Chrome теперь умеет быть headless, умеет параллелить Remote Debugging сессии, команда хрома выпустила Puppeteer. Firefox просто научился быть headless.
2. Test Impact Analysis - просто офигенная статья от Paul Hammant в блоге Мартина Фаулера.
3. Более менее внятно про  Pact и Consumer-Driven Contracts c примерами на  github.
4. Скалирование Selenium-тестов на Amazon Lambda - новый уровень упоротости!
5. Для тех кому нечем будет заняться долгими новогодними вечерами - видеозаписи симпозиума Facebook про тестирование и формальную верификацию систем.  
6. Тем же кому хочется тем более приземленных - записи с закрытой конференции @Scale про Developer Tools и очень много про тестирование и темы смежные с ним. 


P.S. тем кому этих шести пунктов не хватило чтобы упороцца предлагается пройти видеокурс по TLA+

31 октября 2017

Напосмотреть: Тестирование: Пред-Heisenbug-овый

Часть докладов пересекается  с темами которые будут на Гейзенбаге.
А часть - нет, но спойлерить ту часть которая будет на Гейзенбаге я не буду. 

1. Ребята из 2GIS о том сколько геморроя можно поиметь при построении инфраструктуры автоматизации тестирования для Adnroid  приложений



2. О том что можно получать СМС-ки для регистрации  аккаунтов на номера Twillio и как заставить Google анализировать его же собственные голосовые сообщения.



3. Про Test Containers от их же создателя

TestContainers – Richard North from Official ZeroTurnaround Account on Vimeo.

4. Даже такое серьезное издание как Guardian не ссыт тестировать в продакшене, а ты ?



5. Обзор инструментов визуального тестирования



26 октября 2017

Напочитать: так тестируют только @#$%исты!

Про то, как тестируют программисты

1. JCunit для комбинаторики и тестирования на основе моделей.
2. Какие типы моков бывают - с примерами для Mockito.
3. Как можно (нужно ли?) комплексно протестировать Spring Boot приложение - подробно и детально тут.
4. Как Facebook ищет баги с помощью генетических  алгоритмов и как к этому прикрутить crowdsourcing.
5. Infer от Facebook живет и они даже про него рассказывают: видео , статья . (maven-плагин для интеграции)
6. как тестируется язык Rust - очень интересно.
7. Как программисты GitHub устраивали back-to-back  тестирование в продакшене.
8. Infer (ныне фейсбуковский) учится находить race conditions.
9. Как протестировать отправку почты с простейшим SMTP сервером и модными TestContainers Arquillian Cube.

26 сентября 2017

Напочитать: JUnit 5


Собственно 10 сентября, после 2-х лет разработки в свет вышел JUnit 5 он же JUnit Lambda.
Если для вас это ничего не значит и Вы не понимаете почему это событие вон из моего дома можете дальше не читать.
А тем, кто остается собственно воть:

1. Выступление Марка Филлипа о том как переехать с JUnit 4 на 5.



Кстати Марку видимо понравилось и он приедет с продолжением темы на Joker.

2. Большая статья  на Хабре про фичи и фишки.
3. Tutorial от Petri Kainulainen по JUnit 5 - тут
4. Параметризация тестов  на JUnit 5  c примерами и картинками - тут.
5. Большая презентация в качестве шпаргалки.
6. Параметризация из JSON
7. Расширение для удобной работы с WireMock
8. Альтернативный движок для тестов - jqwik
9. Слегка уродливое расширение для Selenium на JUnit5.
10. JFairy  для рандомизации тестовых данных.
11. Комплексный пример с JUnit5 и Selenium для проекта на VaadinПояснительная текстовочка на немецком.
12. Тестировать интеграцию с базами тоже можно - Rider.
13. Тестировать логи (логи, епта!) тоже можно. Пример тут для JUnit 4 и 5.
14.  Тестирование самих расширений JUnit5, Guice, интеграция с Mockito - все тут.
15. Перехват out и err потоков через  расширение - тут.
16. Набор extension-ов от разработчков  JUnit5 - JUnit Pioneer.
17. Extension для Vert.X  под JUnit5 - детали тут.
18. Программная регистрация расширений - детали в официальной доке.
19. Поддержка Vert.X для JUnit5 - тут
20. Расширения для RestAssured - тут
21. Расширение для Jersey - тут
Мигрируйте!