Чудес не бывает или я ошибаюсь?

Наводил порядок в блоге (чистил умершие ссылки, картинки и тп), наткнулся на заметку про 5-летие блога . Интересно было посмотреть на статистику спустя уже 13 лет. Заходов из поисковых систем, других ресурсов и сайтов суммарно больше 160 тыс.  5 лет назад было 54тыс - практически линейно. Как гугл насчитал без малого 800 тыс - скорее всего с ботам и прочими краулерами. Самые популярные статьи (тут уже видимо просмотры с ботами). В лидерах по популярности все те же 2 заметки про моки и ресурсы для тестировщиков (имхо далеко не самые интересные). Mock vs Stub 83тыс  (регулярно в топе выдачи по этому запросу в гугле, продолжительное время висела на 1 месте, не согласен с ее популярностью, но с названием угадал) Полезные ресурсы для молодых (и не только) тестировщиков   61тыс - с апреля этого года снова стала посещаемой, видимо где-то на популярном ресурсе появилась, но по статистике не видно откуда. Смешная история с " План "Б" или как прикольно провести субботний день ...

"Lately I find I'm working on automated tests that return non-binary results. Tests that neither pass nor fail" by  @noahsussman Отличная мысль, которую я ретвитил еще в 2016. Но давайте вместе подумаем, что за этим может скрываться? ( кстати, не знаю, что при этом думал Noah ) Ваши тесты прошли и прошли "успешно". Все хорошо или все же есть, куда еще посмотреть? Дальше то, что использовал я лично и то, что еще можно прикрутить дополнительно. Естественно все шаги ниже должны быть автоматизированны. 1. Контролируйте время выполнения тестов. Если набор проверок не меняется (а такое часто бывает, к сожалению), то рост времени выполнения может говорить о проблемах в продакшен коде (чаще всего) или проблемах с окружением. 2. Контроль за количеством выполняемых тестов. "Все зеленое" не значит, что сегодня выполняли те же Х тестов, что и вчера. Смешно(нет), но случается такое, что какие-то проверки "исчезают" из запуска из-за того, что у кого-то ...

Есть тред в твиттере, но пусть тут для удобства тоже будет. Книги большей частью достаточно "возрастные", у некоторых есть свежие переиздания, где добавлены "свежие" темы, типа мобилок и тп. Из-за "возраста" сравнительно легко ищутся не только в магазинах. Вводная по "разработческому" тестированию Про тестирование обзорно для разработчика Developer Testing The Art of Unit Testing (лучшая, на мой взгляд, книга по юнит-тестам) С примерами на С#   С примерами на JS   Применимо и к другим языкам Паттерны для хороших тестов (практически любых) xUnit Test Patterns: Refactoring Test Code (есть книга) То, что мало кто из тестировщиков читал: Теория тестирования Lessons Learned in Software Testing: A Context-Driven Approach Букварь по тест-дизайну A Practitioner's Guide to Software Test Design Гибрид двух предыдущих Software Testing and Analysis: Process, Principles and Techniques: Process, Principles, and Techniques Еще один гибрид The Art of Softw...

Недавно поучаствовал в Heisenbug Piter 2021 в роли эксперта на очередной серии доклада Андрея Солнцева про flaky тесты. Люблю эту тему. Кажется, это своего рода "дебаг", только для тестов. Иногда расследование похлеще приключений Шерлока. Тема flaky тестов древняя, как сама отрасль. Первое найденное упоминание термина в традиционных интернетах (типа блогов, твиттеров) в 2008 году в блоге гугла . Мне больше нравится называть их “моргающие” или, что четче отражает проблему, случайно успешные. Давайте еще раз зафиксируем то, что поможет меньше попадать в историю, когда тесты у нас "случайно успешные" и что делать, если уже "вляпались". Итак, что делать, чтобы "моргающих" тестов было меньше: тесты должны быть написаны в правильном слое " той самой пирамиды ": чем ближе слой к модульным тестам (а лучше именно в них), тем меньше шансов на моргания, потому что зависимостей меньше. в ту же тему: чем меньше UI-тестов, тем лучше. Открывая в оче...

Черновик с набором ссылочек долго мариновался и вот дождался потребности в себе.  Пусть теперь лежит публично. История началась год назад (твою ж дивизию, вот я торопыга...) с обсуждения в комментах того, что это за роль/должность такая "тимлид". Пересказывать обсуждение тут смысла не вижу, кому интересно - велком в тред. Спустя год тема получила свое продолжение в твиттере Никиты Макарова лайкни оригинальный твит Я думал описать свое видение этой роли, но кому это может быть интересно: жизнь не черно-белая, у всех разные ситуации, забил короче. А вот полезных ресурсов чуток накопилось, поэтому пусть нанесут пользу кому-нибудь. Но какой либо системности просьба не ожидать. Disclamer : если вы только рассматриваете для себя роль лида, технического менеджера и тп, подумайте, оно вам действительно надо, обратно пути может не быть. Ну и опять же, я б учитывал такой забавный момент: лайкни оригинальный твит Ну, если не передумали, то начнем. А начинать я бы рекомендовал с этой кн...

Глянул, что уже есть в программе Heisenbug Piter 2020 : так как я сейчас не в ПК, то интересно, что там у ребят с программой получается. И я вам скажу, что интересно получается :) Во-первых там есть доклад Адама Торнхила , одного из авторов инструмента CodeScene , которого я рекомендовал пригласить. Очень хочется послушать про жизнь кода. Во-вторых в программе Иван Крутов , один из авторов Aerokube. Еще Аня Чернышова про возможное решение проблемы падучих UI-тестов. Что бы я еще посмотрел: Effective unit testing Тестирование производительности клиентской части React/Redux-приложения с использованием Enzyme Demystifying Cross Browser testing  (от бывшего автора Puppeteer) В общем, еще раз вам ссылка на программу , смотрите-думайте. Если созреете и ваша компания-редиска и не оплачивает вам конфу, промокод на персональный билет   shulga2020pc . Еще интересных вам ссылок, местами философских, но про тестирование: Interaction Resiliency (iXR) is the practic...

На самом деле про попытку отказа от менеджеров я узнал раскручивая попавшуюся на глаза историю про проект Oxygen . История на самом деле давняя, берет свое начало аж в 2002 году . Лари Пейдж и Сергей Брин решили, что менеджеры только мешают быстрой разработке, и решили их попробовать без них. Эксперимент закончился через несколько месяцев: число страждущих порешать проблемы напрямую через Пейджа (а другого способа не было) превысило его пропускную способность :) В итоге менеджеров вернули, потому что они все-таки приносили пользу: помощь в приоритезации проектов, фасилитации взаимодействия, поддержка в карьере сотрудников и направление процессов и систем в соответствии с целями компании. Но вопрос в том, как понять, какой менеджер полезен, а какой так себе. В 2009 (по другим источникам в 2008) Google запустил проект Oxygen, целью которого стал ответ на вопросы "Зачем нужны менеджеры и какие". Вылилось это в исследование с анализом работы более 10000 менеджеров по 100 п...

Сходил в гости к Константину в его подкаст " SDCast ". Вроде интересная получилась беседа , душевная. Чуть меньше 1.5ч возможностей узнать чуть больше про меня, SEMrush и моем отношении к процессу разработки с точки зрения качества. Ссылки для послушать: Основная  https://sdcast.ksdaemon.ru/2019/07/sdcast-106/  и резервная  VK  https://vk.com/ksdaemon?w=wall6753715_549 FB  https://www.facebook.com/ksdaemon/posts/2462401727171916

1.    Sharing Our Engineering Ladder "Creating an engineering ladder (that is, the job descriptions and levels of an engineering organization) is a daunting task. If you do a half-hearted job, you're likely to cause more problems than you solve." "In addition to the ladder causing problems inside of my team, we were having a hard time evaluating candidates during interviews and determining what level to hire them into. Particularly at the more senior levels, it wasn't clear what the criteria for success really looked like. So, together with my tech leads and engineering managers, we rewrote the ladder to be more specific. It has been very helpful both for the process of reviews and promotion committees as well as for the process of hiring." Я уверен, приведенные в ссылках характеристики коими должен обладать разработчик и менеджер на разных позициях в своей карьере, будут полезными многим. 2.   If Your Boss Could Do Your Job, You’re More Likely to ...

Давно ничего не писал себе и вам в полезные заметки. А их накопилось. Продолжим цикл, хотя он теперь и не "5 за 5 (дней)". 1.  Статья из 1995 . Сколько времени прошло, а ничего не меняется. Но именно такие мысли я называю классикой и философией промышленной программной разработки: "Задачи условно делятся на три категории — соответственно квалификации. Низшая — ты можешь запрограммировать предложенный кем-то алгоритм. Средняя — по предложенной спецификации функции или программы ты можешь предложить алгоритм ее реализации и запрограммировать его. Высшая — ты можешь предложить способ решения задачи, написать спецификацию программы, ее решающей, и запрограммировать ее." Нет моей самой любимой квалификации: Высочайшая - ты умеешь решить задачу, не написав при этом код. А если еще удается и удалить часть кода - это еще лучше. 2. " Chaos Engineering: the history, principles, and practice " - отличное введение в тему от компании, которая занимается ...

Тема модная, имхо отпочковалась от DevOps, а скорее стало ее развитием (хотя считается, что развивались темы параллельно и одновременно). Зародилась в Google, во многом построена на основе текущей структуры разработки Google, поэтому применение в других организациях сталкивается со сложностями . По теме 3 основные книги (в порядке даты издания): Free to read online или купить  Site Reliability Engineering. How Google Runs Production Systems  (апрель 2016) Free to read online или  The Site Reliability Workbook. Practical Ways to Implement SRE (июль 2018) Seeking SRE. Conversations About Running Production Systems at Scale (сентябрь 2018). Мой небольшой тредик по этой книге В первой книге про концепцию и базовые вещи. Вторая про внедрение на примерах. Третья похожа на вторую, но в виде примеров (в тч best practices) из разных компаний. Обзоры первой книги: Commentary on Site Reliability Engineering Review: Site Reliability Engineering Google SRE book ...

Решил собрать в одном месте все нравящиеся мне термины из психологии, которые касаются работы, мотивации, отношения к своему труду и к себе. Задача не стояла в объяснении каждого термина, а просто в том, чтобы все было собрано в одном месте. Если вы знаете, еще какие-нибудь интересные штуки, пишете в комментариях. Эффект Даннинга — Крюгера Определение в вики слишком затянутое. Я его понимаю так:  глупые не понимают, что они глупые, потому что они глупые. Но при этом уверены, что они круты. А умные "знают, что ничего не знают" и думают, что все остальные о них того же мнения.

сперто(с) Уже 3 месяца провожу собеседования тестировщиков (март 2016). Поначалу они просто  веселили - после 15-летнего опыта собеседования С++-разработчиков, общение с тестировщиками (чаще были "-цы") было чем-то экзотическим и забавным. Потом становилось все грустнее и грустнее, мимими закончилось. Началась печаль.

Доклад Бори Вольфсона "Эффективные ретроспективы" ( видео , слайды ) Цикл статей Никиты Макарова " Ретроспективы в командах " Презентация Макса Дорофеева " Правила хорошей ретроспективы или ключ к непрерывным улучшениям " Хорошая статья про оценку ретроспектив Александра Селяева

Выступил на BitByte 2014. Ставлю себе троечку. Скомкано получилось. На паре слайдов забыл рассказать запланированое, в итоге - не факт, что получилось донести идею. Надо лучше готовится :)

Немного полезных ссылок про unit-тестирование C++

Соответствие студии стандарту  C++11 Features  в Visual Studio 2012 (там еще нет ноябрьского свежака ) Welcome back to C++  (Visual Studio 2012)

Disclaimer: Началось все "с чего начать", потом превратилось в копилку полезных ссылок по автоматизации. С чего начать?  Полезные советы

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