К основному контенту

Сообщения

Flaky тесты (они же моргающие или "случайно успешные")

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

Через призму менеджера про "Никаких правил. Уникальная культура Netflix."

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

"The Ongoing Revolution in Software Testing" by Cem Kaner (2004) - разбор общепринятых утверждений о тестировании/тестировщиках

Благодаря давнишнему твиту Alan Page  узнал про чудесную статью Cem Kaner , который еще в 2004 году разобрал популярные утверждения (мифы?) про тестирование и роль тестировщиков. Что именно так разбирается: The Role of Testers • The primary reason to test is to find bugs? • The primary reason to test is to prove the program works correctly? • Testers are THE advocates of quality on a project. • Test groups should evolve into quality assurance groups. • The test group should have the power to block release if product quality is too low. • Testers and programmers have conflicting interests. • The test group should work independently of the programmers. • Testers should push their project teams to follow "appropriately professional development models," like the Waterfall, that require people to THINK before they act. • Testers should base test cases on documented characteristics of the program. If the software documentation is inadequate for this, testers should assert a quality

Обычные и не очень вопросы к собеседованию на позицию Engineering Manager

Навеяно тредом под вопросом Charity Majors , своими собеседованиями и собеседованиями меня :) Может кто найдет что-нибудь интересного себе. Кстати, многие из этих вопросов можно задавать нанимающему менеджеру. Disclaimer: Порядка, приоритета в вопросах ниже нет.  Необходимость и момент их вопрошания зависит от течения беседы.  На полноту и ценность для вас список определенно не претендует. Этот список не значит, что на собеседовании со мной вы услышите именно эти вопросы. 1. Что мотивирует людей вообще (немного теории, а-ля Маслоу, Герцберг, RAMP и тдтп в том числе просто "своими словами"). Что мотивирует вас? Ну и дальше про то, как использовалось в работе. Как работали с так называемыми "underperformance" товарищами? 2. Лидерство vs "быть начальником" - что это для вас? Как вы определяете лидерство? 3. Карьерный рост для разработчиков в ваших командах. Как они растут? Что для вас этот рост, что вы думаете о грейдах (уровнях)? Какой процесс оценки уровня

Тимлид - таинственная роль в реальном мире или фантастические твари среди нас

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

Короткой строкой: новости про Heisenbug с промо и полезные ссылки

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

Как Google от менеджеров пытался отказаться

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