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

Как выстраивать грамотную коммуникацию с подчинёнными? По мнению автора статьи Cindy Sridharan*, многие новоиспечённые начальники, стремясь завоевать расположение людей, слишком вовлекаются в заботу о них и пренебрегают другими важными задачами. В итоге, любовь сотрудников может стать опасной штукой, которая принесёт вред и убытки всей организации. Во всём нужно искать баланс. 

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

*Обращаем ваше внимание, что позиция автора может не всегда совпадать с мнением МойОфис.

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

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

Общепринятой практикой в индустрии является использование тест кейсов в качестве основы для автоматизации тестирования. QA инженеры разрабатывают их на основе user stories в рамках обычного тестирования, а затем автоматизируют эти тесты. С каждой итерацией тестируется больше историй, автоматизируется больше тестовых случаев, и набор автоматических тестов становится всё больше. Руководители продвигают такие метрики, как, например, «процент покрытия» и хвалят команды с высокими показателями. Некоторые компании даже специально нанимают «инженеров по автоматизации», чья единственная работа состоит в том, чтобы брать тест кейсы и автоматизировать их.

К сожалению, автоматизация тест кейсов и навязывание «процента покрытия» — это антипаттерн обеспечения качества, который неизбежно приводит к раздутым и сложным в обслуживании наборам тестов, которые приносят мало пользы. Хотя автоматизация имеет решающее значение для agile delivery, этот чрезмерно упрощенный подход «фабрики автоматизации» не является хорошим способом автоматизации тестирования.

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

Издержки и преимущества автоматизации тестирования

Чтобы понять, почему автоматизация существующих тест кейсов настолько проблематична, нам нужно вернуться назад и немного проанализировать теорию автоматизации. В частности, нам нужно изучить издержки и преимущества автоматизации, посмотреть на ожидаемую ценность автоматизированных тестов во времени, а затем оценить, как ожидаемая ценность меняется в различных типах тестов. Затем мы сможем увидеть, как автоматизация тест кейсов с использованием простого подхода «фабрики автоматизации» повлияет на тестирование в целом.

Так, с женой мы взяли 1 млн ₽, купили станки и запустили свое производство кожаных изделий. Сейчас у нас работает 7 человек.

Всем привет, меня зовут Никита, уже пару лет я зарабатываю на жизнь развитием платформы-как-сервис в СберМаркет. В основном отвечаю за инструменты локальной разработки. Являюсь одним из создателей cli, которая позволяет развернуть сервис со всеми его зависимостями в одну команду sbm-cli service up.

Хочу рассказать, как мы делаем тестирование на моках в PaaS. И поделиться нашим опенсорс-решением на базе Wiremock.

В этой статье вашему вниманию представлено сравнение двух инструментов для поиска ошибок в работе с памятью в программах, написанных на memory-unsafe (небезопасных при работе с памятью) языках — Sanitizers и Valgrind. Эти два инструмента работают совершенно по-разному. Поэтому, хоть Sanitizers (разработанный инженерами Google) имеет ряд преимуществ перед Valgrind, у каждого из них есть свои сильные и слабые стороны. Следует сразу отметить, что проект Sanitizers имеет название во множественном числе, потому что он состоит из нескольких инструментов, которые мы рассмотрим в этой статье в совокупности.

На просторах необъятного можно найти массу статей про выгорание. По этой теме проходят конференции, у многих есть личный опыт. Проблема актуальна и останется такой надолго, ведь первое «выгорание» — это не про вопрос «случится или нет», это про вопрос «когда» и «насколько сильно».

Я начал свой путь как разработчик и был им 15 лет, а сейчас руководитель группы разработки. Прошёл всю дорогу от младшего до ведущего и шагнул дальше. Пока я гнал по карьерному треку, я полноценно выгорал два раза, а потом решил, что хватит это терпеть. И не выгорел третий. Как получилось? Об этом и будет эта статья.

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

За последний год одна из команд автоматизации тестирования МойОфис претерпела несколько крупных трансформаций. Благодаря высокому темпу найма в команду регулярно приходили новые специалисты, но увеличение её численности замедляло процессы: как минимум, встречи длились дольше, а точность планирования снижалась. Для решения проблемы мы решили внедрить в команде внутреннюю механику деления — и в соответствии с её принципами прошли уже три успешных итерации. В результате из одной крупной команды было сформировано несколько, более компактных и эффективных.

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

Пример 1. Тестовый

Ничего не работает

«Но за всей этой красотой скрывается хаос и безумие». — Tanner Walling

Почему?

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

Подобная статья должна была появиться раньше, лет десять или пятнадцать назад, когда Agile только начинал внедряться в ИТ-компаниях. Сколько можно бы было избежать ошибок, проблем, конфликтов, , если бы менеджеры сразу подходили к вопросу правильно, не отвлекаясь на лишние действия …

Зато за это время накопился опыт "внедрений" Agile в разных условиях, в разных компаниях, который следует обобщить и повсеместно распространять.

Прим. перев.: автор данного исследования — Marc Richards, Solutions Architect и DevOps-инженер — продемонстрировал потрясающую настойчивость и тщательность в тотальной оптимизации производительности веб-приложения. Получившийся материал — кладезь полезных знаний для расширения своего кругозора в области оптимизации, особенностей сетевого стека в Linux и не только, даже вне зависимости от практической заинтересованности в конечном результате автора. Приготовьтесь к по-настоящему длинному техническому путешествию с обилием терминологии, увлекательных графиков и полезных ссылок.

Зачастую мне приходится слышать в подкастах или лицезреть в комментариях примерно такой диалог: "Я вашу айтишечку на балде вертел. Я сюда ради денег пришёл, которые в России ни в одной другой области не платят. Я вру на собесах об опыте, потому что работодатели точно так же врут соискателям об условиях работы, требования к джунам сениорские, а зарплата - нет"

Постоянный обмен знаниями, осмысление и применение чужого опыта — фундамент для развития любого разработчика. Но стоит ли искать инсайты исключительно в кругу коллег, или же получать их можно от самых разных людей?

Марианна Беллотти*, тимлид и автор книги «Kill It with Fire», в стремлении стать хорошим руководителем начала все больше размышлять над советами, которые когда‑то помогли ей вырасти в профессии. И поймала себя на мысли: зачастую лучшие из них исходили от людей без опыта работы с программным обеспечением.

Вот пять ее любимых советов.

*Обращаем ваше внимание, что позиция автора может не всегда совпадать с мнением МойОфис.

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

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

Про то как вызывать Python из C написал в прошлой статье, теперь поговорим как делать наоборот и вызывать C/C++ из Python3. Раз начал писать об этом, то раскроем всю тему до конца. Тем более, что ни чего сложного здесь нет тоже.

Да вымереть не могут.

Откуда это всё пошло? Чем так условные «программисты» не угодили? И почему именно программисты?

Со всех сторон интернета слышу: персонала нет на рынке труда, людей в целом мало — не рождаются, умирают, мол, демографическая яма, работать некому, и всё в таком духе. Кадровый голод в промышленности достиг нового рекорда. Дефицит кадров испытывают 42% предприятий, показал июльский опрос Института Гайдара. На момент предыдущего опроса в апреле о нехватке работников заявляли 35% компаний.А теперь главный вопрос — это физически людей не хватает или просто на ту зарплату, что предлагают, никто не хочет идти?

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