Интересный вопрос (часто возникает в той или иной формулировке):
"Качество ПО - это ответственность команды". Но почему-то разработчики не хотят тестировать продукт (когда надо)? И писать автотесты (когда надо)?

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

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

Что происходит в реальной жизни?
Разработчиков не учат тестированию. Более того, популярно мнение, что это вредно. Я однажды уже комментировал это . (Уже стесняюсь писать про то, сколько лет назад это было, но мало что менялось с тех пор).

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

Можно долго мусолить тему "разрабов в тестировании", но реальность такова, что только руководитель разрабов определяет, участвуют они в тестировании или нет, а если участвуют, то как именно.
Поэтому если вы, как тестировщик, имеете вопрос "почему разрабы не тестируют", то задайте его их руководителю. Что делать, если этот вопрос возникает у руководителя, мы обсудим позже, хотя кажется, что ответ очевиден.
#testing #holywar

Софт-скилы под давлением временем только твердеют и замещают собой старые хард-скилы, которые превращаются в песок - путь менеджера
#мысли_вслух

Мне очень нравятся DORA метрики. Это хороший инструмент для оценки качества DevOps-процессов. И хотя изначально (в лоб) он больше подходит для тех проектов, которые можно обозначить, как "self-coded + self-hosted", все метрики можно замапить на любые типы проектов и типы релизов. Вот пример того, как это можно сделать для мобилок.
PS грустный факт: я нечасто участвовал в собеседованиях DevOps-ов, но за все время не могу вспомнить, чтобы кто-то из них знал эти 4 буквы DORA.
#metrics

"...давать ошибаться..."
Кстати, про ошибки.
Все делают ошибки. Ошибка - это нормально, это в целом даже ожидаемо. Ненормально ничего не делать после того, как ошибка произошла, считая что "ошибка - это нормально".
И под “делать” я тут понимаю не “кару небесную”, а нормальную работу над ошибками: понять причину, неочевидные следствия и шаги по их устранению, а также нужные исправления для того, чтобы уменьшить шанс на повторение ошибки и/или снизить ее цену.
#мысли_вслух

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

А если мы говорим о менти, который хочет получить совет, то лучшее по этой теме было тут "Instead of looking for a mentor, just find somebody who can answer some questions you have. Then, if you think they can answer some more, ask them again. In reality, a mentor is mostly just somebody that answers questions more than once."

Ну а я постоянно следую этому совету
"If you want a mentee - get good at something and make yourself available to answer questions about it"

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

#развитие

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

Как я для себя формулирую ожидания от Team Lead / Tech Lead:

Team Lead:
• фокусировать
• вдохновлять
• растить
• коммуницировать
• воспитывать
• поддерживать
• оценивать производительность команды
• выявлять внутренние проблемы в команде на ранних стадиях
• решать конфликтные ситуации
• контролировать внутренние процессы разработки
• организация ретроспективы

+ добавляется то, что обычно делает или Tech lead, или эти активности размазываются по другим людям в команде:
• разработка (программирование или тестирование)
• соблюдение регламентов
• декомпозиция задач
• code review
• техническое воспитание новичков
• принятие решений в рамках тех технологических решений и стандартов, что есть в компании
• участие в архитектурной(-ых) группе(-ах)
• контролировать технический долг
• участвовать в отборе кандидатов, включая собеседование
• изучение индустрии

Можно ли это все совмещать? Наверное, с определенной долей успеха, можно. Более того, какие-то задачи тимлида проще делать будучи еще и техлидом. Зависит от размера команды, ее состава, типовых задач и процесса их поступления.

Чем Team Lead в этом случае отличается от Engineering Manager?
Распоряжением бюджета (планирование/расход).

Чем Team Lead отличается от Scrum Master (правда ведь весьма похоже по ожиданиям?). У SM фокус на скраме, поддержанием его культуры, ценностей и тп. Но, если коротко, далеко не везде у нас есть скрам, уволить сотрудника скрам-мастер не может (хотя тимлид тоже не всегда 😉) и за работу команды в итоге отвечает Team Lead.

Вообще вопрос не нов. И у меня тоже есть немного букв про эту таинственную роль с полезными ссылками по теме внутри.
#процессы #management

Один из самых неожиданных вопросов, который пришлось услышать на проходивших у меня в прошлом году собесах: "как вы будете мотивировать людей, которые не хотят работать? Они приходят только деньги получать".
Но самое грустное, что это не тренировочный кейс, это то, с чем пришлось бы столкнуться (по словам собеседующих), “потому что, давайте будем честными, хотя вы и можете обеспечить вовлеченность сотрудников, вы не можете замотивировать их. Это происходит изнутри.” (Do Managers Really Have Power Over Employee Motivation?)
А в целом, не демотивируйте, чтобы потом не мотивировать - это самое простое обычно. Это то, с чего стоит начать. Частично, то что может демотировать, мы уже обсуждали.

#байки #management

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

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

#management #процессы #собеседования

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

Тема оценки предстоящих работ постоянно в топе инфоленты, потому что все стараются, но мало кто попадает: потому что это сложно или долго.
Estimation Isn’t for Everyone одна из свежих статей на эту тему. Забавно, что там 1:1 повторяются мои мысли про усреднение оценки на периоде времени, что дает возможность перейти просто к количеству выполняемых задач для измерения скорости команды.
А время по оценке каждой задачи в отдельности правильнее тратить на то, чтобы понять, что именно нужно сделать и эксперименты. Поэтому что именно это уменьшает неопределенность и снижает риски.

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

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

Давайте сегодня сдуем пыль со старой статьи-перевода (я начинал вести свой блог делая переводы интересных статей, добавляя свои мысли по ходу).
Кто такой хороший тестировщик?
Статья была какое-то время очень популярна (по статистике). Что изменилось с тех пор? Имхо - ничего. Классика.
ЗЫ Только ссылку на оригинал пришлось поправить, потому что старая умерла.
#testing #классика #развитие

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

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

Итак, как обучать руководителей? Хмм, да кажется проще, чем инженеров, потому что нужно научить тому, что, по идее, уже знаешь и делаешь сам. А если не знаешь - научиться вместе 🙂

Регулярные задачи и активности у подчиненного руководителя сильно пересекаются с твоими текущими или ты ими занимался недавно.
Проведение собесов/отбор, 1:1, формирование команд, планирование и работа с рисками, бюджетирование (😭).
Ты же сам все это уже умеешь? Делись опытом, спрашивай, слушай (больше, чем говоришь сам), направляй в нужную тебе сторону, поддерживай правильные действия.
Если есть сомнения в своих педагогических навыках, организуй обучение на специализированных курсах, посещение конференций. Только важно потом обсуждать увиденное/услышанное/изученное.

Самое сложное, пожалуй, это оценить, как это все применяется твоим сотрудником на практике.
Но это уже тема отдельного разговора.

#ваши_вопросы #management

Традиционный пятничный мем.
Картинка 10+ летней давности. Тогда прямо в тему. Сейчас, хочется уже верить, не совсем. Но все равно, улыбает.
PS или все так же? 🫠
#it_memes #тестирование

Закон Зимургия на разработческий лад: если вы написали говнокод, то вы не сможете его протестировать не написав еще говнокода.
#мысли_вслух (в этот раз не мои)

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

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

PS как-нибудь напишу про пирамиды тестирования и то, что про них думаю.
#testing #мысли_вслух

"Какой бы совет №1 вы дали менеджеру-новичку?"
Как я ответил на этот вопрос: "Будь готов к тому, что теперь твоя работа - это делать работу мозгами и руками других людей без наблюдения ощутимого результата своего труда в моменте здесь и сейчас".
А дальше, как в статье, тренируй чуйку и оттачивай менеджерский инструмент на оселке своего опыта.

#management

Очень интересно сейчас выглядит продуктовая разработка в какой-то части отечественных продуктовых компаний: нужно сделать продукт, который повторяет некоторый многим привычный, но иноземный, совокупного возраста лет 10-25. И нужно не просто частями наращивать, а чтобы сразу и полностью копия.
Все вот эти вопросы “а какую проблему решаем?” в традиционной продуктовой (да любой) разработке втыкаются в “вот оно вчера так все работало, и мы хотим, чтобы все так же работало, но с вами”. Огромное поле задач для людей, которые умеют в приоритизацию и переговоры, пока разрабы судорожно повторяют фичи возраста 10+ лет, потому что пользователю нужно именно это. Вот такая вот вроде продуктовая, а как бы и нет, разработка. Некоторые бэклоги забиты на годы вперед. Порешает ли пользователь свои проблемы без новых продуктов? Я думаю, что, в какой-то степени, да (просто пример одного из вариантов решения). Понадобятся ли эти забитые бэклоги после этого, хороший вопрос…
Но это шансы и их надо использовать. И в этой ситуации важны качественные принятые решения со стороны разработки, как на, условно, тактическом, так и стратегическом уровне, позволяющие закрыть вопросы того, что нужно было "вчера" и того, что понадобиться "послезавтра". А это не всегда совпадающие истории...
#байки

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

Молодые родители отмечают каждый новый месяц ребенка в течение года. У владельцев собак то же самое со щенками. Я уже немолодой родитель, да и собаки у меня уже взрослые.
Но вот каналу - 1 месяц 🎉
Спасибо, что подписались и, если верить статистике, даже его читаете (знаю-знаю, не все). С одной стороны, хочется у вас попросить обратной связи: чего добавить, чего убрать (больше/меньше баек, больше просто ссылок без моих комментов, долой засилье мемов). А с другой 🫣, лично меня текущий формат пока устраивает. Но с удовольствием подумаю над вашими предложениями, если кому-то захочется поделиться своими мыслями/вопросами/идеями.
Из удивившего в телеге: в тлг-канале не видно, кто именно ставит реакции под сообщениями (в комментариях видно, а в основных постах - нет). Поэтому не стесняйтесь ставить свои 💩 и ❤️- я все равно не вижу кто именно отреагировал, но зато вашу реакцию на пост можно оценить.
Очень признателен тем, что находит время комментировать, спасибо вам большое, вы помогаете.
Задающие вопросы - для вас в моем ❤️ отдельный уголок.
Погнали дальше…
#байки

Все хэштеги и группа для обсуждения
#байки - истории из жизни
#it_memes - веселые картинки по теме канала
#quality
#testing
#test_automation
#unit_testing
#management
#процессы
#tech_read - полезные статьи
#ваши_вопросы - ответы на ваши вопросы, можно задавать любым удобным вам способом
#holywar - посты, которые могут вызывать горение
#мысли_вслух - короткие, но умные мысли, чаще мои :)
#metrics - про метрики (технические, процессные)
#развитие - посты про развитие, свое и команды
#it_философия - посты-наблюдения про отрасль
#codereview
#observability
#собеседования
#вопросы_с_собесов
#про_резюме
#оценка
#тесты_в_проде
#стратегия чтобы это не значило

Все кому заходит контент, но телега мешает его обсуждать, велком в группу https://t.me/+eVSMX4QvqvxlNjcy