OWASP Top10:2025 RC1 (6 ноября 2025)
What's changed in the Top 10 for 2025

Напомню, что предыдущий Top 10 составлялся в 2021.

Обратите внимание, что Software Supply Chain Failures и корректная обработка ошибок (Mishandling of Exceptional Conditions) теперь тоже входят в этот список.

Ну и SSRF вошла в состав Broken Access Control, то есть неявно их теперь все же 11 :)

security #tech_read

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

PS для тех кто не в теме: где-то в Мск провели презентацию нового робота со звучным названием idol, он вышел на сцену и упал... "Разработчики объяснили инцидент особенностями ускоренного обучения."

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

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

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

The Testing Techniques We Couldn't Afford (Until Now)

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

PS Я не так часто размышлял над этим вопросом в принципе, потому что все еще скептически ко всем этому отношусь: ибо вижу, как "весело" может поддерживаться код, который был написан тобой не вчера. Но видя, как та же ИИ может помочь "разбирать" старый код, может и не все так страшно?

#testing #ai

Реорганизация
Думаю, что один из самых сложных моментов в работе менеджера.
Много предваряющих вопросов и сомнений, если задумал сам.
Не меньше вопросов, еще более "интересных", если это происходит неожиданно для тебя.
Какие-то реорганизации радуют, продукт развивается, команда растет и это требует изменений в оргструктуре. Например, разделение команды.
Какие-то реорганизации вызваны не логикой, но обстоятельствами.
Недавно на одном из собесов меня спрашивали про мои самые большие ошибки, так вот, сходу, только затягивание реорганизации пришло на ум - опасения последствий побеждают чаще и, соответственно, принятие решения откладывается.
С другой стороны, перед глазами было много примеров, когда проведенная реорганизация не достигает своих целей, кстати, не всегда озвучиваемых публично, а просто сводится к изменению структуры.
Осторожные же движения в эту сторону могут вызывать ощущение тягомотности, когда возможные переживания у людей растягиваются по времени. Иногда может казаться, что один раз “рубанул” и погнали тюнить. Но всегда есть нюансы, в том числе такие:

Лучший способ запустить реархитектуризацию продукта - поменять оргструктуру/подчинение команд, которые его разрабатывают.

Чем все это было навеяно - как обычно, лентой подписок:
5 Strategic Things Every Manager Should Do After a Reorganization
5 Essential Things Every Leader Should Evaluate After a Reorganization

и еще немного про реорганизацию

#процессы #management

Очень давно тут была ссылка на серию статей про подходы к тестированию микросервисов.

Думаю, что этот интересный доклад от автора WireMock, хорошо их дополнит.

● Modern mocking tools used wisely can simulate sufficiently realistic behaviour for most development and testing tasks
● API observability + mock generation + contract testing reduces effort and increases confidence
● Use GenAI with contract testing guardrails for further, safe productivity gains

Слайды будут в комментах.
Видео можно посмотреть только с регистрацией на infoq.com.
Ссылки на демо-проект и страницу-лендинг по докладу

#test_automation #tech_read

🫣 "Простите, часовню тоже я развалил?" (с)

#it_memes вокруг нас

Когда я уходил из МойОфис, естественно была куча вопросов о причинах, в том числе “сам” или…

Сам 🙂 и да, я по-прежнему готов рекомендовать компанию.
Понятно, что публичной конкретики причин вы тут не дождетесь, но можно пообщаться на собесе 😃

Недавно, разбирая долги по “вычитке интернетов”, добрался до статьи The Hidden Reason Great Engineers Quit
И хотя я не “great engineers” (но определенно неплохой менеджер), моя история очень легла в “Because the moment they stop learning… they start leaving.”
Учиться можно всегда и везде. Просто если приходится учиться тому, чему не хочется, то ты тоже “stop learning”.

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

#management

The Hidden Architecture of Engineering

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

You don’t redesign an organization because it’s old. You redesign it because something isn’t working.

The real question isn’t “what structure should we have?” It’s “what problem are we solving, and what design will align our teams to solve it?”

Structure is strategy made visible. A good design aligns incentives, communication patterns, and ownership boundaries with your goals. It creates high-bandwidth communication where you need it and separation where you don’t.

#процессы #management

State of testing 2015 vs 2025 (простите, меня уже чуток тошнит от подготовки к собесам по сисдизу, решил занять голову чем-то другим, просто стало интересно)

Короче: ничего в глобальном смысле не поменялось, какие-то болтания туда-сюда (особенно если сравнивать 2013, 2015, 2023-2025) 😃.
А с учетом того, что это еще и разные люди отвечали, я бы даже сказал разные поколения, то выглядит как "С - стабильность" в отрасли.

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

Да в 2015 были модные фишки в виде Big Data Testing, Testing in Cloud и чуть больше Agile.
Сейчас больше про ИИ (рекомендую глянуть в доку, там интересно посмотреть по ИИ), а Agile поменьше (он скорее всего "трансформировался" и стал просто частью процессов "как все привыкли").

Состав участников опроса по job titles практически без изменений (из самых интересных позиций):
• лиды/менеджеры ~38%
• тестировщики ~35% (если объединить test engineer/tester в итогах 2025)
• автоматизаторы ~7%

Если принять голосовавших за срез отрасли тестирования в 2015 и 2025, то выглядит так, что лидов в отрасли что-то многовато, а количество автоматизаторов не растет (и слава Байту).
Но, в небольших компаниях автоматизаторов больше (2015) - до 12%. Отсюда можно предположить, что если хочешь двигаться в автоматизацию - лучше небольшие (типа 50-100 человек) компании, что в целом схоже с моими мыслями по этому вопросу.

Что касается покрытия автоматизацией, то как будто то на то и выходит: у 55% опрошенных, автоматизацией закрыто < 50% сценариев. И у 20% покрытие в районе 75%+
Кто-то даже декларирует полный отказ ручных проверок: 💪, ну или 🤡, тут уж кому как.

Важность программерских скилов неожиданно снизилась (снова ИИ-шка?), Ops тоже не в фаворе (видимо из-за того, что выросла отдельная ветка DevOps - Test/простите/Ops)

Зато в 2025 резко выросла важность коммуникационных скилов 🤔

В 2015 в вопросах были разные тестовые методики и собственно то, чем занимаются тестировщики, сейчас этого нет, но появились метрики и много про то, куда запихнуть ИИ.

Кстати, недавно обсуждали про TMS и то, что без них "нельзя": в 2015 65% пользовались Excel-ками (+вордом и почтой), как рабочим инструментом. Правда и TMS тоже было достаточно много.

PS но первые отчеты (2013, 2015 мне больше нравились, они больше именно про тестирование что ли).
Сами отчеты будут в комментах. Вдруг кому-то захочется глянуть 🙂

#testing #байки

И снова про структуры, но совсем организационные, а параллельные 🙂
Shadow Structures: The Unofficial Systems

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

И наступает "мы порешали в личке".

#процессы #management

PS надеюсь, те из подписчиков, кто еще не менеджер, хотя бы краем глаза смотрят эти все "менеджерские" заметки/статьи для подпитывания мыслей "а оно мне точно надо?" 🙂

Технические приемы для переписывания бека, чтобы не отломать фичу на проде:
- для API на чтение просто сравниваем то, что отдает старое и новое (Tap compare testing)
- для API на запись дублируем БД и дальше сравниваем состояние БД через API на чтение

Modernizing Reddit's Comment Backend Infrastructure

А что из этого переписывания получилось можно посмотреть на графиках.

#tech_read #testing

Как-то неожиданно долго от меня "прятался" очередной "закон", который на самом деле часто подтверждается в жизни.

Закон Галла

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

Теперь осталось понять, что такое в этом месте, "простая" система и "сложная" 🙂

#it_философия

Летом коллега подарил мне книгу с напутствием "читается тяжело, но дочитай до 200 страницы".
Читалось действительно тяжело.

Но дойдя до этого слова и посмотрев на номер страницы, я понял, почему он мне ее вручил :)

Это было слово "Качество".

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

ЗЫ Паша, прости, я помню, что мы договаривались это все помусолить вместе, но пока не срослось :)

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

Теперь я знаю, как это называется по-умному, феномен Баадера‑Майнхофа.

Ну и один из любимых (не устану этого повторять) авторов из подписок.

Quality is a System
quality isn't something you make - it's something that comes from the system

Там можно каждую строчку в цитаты, и про ответственность с виной, и про героев и тдтп.

PS главное, чтобы хватало сил, желания и времени строить системы до того, как все вокруг снова меняется 🙂
А то на собесах рассказываешь про вот это все: прозрачность, ожидания, доверие, все кивают, а что на самом деле думают неизвестно.
Хотя, нет, было уже "а вы сами верите, что это все работает?".😃

#quality #процессы

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

Скучаю видимо? 🙂

#байки

Достаточно пессимистичная (ну или реалистичная) статья про то, сможет ли использование AI привести к снижению количества проблем при разработке софта и выполнению IT проектов в срок. Сравнивается то, что было 20 лет назад и сейчас.
Особенно забавно, что слово "quality" автор в принципе не использует. Оперирует просто "снижением количества failures" и рисками.

Если попробовать суммаризировать, то основными причинами неуспеха IT-проектов будут нежелание человека учиться на своих и чужих ошибках и, ты-дынц, "ни для кого не секрет, что получить финансирование исправления проблем в разработке программного обеспечения гораздо проще, чем запросить необходимые средства заранее для устранения связанных с этим рисков" .

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

#процессы #оценка

Кстати, про укладывание в сроки и оценку, в том числе проектов 🙂
Почти 10 лет назад я тут собирал в кучку полезняхи про "noestimates" (тут была ссылка ).
Там есть веселые картинки про то, насколько точными являются оценки сроков/бюджетов (по исследованиям 1994-2004).
Судя по вчерашней статье, за эти 20 лет мало что поменялось.

И вот в этом месте интересно, в чем секрет точности угадывания?
#процессы #оценка

Немного цинизма в пятничных #it_memes

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

Внеурочный нерекламы пост :)
Скоро Новый год. Если хочется подарить красивый подарок, сделанный от души, то заходите на странички моей жены. Если что-то понравится, то с промокодом "от Макса" 15% скидка 🙂.
В комментах есть немного фото и ссылок.