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% скидка 🙂.
В комментах есть немного фото и ссылок.

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

Team Autonomy Is a Beautiful Lie — Here’s What’s Really Holding Teams Back

Everyone claims to “trust the teams.” Yet the moment something goes wrong, leaders rush in to approve, correct, or steer. It’s as if the organization is saying: We empower you — but only when it’s safe for us.

И да, снова строится на доверии и прозрачности.

Real autonomy means letting teams make decisions you might not have made yourself — and standing by them as they learn.

If leaders keep rescuing teams from discomfort, autonomy becomes theater. The system feels safe, but no one grows.

There’s a quiet courage in stepping back. In trusting people with real responsibility. In accepting that mistakes are part of progress.

#management

Итак, немного про мои результаты 🔎 поиска работы (7 недель) для интересующихся.
По рекомендациям:
• Известных мне рекомендаций в конкретные компании - 10 (всем огромное спасибо ❤️)
• Созвонов с рекрутером - 5
• Собесов - 4
• Офферов - 3

Мои отклики - 5
• Созвонов с рекрутером - 1
• Собес - 1 (отказ после 1 этапа в пользу другого кандидата)

Интерес рекрутеров - 2 (все мимо моих ожиданий)

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

Итого: качаем кумовство нетворкинг.
Без него сейчас, думаю, никаких шансов даже просто пообщаться по позиции.
Опять же, часть из позиций "оформлялось" уже после появления меня на горизонте.
Вылизывание резюме полезно, но в какой-то момент времени превращается в "переставление кроватей" внутри него. Ну и да, без "циферок" в резюме вообще никак. По резюме было получено "добро" от 3х независимых рекрутеров, но и у них оставались комменты, отличающиеся друг от друга.

Для контекста:
- весной 2022 у меня было всего 3-5 полноценных общения с собесами за 3 месяца. Поэтому, для меня поиск в этот раз прошел проще.
- февраль 2025, поиск только откликами - 3 отклика, 3 собеса, 3 отказа.

Что спрашивают на собесах (спойлер, ничего экзотического и необычного, но всем интересно и куча вопросов в личке):

Общие, традиционно-классические вопросы:
- почему уходите (классно было отвечать на этот вопрос после Semrush, сейчас было сложнее)
- что ищете
- как будете выбирать между предложениями (вначале вопрос казался издевательским, тут бы хоть что-то)

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

Техничка:
- собес по системному дизайну: попалось проектирование месенджера, я его предварительно не смотрел 🫣, нахеровертил я там знатно, но имхо даже завелось бы, если б делать. Я оценил как "не прошел", но проскочило. Помог опыт по техничке Документов Онлайн (особенно CO часть, для тех кто в теме)
- просто вопросы "по верхам", которые все равно надо повторять при подготовке к системному дизайну (тут только то, что спрашивали, вспоминать нужно больше): типы и применимость баз, индексирование, шарды/партиции, база по REST, "вы вбили https://domain.ru в браузере, что дальше", балансировка, кеширование, +/- монолит/микросервисы, мониторинг, основные типы уязвимостей веб-приложений,

Как готовился к техничке 📝
1. "System Design. Подготовка к сложному интервью", Алекс Сюй. Еще рекомендуют "System Design: пережить интервью" (сам не смотрел)
2. "пролистал" кабанчика. Книга действительно не для подготовки к собесам, но пара вещей по БД оттуда пригодились :)
3. Общение с ИИ ботом в Chrome: "способы балансировки трафика", кеширования, "как сделать CDN", "как...то/се". Если в ответах, что-то из мне неизвестного - расширяю поиски в ширину. Получается, что типа ответа на пару страниц
4. Ну и далее список вида:
- балансировка + мониторинг
- кеширование + мониторинг
- БД (выбор, типы, реплика, шарды, патиции) + мониторинг
- мониторинг вообще +observability +SL[IOA]
- ИБ (OWASP + самые популярные проблемы) + для каждого из пунктов списка выше тоже смотрю ИБ-проблемы
- деплойка (канарейка, блю/грин и тп)
- кубер по верхам посмотрел, просто базовую концепцию
- микросервисы (база, +/- подхода, стейт-фул/лесс)
- C4

#вопросы_с_собесов

В целом и раньше больше платили за то, что сидишь и думаешь, а не строчки пишешь. А сейчас похоже это становиться более явным.

The cost of producing code is approaching zero

До изобретения печатного станка Гутенберга книги были дорогими. Переписчики копировали рукописи от руки. Предложение было ограничено, строго контролировалось и оптимизировалось для сохранения, а не для масштабирования.
...
Сегодня код находится там же, где были рукописи в 1450-х годах: дефицитный, медленный и зависящий от экспертов. LLM начинают играть ту же роль, что и печатный станок для текста: снижая издержки на производство артефактов.

...

На что стоит обращать больше внимания:
• Выбор правильной проблемы. В мире, где каждый может что-то построить, самое сложное — понять, что вообще стоит делать?
• Данные, интеграция и распространение. Код прост. А вот его интеграция с реальными данными, рабочими процессами и каналами распространения — нет.
• Доверие и управление. Когда любой может развернуть приложение или агента, узкими местами становятся вопросы происхождения, безопасности и подотчетности.

Наиболее затратные компоненты ПО смещаются вверх по цепочке: выбор задачи, интеграция, эксплуатация, управление рисками и изменения с течением времени.

...

Если вы сегодня занимаетесь разработкой ПО, ваше преимущество смещается от знания фреймворков к знанию предметных областей и пользователей; от реализации функций к выбору тех функций, которые действительно важны; от принципа «действуй быстро и ломай все» к обдуманным действиям и ответственности.

В комментах немного веселых картинок из The State of AI coding

не мои #мысли_вслух #it_философия

Специализированный OWASP Top 10 for Agentic Applications 2026
Немного для тех, кто судорожно пытается хоть как-то придумать, как оценить все новые "AI фичи" на безопасность.

#tech_read

Ох уж эти декабрьские мошенники в пятничных #it_memes

Стремление к предсказуемости

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

Наиболее распространенное решение — больше внимания уделять планированию.

Более подробные дорожные карты. Больше отслеживаемых зависимостей. Часто больше встреч, просто чтобы «подстраховаться».

И почему-то предсказуемость все равно не улучшается.

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

В результате они получают лишь показную игру.

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

Это не так.

Меня раздражают команды, которые делают частые релизы целью, а не результатом работающего процесса.

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

Не «когда это будет сделано», а «на какую дату вы уверены на 50 процентов».

Это число имеет значение.

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

При 90-процентной уверенности команды перепланируют. Они затягивают. Они откладывают обучение во имя безопасности.

При нулевой уверенности команды бросаются в бой вслепую и потом расплачиваются за это.

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

Когда релизы непредсказуемы, руководители часто сосредотачиваются на симптомах. Они просят более четкие даты. Они требуют более ясных обязательств. Они подталкивают команды к тому, чтобы те «взяли на себя» ответственность за выполнение. Они увеличивают количество отчетов.

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

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

#процессы #management

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

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

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

Подводя итоги года.
5-ка лучших самописов по комбинации просмотров/реакций/пересылок.
Всеми любимые #it_memes и посты про поиск работы вне конкурса 🙂.
• Про автоматизацию тестирования (хотя согласен, картинка там мемная, чит)
• Кейс “команда предложила решение, но оно кажется вам неправильным - что будете делать?”
• Про серебрянные пули
• Про документирование принятых технических решений
• Про переработки
Если аннулировать результаты для первого поста за чит-картинку, то в топ попала, чему я рад, история болотной сосны.

Вот прям весь я в 6 постах, прикольно получилось. Не добавить/не отнять.

2025 заканчивается.
Год, а особенно его финиш, был очень насыщенным на эмоции, и на работе, и дома.
Пусть в следующем году у вас все получается, а ваше сердце и разум придадут вам смелости в своих решениях.
Ваш Айтиболит 🎄🎅🏻