18 сентября 2018

День нетестировщика и скидочки на зимний Heisenbug

Давеча тут был День Тестировщика,
 но я был в Праге и был занят, 
поэтому руки дошли только теперь. 
Вспомнилось мне тут как я попал в тестирование. 
При том слово «попал» - оно ключевое. 

Мне позвонил Слава Ванюлин, тогда еще менеджер проекта, а ныне руководитель всея Ауриги, и предложил поучаствовать в проекте.
В этот момент я сидел на "лавке запасных" как часто бывает в компаниях-аутсорсерах, когда один проект, в котором ты участвовал уже закончился, а в следующий тебя еще не пристроили. 
Проект был про встраиваемое ПО и мне было интересно. 
Команду тестирования на проект собирали с нуля хотя проект уже был полгода, нас было 3-е и тест-менеджер. 

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

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

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

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

Дальше началась работа.
Мы втроем херачили автотесты на Jython-е как проклятные - по 20-25 автотестов в день - основной интерфейс у продукта был ssh+консоль. 
Дымовое тестирование со временем превратилось в рутину, документацию и тест-план я, конечно, вылизал - я своей шкурой прочувствовал почему она нужна актуальная. 
Спустя 4 месяца меня забросили разработчиком на другой проект. 

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

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

29 августа 2018

Мысли Мудрого Мавроди , часть 2 - Этика по@#$зма

Второй выпуск в этом формате.


Мной постоянно были недовольны в разных аспектах. Родители. учителя, руководители, женщины. В какой-то момент времени я понял что "недовольные мной" в моей жизни будут всегда. К этому нужно относится как к фону. И делать то, что хочется делать. Недовольные все равно будут. похуй-пляшем Пренебрегаем и вальсируем.

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

Язык и менталитет на самом деле много очень много значат.
Именно поэтому существует десятки клонов LinkedIn-а, CraigsList.
Проблема на самом деле в том что нельзя вот просто так взять и перевести с языка X на язык Y. 
(Ну или можно, но в ограниченном числе случаев).
Есть еще какая-то «национальная составляющая» на которую всем непохуй, которая дает возможность жить проектам клонам.
  
Основой реально работающих процессов в больших организациях в том числе является похуизм. 
Похуизм и бюрократия.
"Пока вы не напишете мне эту бумажку как положено я не буду для вас ничего делать, мне похуй» - примерно так это выглядит.  Это заставляет каждого конкретного шустрика роптать, но в том числе и заставляет крутиться этим колесам для миллионов.

Есть примеры вакансий-могильников.
Выглядит это примерно как "водитель, с опытом вождения болида F1, плюсом будет умение вождения БТР, только  с личным автомобилем». 
Суть в том что внутри компании ввиду того, что Друкера нынче читать не модно, вырос незаменимый человек.
Потом этот человек куда-то ушел - похуй по каким причинам - перегорел, переманили, устал.
И теперь этого бывшего одного человека очень надо заменить. 
Поэтому за голову такого человека предлагают награду, особенно если он добровольно сдастся в руки рекрутера. 
И,да, всем похуй, что таких не существует.


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

Подумалось тут, что предприниматель - это человек с иллюзией максимально-точной картинки его будущего бизнеса. И имея эту картинку в голове он принимает решения, которые ведут его  в сторону этой картинки. 
Есть четкое видение конечного результата, необходимых для этого действий, и есть четкое понимание на что в этой все картине похуй не важно. 
Вот то, на что похуй - это можно купить, арендовать, fake it until you make it, и так далее со всеми остановками.
И еще одно интересное свойство у предпринимателей есть - это свойство искусственно абстрагироваться от того что похуй не представляет для него интерес вот конкретно сейчас. 

Когда ты инженер ты можешь сделать что-то конечное и завершенное, потому что ты создаешь вещи или программы. Ты можешь «закончить».
Менеджер «кончить» не может. Потому что все что он создает - команда.

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

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. Обзор инструментов визуального тестирования