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-тестирования.
Заметки о разработке, тестировании, управлении проектами, людях в ИТ.
31 октября 2016
17 октября 2016
Badoo TechLeads Meetup
В субботу, 15 октября в Москве прошел Badoo TechLeads Meetup.
Я хотел было проанонсировать это событие, но на момент когда начал писать анонс регистрация уже была закрыта, так что он был бы излишним.
Выступить на митапе меня сподвиг Леша Петров за что ему отдельное спасибо - без этой внезапности предложения я бы не решился говорить на эту тему еще довольно долго, хотя хотел давно.
(А говорил я на тему того как мы поднимали автоматизацию тестирования в Одноклассниках с нуля и учили тестировщиков писать автотесты.)
В этом здании находиться московский офис Badoo а на первом этаже в кафе было само мероприятие.
Места хватило всем.
Ребята рассказали о том как они ускоряли релизы в мобильном вэбе. Опыт лично мне был довольно близок, да и проблематика у нас с ними схожая.
"Багфиксинг процесса разработки в iOS: взгляд с двух сторон", Екатерина Николаенко, Катерина Трофименко
Интересный рассказ про модификацию процесса релиза iOS приложений. Очень удивила роль "Багфиксера", но потом вспомнил про целый "Stabilization team" в Facebook :).
Вообще чем больше наблюдаю эпопею развития мобильный приложений, тем чаща на поверхность всплывают вот какие мысли:
1. Мобильные приложеньки - это тот же самый десктоп из 90-х, когда софт писали на болванку/дискеты и он ехал к потребителю, где ставился в совершенно непонятном и незнакомом окружении.
2. Инструментальные средства разработки мобильных приложений конечно эволюционируют, но до иниструментов отладки и диагностикти web-a и server-side имкак до китая раком очень далеко. И ждать чудес не стоит - либо начинать строить инструменты сами, либо пользоваться webview, со всеми вытекающими отсюда.
3. Проблематика расширяющейся матрицы устройств - одинковая у всех, особенно в контексте Android и китайских телефонов. Думается мне что вендоры скоро подрежут открытость платформы.
“Технологии vs коммуникации: что важнее?", Альгис Фатеев
Доклад о неизбежной эволюции процессов в Avito.
Отличные формулировки мыслей - "занимайтесь своими процессами сами, если не хотите чтобы ими занимались аудиторы от акционеров".
Мне кажется многим организациям не хватает как раз той самой сборной аудиторов от акционеров, которая регулярно бы трясла их.
Был еще четвертый доклад, но я его не слушал - по ряду объективных причин.
Поэтому не стоит делать больших конференций про процессы разработки и организационные изменения - не нужно преумножать объем говна во вселенной, поверьте его и так достаточно.
Лучше сделать небольшой митап.
Badoo первые (насколько мне известно) кто ступил на этот путь. Молодцы, чо.
Презентация тут, видео воспоследует.
Я хотел было проанонсировать это событие, но на момент когда начал писать анонс регистрация уже была закрыта, так что он был бы излишним.
Выступить на митапе меня сподвиг Леша Петров за что ему отдельное спасибо - без этой внезапности предложения я бы не решился говорить на эту тему еще довольно долго, хотя хотел давно.
(А говорил я на тему того как мы поднимали автоматизацию тестирования в Одноклассниках с нуля и учили тестировщиков писать автотесты.)
Место
Москва, Цветной бульвар, д.2.В этом здании находиться московский офис Badoo а на первом этаже в кафе было само мероприятие.
Места хватило всем.
Организация
Все хорошо, ничего особенного сказать не могу.Доклады
"Мобильный веб: назад в будущее" Виталий Шароватов,Руслан БайрамкуловРебята рассказали о том как они ускоряли релизы в мобильном вэбе. Опыт лично мне был довольно близок, да и проблематика у нас с ними схожая.
"Багфиксинг процесса разработки в iOS: взгляд с двух сторон", Екатерина Николаенко, Катерина Трофименко
Интересный рассказ про модификацию процесса релиза iOS приложений. Очень удивила роль "Багфиксера", но потом вспомнил про целый "Stabilization team" в Facebook :).
Вообще чем больше наблюдаю эпопею развития мобильный приложений, тем чаща на поверхность всплывают вот какие мысли:
1. Мобильные приложеньки - это тот же самый десктоп из 90-х, когда софт писали на болванку/дискеты и он ехал к потребителю, где ставился в совершенно непонятном и незнакомом окружении.
2. Инструментальные средства разработки мобильных приложений конечно эволюционируют, но до иниструментов отладки и диагностикти web-a и server-side им
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 + интегрционные тесты и все как мы любим.
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 + интегрционные тесты и все как мы любим.
Ярлыки:
antivirus,
cd,
ci,
criu,
docker,
flaky tests,
gpath,
integration testing,
java8,
jenkins,
junit,
linux,
lmax,
log4j,
maven,
mob devices,
powershell,
robot framework,
spectron,
spring
10 июня 2016
Книга: Уильям Детмер. Теория ограничений Голдратта.
Собственно давно я не писал обзоров на книги.
Тому была масса причин: во-первых, пачка книжек купленная у МИФа (Кэрол Дуэк и Осознанность) оказались полным фуфлом, где авторы размазывают одну мысль на 400 страниц, а во-вторых, хотелось хорошего, "тяжелого", чтива, с хардкором, мыслями, так чтобы котелок кипел.
Вот собственно и достал с полки ту книгу, которая стояла в списке на прочтение еще с момента отзыва на нее Макса Дорофеева.
Итак, если вы не читали "Цель" и "Цель-2" Голдратта и/или не знакомы с Теорией Ограничений, то нырять в эту книжку вам не стоит вообще - ни в скафандре, ни без него.
Как я писал ранее, во втором томе "Цели" Голдратт обрисовал практические случаи применения тех или иных инструментов, но не расскзаал методику, видимо оставляя для себя возможность заработать не только на книге, но и на тренингах.
Собственно говоря, книга Детмера закрывает этот пробел, ну или является единственной (возможно только мне) известной попыткой закрыть таковой именно в виде книги, а не поездки на тренинг за огромную кучу денег.
Итак, "мыслительные инструменты" Голдратта по факту состоят из 5 деревьев которые нужно последовательно применять при проведении изменений:
Сквозной пример про внедрение TQM на предприятии - вообще полный ад и трэшугар, только запутывает.
Небольшие примеры иногда в книге оказываются удачными, но редко.
Итого
Читать - стоит.
Голдратту за "мыслительные инструменты" - 4 с минусом - мог бы и сам с нормальными примерами расписать.
Детмеру и российскому изданию - 3 с минусом - только потому, что тренинги стоят сильно много денег.
Тому была масса причин: во-первых, пачка книжек купленная у МИФа (Кэрол Дуэк и Осознанность) оказались полным фуфлом, где авторы размазывают одну мысль на 400 страниц, а во-вторых, хотелось хорошего, "тяжелого", чтива, с хардкором, мыслями, так чтобы котелок кипел.
Вот собственно и достал с полки ту книгу, которая стояла в списке на прочтение еще с момента отзыва на нее Макса Дорофеева.
Итак, если вы не читали "Цель" и "Цель-2" Голдратта и/или не знакомы с Теорией Ограничений, то нырять в эту книжку вам не стоит вообще - ни в скафандре, ни без него.
Как я писал ранее, во втором томе "Цели" Голдратт обрисовал практические случаи применения тех или иных инструментов, но не расскзаал методику, видимо оставляя для себя возможность заработать не только на книге, но и на тренингах.
Собственно говоря, книга Детмера закрывает этот пробел, ну или является единственной (возможно только мне) известной попыткой закрыть таковой именно в виде книги, а не поездки на тренинг за огромную кучу денег.
Итак, "мыслительные инструменты" Голдратта по факту состоят из 5 деревьев которые нужно последовательно применять при проведении изменений:
- Дерево текущей реальности - чтобы понять что менять
- Диаграмма рзарешения конфликтов - чтобы понять конфликт интересов который не позволяет провести изменения
- Дерево будущей реальности - чтобы проверить куда приведут изменения и приведут ли они туда куда нужно, какие еще последствия будут
- Дерево перехода - позволяет ответить на вопрос "что еще нужно для того чтобы все получилось?" и определить с какими препятствиями вы столкнетесь.
- План перехода - пошаговый план проведения изменений, вытекающий из предыдущих 4 пунктов.
Читая книгу, меня не покидало ощущение того, что я все это уже где-то видел и даже делал.
Не, ну на самом деле: дерево текущей реальности - это Root-Cause Analysis как ни крути, диаграмма разрешения конфликтов - это суть есть mind-map, только выстроенный по определенной семантике.
Альтернативных имен оставшихся трех инструментов я не знаю, но с наибольшей долей вероятности многие их использовали, даже сами того не подразумевая - это черчение квадратиков/кружочков и стрелочек на листке бумаге/whiteboard-е/флипчарте с правильной установкой (читай семантикой) в голове.
Собственно наверное рафинированным смыслом книги и является - вложить в голову читателю две вещи:
Книга оснащена массой иллюстраций и примеров - неудачных в большинстве своем, надо сказать.Не, ну на самом деле: дерево текущей реальности - это Root-Cause Analysis как ни крути, диаграмма разрешения конфликтов - это суть есть mind-map, только выстроенный по определенной семантике.
Альтернативных имен оставшихся трех инструментов я не знаю, но с наибольшей долей вероятности многие их использовали, даже сами того не подразумевая - это черчение квадратиков/кружочков и стрелочек на листке бумаге/whiteboard-е/флипчарте с правильной установкой (читай семантикой) в голове.
Собственно наверное рафинированным смыслом книги и является - вложить в голову читателю две вещи:
- Стандартный менеджерский фреймворк "Что менять? На что менять? Как провести изменения
чтобы все не разлетелось к херам ну и результаты тоже было бы неплохо поиметь?" - О чем нужно еще подумать при ответе на каждый вопрос из п.1
Сквозной пример про внедрение TQM на предприятии - вообще полный ад и трэшугар, только запутывает.
Небольшие примеры иногда в книге оказываются удачными, но редко.
Итого
Читать - стоит.
Голдратту за "мыслительные инструменты" - 4 с минусом - мог бы и сам с нормальными примерами расписать.
Детмеру и российскому изданию - 3 с минусом - только потому, что тренинги стоят сильно много денег.
07 июня 2016
Анонс: 17 июня - QA Meetup в Нижнем Новгороде
17 июня в Нижнем Новгороде будет проходить QA Meetup.
Адрес: г. Нижний Новгород, Ковалихинская, д.8, Центр Мировой Торговли, Медиа Страйк Холл (10 этаж)
02 июня 2016
Они учат тестировщиков программировать
Н.М. Светлов, первая лекция по Теории Систем и Системному Анализу.
Вот тут вот я поинтересовался за некоего Бейзера у Леши Лупана, а давеча Леша ответил на мой интерес.
И подумалось мне в свете этих событий за историю как тестирования, так и всей нашей отрасли.
И вот что я думаю про историю тестирования - их у нас три. Одна история - она про то самое тестирование и разработку про которую Бейзер и Боэм.
Так вот, разработка Боэма и тестирование Бейзера - это одна история нашего тестирования, да и вообще всего 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. откопал в просторах интернетов вот такую вот летопись.
И подумалось мне в свете этих событий за историю как тестирования, так и всей нашей отрасли.
И вот что я думаю про историю тестирования - их у нас три. Одна история - она про то самое тестирование и разработку про которую Бейзер и Боэм.
Вы знаете кто такой Бэри Боэм?
А про спиральную модель разработки ПО ?
Это все было задолго до всяких 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, нужно много администрировать БД, нужно писать много технической документации.
И специализация людей для каждого этапа - дело вполне себе логичное и даже эффективное.
Так вот, собственно говоря, причем здесь "Они учат тестировщиков программировать" ??
А вот, на мой взгляд, ситуация из которой выросло тестирование в первом этапе нашей истории - когда мы делаем высокорисковые проекты, с совершенно непонятным результатом, в совершенно неизвестном домене, где все во что ни плюнь - пипец (!!!), инновации!!!! - она структурно идентична той ситуации которая сейчас, на третьем этапе нашей истории, наблюдается на рынке, когда все хотят автоматизацию тестирования, чтобы тестировщики валидировали продуктовые идеи, умели читать логи и мониторить продакшен,да еще и в юзабилити разбирались.
С той лишь разницей, что тогда были системы ПВО/ПРО / межконтинентальные ракеты/ Буран , а теперь AirBNB/ беспилотные автомобили/Amazon Prime, который доставляет покупки дронами.
Это все, кстати, и не про тестировщиков тоже - у погромистов (опечаток тут нет) те же самые попабольки - давайте, вы, погромисты, будете знать как это все разворачивается в продакшене, как и где и из чего сделан CI, построите мониторинги, будете работать с метриками с продакшена, запускать A/B тесты на живых пользователях и при этом не требовать прибавку к зарплате на ношпу и анальгин (виски вам может еще наливать???) за то что это типа не ваша работа.
Термин full-stack developer шагает по сайтам для поиска работы.
Потому что в большинстве случаев сейчас не нужно "хорошо, но только вот это", нужно "нормально, но все", так чтобы взлетело, а там посмотрим что пользователи скажут, подкрутим.
Тестировщиков учат программировать, програамистов тестировать и все это в угоду одному - скорости бизнеса.
Все разговоры и выступления типа Testing is Dead/Testing is not Dead - это все стандартная пропаганда молодой поросли, чтобы побыстрее вытеснить старую плесень ну или нечто сродни рыку молодого льва в саванне, когда старших нет рядом и никто не может дать по башке.
Тестирование не живо, и не мертво.
Оно просто эволюционирует, равно как и вся отрасль.
Не надо делать из этого трагедии, нужно делать выводы и строить планы.
Планы развития.
Планы развития себя.
Совершенствоваться не обязательно. Выживание — дело добровольное. © Эдвард Деминг.
P.S. откопал в просторах интернетов вот такую вот летопись.
16 мая 2016
Конференции: goto; Conference Стокгольм
Периодически просматривая видео с goto Conference появилась мысль посетить лично.
А твиттер подсказал, что в этом году она первый раз проходит в Стокгольме.
Собственно затея удалась, отчет ниже.
По утверждениям аборигенов - это самая большая и самая крутая площадка в городе, там проводят свои мероприятия Oracle и Microsoft.
Вид с балкона на центр Стокгольма с другой стороны пролива конечно отличный, но площадка так себе. Основная проблема, как и в большинстве мест - вентиляция. Мероприятие было рассчитано на 200-300 человек, и если бы был аншлаг, то дышать было бы нечем совсем.
В нагрузку к кофе от кейтеринга ребята поставили еще одну привозную кофеварку с двумя баристами, у которых за два дня так и не удалось попить кофе, обед организован весьма странно, несмотря на избыток места. 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, а также есть выступление на схожую тему.
Остались спикеры да и то не все, и часть участников. Расстраиваться нечему - небольшое количество народа позволило пообщаться с Эдрианом Кокрофтом и Рэнди Шупом за кружкой пива и поеданием бекона. В качестве развлекухи организаторы пригнали какого-то фокусника, но я видел что он залип в какой-то компании которая общалась на тему Docker-контейнеров - у него afterparty точно удалось. Вообще, за доступ к телам докладчиков после первого дня организаторам стоит поставить отдельный плюсик.
Fred George про то что микросервисы ускоряют бизнес - уже не свежее , но все равно слушается приятно.
Tom Wilkie - о проблемах мониторинга,визуализации и трассировки облачных инфраструктур. Все сказанное - оно очень правильное, а вот все показанное никак не внушает веры в то что это можно натянуть более чем на 100 сервисов. А ну и да - хипстерский Go.
Steven Borelli про то как Cisco запилило свой облачный шедулер поверх творчества HashiCorp - этот доклад как нельзя лучше иллюстрирует то количество hype-а и buzz-a вокруг облачных технологий, которое сейчас есть на рынке - все пытаются снять пенку, даже Cisco.
Andrew Phillips про то что не тестированием единым сыт должен быть разработчик, метрики с продакшена тоже смотреть надо. Скрытый product-placement Dynatrace.
Очень спокойно, чистый и свежий воздух за счет того что море рядом (зимой наверное вообще очень свежо), спокойные люди на улицах. Мне повезло с погодой.
Ну и да - цены. Цены в Стокгольме просто конские. Проезд на автобусе от Арланды до Стокгольма - 12 евро (для сравнения в Вене 4-8, автобус - 8), кружка пива - от 6 евро, стрит-фуд - в районе 10.
Если еще раз и поеду на 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, то в другую локацию.
Подписаться на:
Сообщения (Atom)