В ленте пролетела рекомендация этого бесплатного курса по фаззинг-тестированию на базе книги "The Fuzzing Book. Tools and Techniques for Generating Software Tests".

Как говорится "не смотрел, но одобряю" (но книга действительно рекомендательная).

#test_automation #testing #tech_read

Architecture Intent Checks try to do this same thing, and they work on the principle that most decisions make perfect sense to anyone with the same context. They’re non-blocking because the default assumption is that it’ll be the right decision (or at least right enough!). When we get it wrong, we learn fast, course-correct, and move on. The cost of occasional mistakes is far lower than the cost of making everyone wait for permission.

Звучит красиво, но, черт возьми, как они определяют цену ошибки и как проверяют на собесах умение людей принимать самостоятельные решения.
Или фишка как раз в том, что решения принимать могут многие, но не все руководители готовы к такому?
А может дело еще и в способности человека уметь разгребать после принятых собой решений. Как это проверять?

Много вопросов, мало ответов. Но сам подход нравится.

Letting Teams Make Occasional Mistakes Costs Less Than Waiting for Permission

ЗЫ Architecture Intent Checks - это что-то типа RFC/ADR, для фиксации принимаемых решений, но их обсуждение не блокирует дальнейшие работы.

#management

The Goal of Compensation is to Create the Most Talented, Enthusiastic Team That Your Budget Allows

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

Ваша цель — не сделать людей счастливыми.

Ваша цель — не удержать свою команду любой ценой (хотя удержание — часть уравнения).

Ваша цель — не получить «выгодную» цену за оплату труда сотрудников.

Ваша цель — не соответствовать рыночным условиям.

Ваша цель — не соответствовать тому, что платит <другая компания>.

Ваша цель — не соответствовать ожиданиям сотрудников.

Ваша цель — не платить одинаково (хотя часть вашей цели — обеспечить справедливость).

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

Звучит все красиво. Недалеко от правды. Но есть нюансы. Самое сложное конечно это баланс "бюджет - талант команды - цели бизнеса".

Там в статье еще есть про то, что ЗП не делает счастливым, но легко делает несчастными, ну и про то, разговоры про ЗП все равно ведутся между людьми и вам нужно уметь объяснять про "справедливость". Ну и про то, что компенсация - это не только ЗП.

Кстати, около года назад уже была заметка про "алгоритмы промоута".

А 10 лет назад был доступен хороший доклад про премирование в IT. Сейчас только слайды остались :(
В премии для инженеров, на самом деле, мало кто умеет, ровно потому что не соблюдаются условия прозрачности и своевременности. Ну и премии за KPI/MBO для менеджеров приводят к тому, что все вместо работы начинают всё тащить к этим буквам. Но это уже совсем другая история... :)

#management

А все уже закончили со своим performace review? А то тут лайфхаки подвезли. И хочу отметить, что они вполне себе годятся, если менеджер не парится с тем, как это все устроено. Можно использовать в этом году, чтобы в следующем быть готовым и во всеоружии.

Про сами ревью писал тутъ и тутъ. И про сопутствующие калибровки тоже.

#management #процессы #развитие

"У меня интересное наблюдение. Мне было очень сложно вырасти в плане менеджмента, когда вокруг меня были классные спецы. Такие колеги всё делали и никаких проблем не было, соответственно никаких кейсов менеджерских тоже не было. Но стоило попасть на пару мидлов, которые очень сложно учатся, как жизнь заиграла новым красками.
Когда ты видишь, как все ухудшается, волей не волей начинаешь искать правильные формулировки, аргументы. Я стал замечать что у меня появились какие-то принципы, четкие требования, более выраженное свое мнение. Стал чаще задавать вопросы "а зачем это делать?", "что это даст проекту?"".

В хорошей слаженной команде, где все работает, как часы, сложно вырастить менеджера из разработчика.
Я бы даже сказал, что в таких условиях рождаются слабые менеджеры.
Сильные люди создают хорошие времена, хорошие времена создают слабых людей, слабые люди создают трудные времена..."

#мысли_вслух от одного из моих бывших крутых технарей, который вступил на менеджерскую тропу.
Жаль, что у меня не получилось дать ему возможность расти в менеджменте рядом со мной. Остается только надеяться, что он запомнил что-то хорошее.
А то надо мной было категорически мало руководителей, у которых можно было учиться чему-то хорошему. Но было много примеров, как делать не надо. И это тоже полезно: если не делать, как не нужно, но при этом что-то делать, сильно больше шансов, сделать как надо, особенно если ты, как и многие, менеджер-самоучка 🙂

#management

Очередная полезняха из ленты.
System Design Space - ресурс для изучения системного дизайна и подготовки к собесам по нему от Александра Поломодова, который часто про сисдиз рассказывает и пишет.

#tech_read #собеседования

Не знаю, поздно уже регаться или нет. Скорее еще можно.
Краем глаза смотрю на слайды первых докладов (потом будут записи) конференции Stratoplan B2B conf: ИТ стратегия на 10 лет. Очень откликается с последним опытом стратегирования (деланием стратегии), да и прошлых опытов тоже.
Кому интересно, отдавайте им свои контакты в качестве оплаты (а так типа бесплатно) и можно потом посмотреть. Имхо полезно.

#не_реклама :)

Prior era’s good leaders are often bad leaders in the following era

"Good engineering management" is a fad
Management skills:
• Execution
• Team
• Ownership
• Alignment
• Taste
• Clarity
• Navigating Ambiguity
• Operating Across Timescales

Это все к вопросу о "плохих или хороших" менеджерах. У каждого есть свои супер-скилы и точки роста в каждом управленческом кейсе.

ЗЫ "всякому овощу своё время" - русская народная мудрость...

#management

Жизнь сложная штука: пока я думаю про что писать, и писать ли вообще, может статься, что и писать будет некуда.

Обычно темы подсовывали инфолента или работа. В инфоленте сейчас сплошной ИИ. А на новой работе есть ощущение, как у того чувака позади фуры в ролике (если он у вас загрузится): и вот думай, есть польза от тебя или нет.
Нужно искать правильную точку приложения усилий.

В общем не теряйте, надеюсь, нам еще будет где пообщаться 🤞
ЗЫ традиционно, в периоды "стопора чистого листа" я рад видеть #ваши_вопросы в личке.

ЗЫ2 кстати, ролику отлично подходит подпись "я и мои достижения в резюме". Видел тут недавно огненный список "достижений".

#байки #мысли_вслух

The most dangerous teams aren’t toxic.They’re polite, busy, and very good at explaining why nothing is anyone’s fault.

(с) Alan Page
чужие #мысли_вслух

Ну, за приоритет Ы

The word “priority” came into the English language in the 1400s, and it was singular, meaning the very first thing, the thing that came before all others. It stayed singular for the next five hundred years.

Only in the 1900s did we pluralise the term and start talking about “priorities.”

...

Think about your own organisation for a moment.

• How many parallel roadmaps and subroadmaps exist, with engineers smeared fractionally across all of them? For example, does your security roadmap fight with your product roadmap and your performance roadmap?

• How many teams have their own backlog of P0 items, with each saying they need more people to work on them?

• How many initiatives are all happening at once, each with their own sponsor claiming that theirs is the most important, leading to silos and politics?

Here’s the rub: the plural form of the word has given us permission to avoid the hard work of truly deciding what comes first.

...

Take ten minutes and try this exercise:

• List everything. Write down every project and initiative currently in flight for your team or department. Don’t filter or categorise yet, just get them all down.

• Force a ranking. Put them in order from one to n. Not tiers, not categories: a single ordered list. No ties allowed.

• Notice the hesitation. Where do you want to create exceptions? Where does it feel impossible to choose? That hesitation is where the real prioritisation work lives.

• Identify who decides. Can you make these choices on your own, or do you need input from your team and peers? If it’s the latter, that conversation is the one you’ve been avoiding.

...

it’s priority, not priorities: you should just have one single list.

One list to rule them all. A simple list can make all of the hard decisions happen.

#management #process

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

Из всего, что мелькает вокруг по этой теме хорошо легли
первые 2 главы от Олега. С аналогиями и параллелями из "обычной" разработкой лучше заходит.

 PS Цитата про тесты - до слез 😹

Хорошие инженеры могут воспринимать тесты, особенно — интеграционные тесты, как особый вид документации. Преимущество тестов перед документами в Word/docx в том, что их можно запустить и мгновенно получить ответ — выполняются требования или нет. По крайней мере, такова мечта. Об этом рассказывают на конференциях, строят умные модели и рисуют пирамидки. По факту, тесты мало у кого есть. Либо они проверяют какую-то ерунду. Докладчики, возвращаясь с позёрских QA-конференций, на работе видят пустоту и разруху.

 #tech_read

Дома мне чуток не хватает офисного шума.
Мои постоянно теперь вертящиеся вокруг собаки не замещают фона, к которому привык за долгое время.
Пробую DevOpsRadio.

Спасибо авторам :)
#байки

Я уже готовлюсь, инструмент закуплен, навык использования имеется.

Не пятничный и может не айти #it_memes

Forget coverage; focus on risk

"...the goal shouldn’t be more tests. It should be less risk. Quality isn’t about measuring lines of code, it’s about understanding where things can go wrong and ensuring we catch critical issues early."

"Risk thinking aligns quality with business impact, not just technical metrics."

"Хорошие тесты лучше, чем много тестов" (Don’t aim for more tests; aim for the right tests) - этот дзен не всем понятен и в целом, в автоматизации тестирования количество не всегда переходит в качество. Это происходит достаточно часто, потому что многие находятся в вечном "достижении количества" в условиях "постоянно уходящего поезда из новых фичей".

Вот вроде все хорошо с этим risk based подходом, за исключением нюанса - никто не мало кто знает, что такое "риск".

Про риски тут в канале уже было бубубу:

Со словом "риски" у меня с недавних пор сложные отношения, но в целом действительно, если отталкиваться от них, действительно можно получать более предсказуемые результаты проекта. Но работать с ними никто не умеет (я таких не встречал)...

В статье есть подсказки:
• Какие риски для бизнеса являются наиболее критическими?
• Какие сбои нам было бы стыдно объяснять руководству?
И следующие за ними:
• Есть ли у нас тесты, которые позволяют снизить эти риски на ранних этапах жизненного цикла разработки?
• Если нет, как мы можем повысить уверенность в этой области?
—
Очень логичным кажется пойти к бизнесу и спросить про эти риски. Но часто ответ будет "нужно, чтобы все работало и лучше вчера, на крайняк - сегодня" и вообще "за качество отвечает разработка".
А если ответ будет не таким, то будет что-то вида "репутационные риски" и "финансовые претензии" от "несоответствия ожиданий заказчика реальности". А, еще, "нужно писать фичи, а то продаж не будет" - вот где настоящий риск.
И мой опыт показывает, что история настолько комплексная и многоаспектная, что в 90% случаев "прилетает" по вопросам/проблемам всем давно известным, но которые намеренно или не намеренно "упустили" в момент заключения сделки, если до нее все же дошло.

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

Продолжение следует.

Пока я думаю и пытаюсь выгрузить это хоть в какой-то понятной форме, расскажите, что у вас обстоят дела с "risk based testing approach". Выходит ли за пределы регламентов и правил? Как определяете что и сколько тестировать или автоматизировать?

  #quality

Продолжение про "рисковое тестирование" будет, мне самому интересно. Но потом :)

А пока новости из инфоленты. Всегда было интересно, исходя из чего ИИ выбирает решения для базовой функциональности, которая нужна почти всегда (базы, файловые хранилища, ORM, CI/CD, аутентификация, тесты и тдтп).
Тут небольшой ответ на этот вопрос (на примере Claude Code).
И чуда не произошло - "не все рекомендации одинаково полезны" и думать все равно нужно. Но некоторые "решения по умолчанию" вполне логичны.
Интересно, можно ли теперь в момент выбора опираться на "используется ИИ по умолчанию"? :)

#tech_read

Продолжаем.
Что нам поможет с рисками? (почему-то вспомнился мем "а чего мы хотим?")
Теория.
ISO 25010 (Systems and software engineering|Systems and software Quality Requirements and Evaluation (SQuaRE)|System and software quality models и ее аналог ГОСТ Р ИСО/МЭК 25010-2015 (в виде pdf).
Этот ISO описывает модель качества продукта через характеристики.
• Functional Suitability (Функциональная пригодность): Полнота, корректность и уместность функций.
• Performance Efficiency (Эффективность производительности): Временные характеристики, использование ресурсов, емкость (потенциальные возможности).
• Compatibility (Совместимость): Совместное использование, интероперабельность.
• Usability (Удобство использования): Понятность, обучаемость, управляемость, защита от ошибок пользователя, эстетика интерфейса.
• Reliability (Надежность): Завершенность, доступность, отказоустойчивость, восстанавливаемость.
• Security (Безопасность): Конфиденциальность, целостность, неподдельность, отслеживаемость, подлинность.
• Maintainability (Поддерживаемость): Модульность, возможность повторного использования, анализируемость, модифицируемость, тестируемость.
• Portability (Переносимость): Адаптируемость, возможность установки, замещаемость.

Это то, что можно использовать, как реперные точки, относительно которых мы пытаемся обсуждать вопросы.

“Просто” берем каждую из характеристик/подхарактеристик, уточняем наше текущее состояние и обсуждаем с бизнесом насколько его ожидания расходятся с нашей суровой реальностью.
Что из этого критично, а чем можно пренебречь на данном этапе и как долго можно “пренебрегать”. Для новой функциональности делаем это на входе.

Чем больше прозрачности - тем проще. Даже если бизнес, в силу разных обстоятельств, не может нам дать конкретики, то понимание того, где мы сейчас находимся, очень полезно нам самим.

Банальный пример: вместо вопроса "а у нас будут заказчики с большими файлами?" (с ответом "конечно будут"), лучше задавать "у нас сейчас грузятся файлы до 10GB, этого достаточно будет в текущих условиях?". (Поверьте, только на собесах по системному дизайну такие вопросы задаются на входе и на такие вопросы всегда есть ответы)

Практические знания (получаем контекст):
- о тестируемом объекте (SUT) в целом
- о том, что мы сделали нового
- о внесенных изменениях и затронутой ими части функциональности
- об основных (самых популярных/ожидаемых/итп) пользовательских сценариях
- о пользовательских данных и том, как они участвуют во всех пунктах выше
- кто и как тестировал внешние для нас компоненты, которые делают другие команды

Дальше обсудим, как это все можно применить на практике.

#quality

Все приемы "перевода" качества в количество основаны на примитивных отношениях (например таком: X=1-A/B, где А - число нереализованных функций; В - число описанных функций). И дальше все это так или иначе "агрегируется". Вообще гляньте этот ГОСТ Р 25023-2021 "Измерения качества системы и программной продукции" - прикольно для фанатов отчетности и тех, кого мучают вопросами "а что у нас с качеством?". Как это применять в реале представить сложно (не сталкивался), но видимо кто-то пользуется. Виталий Шароватов у себя подробнее рассказывает тему с рисками.

Ну а если по старинке, то определяем то, на что больше обращать внимание исходя из контекста и ответов на вопросы из прошлого поста.

Начнем с поставки продукта (фичей) - без этого пользователь не получит ничего.
Если поставляем коробку для on-premise, то значит будет установка - риск по “совместимости”. Если хостим сами (что-то а-ля SaaS) - то вопрос чуть другой.
Какие вопросы задаем (или решаем сами исходя из опыта поддержки):
- какая самая популярная ОС из поддерживаемых (но, помним - проверять, что ставимся на все поддерживаемое, все равно нужно, вопрос лишь в том, как часто).
- или самая “капризная” (исходя из опыта предыдущих тикетов)
- свежая ОС в списке
Им больше всего внимания.

Обновление установки:
- целостность хранимых данных при обновлении - важный вопрос. Тестирование миграций часто идет фоном и происходит “благодаря” тестированию обычных фичей. А именно в этом месте может стрельнуть, особенно если стенды обнуляются при накатывании новых версий. Но данные бывают разными, каких-то и не жалко.
- кастомные настройки (“тюнинг”) -что с ними происходит после обновления? Сброс, изменение дефолта.

Функциональность:
- новые фичи - тут понятно, пользователи в них будут тыкаться, даже если им оно и не нужно. Но опять же, перфекционизм - зло. Не надо вылизывать все до тех пор, пока не будет блестеть. Ибо есть шанс, что оно никому это блестящее уже и не нужно будет, когда решитесь таки выйти.
- “старые” фичи - что задели, как, что у нас с проверками в этих местах? Поэтому для определения скоупа тестирования важно понимать, что меняли. История “доверяй разрабам - но проверяй” конечно имеет место быть, но проверять вообще все каждый раз вы не вывезете. А действовать "на удачу" - не самая удачная стратегия 🫠
- интеграционные сценарии - не забываем про договоренности со смежными командами, кто что проверяет и на какую глубину. Отталкиваемся от сценариев друг друга.
- возвращаясь к совместимости: если реализация независима от специфики ОС, то проверять можно на одной, а не пачке. И в этом месте важно понимать, что у нас зависит от ОС или, скажем, браузер-специфик, чтобы учесть это при составлении плана тестирования. Урезаем количество проверок, рискуем, но осознанно.

Самое забавное - дальше, про все остальные характеристики качества (которые не “функциональность”).
“По умолчанию” считается, что продукт безопасный, надежный, удобный в использовании и поддержке.
А тут на самом деле самые яркие риски и кроются. И чем яснее текущий статус для всех, тем больше шансов на понимание того, что именно требует повышенного внимания.

Много заказчиков из банков - готовьтесь к полным ИБ-проверкам, ограничивающим настройкам сети и фоткам логов вместо самих логов (особенно, если не позаботились об экранировании чувствительных данных там).

Основная аудитория на Android - выбрали ее как основную мобильную платформу? Все равно готовьтесь чинить iOS “ахтунги”, потому что их используют топы.

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

Именно в этом месте важны договоренности и прозрачность: "мы срезаем углы - цена вот такая".

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

#quality

Я всегда говорил: везде есть свой уроборос...

"Tech debt causes slowness. Slowness creates pressure. Pressure creates more tech debt. If your diagram has no loops, you probably haven’t looked hard enough. Chains are comforting because they have endpoints. Loops are uncomfortable because they don’t. That discomfort is the point!"

Ask “what conditions made this likely?” rather than “what caused this?” This shifts the question into something systematic, rather than looking for a silver bullet.

Every system has holes (incomplete tests, ambiguous runbooks, technical debt, etc). Individually, none of them are “the cause".
The incident happens when enough of them line up at the same time.

The Root Cause Fallacy In which framing it as a root cause means you've already lost

#мысли_вслух #процессы

Планирование (включая оценку) того, что нам нужно сделать в релизе, квартале, за год - это Сизифов труд?

The Sisyphean Tragedy of Planning | Stop Trying To PUSH Rocks Up-Hill Like Sisyphus

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

Но бизнес не привык и не будет так работать. И большинство клиентов тоже. Им всем нужно понимать что будет сделано, а не "может быть сделано".

Истина скорее где-то посредине, но все ближе к планам/целям и отмеченным датам.

Иначе - это бесконечная история "а вот тут еще один мега-супер-пупер важный запрос прилетел, а вот еще..."
А вообще в голове сложился тот коммент, что первым там нарисовался.
#процессы