"Люди часто говорят говорят о «нестабильных (flaky)» тестах/проверках. Хочется аккуратно отметить, что это не проверка нестабильна, это наше понимание ситуации таково" (с) Michael Bolton
PS хорошая аналогия, но мне больше нравится определение "случайно успешные" для моргающих тестов
#мысли_вслух #testing #test_automation
PS хорошая аналогия, но мне больше нравится определение "случайно успешные" для моргающих тестов
#мысли_вслух #testing #test_automation
👍4
Мы уже касались темы собесов.
У меня много любимых вопросов кандидатам, компаниям.
Если говорить о вопросах в мой адрес, то тоже есть любимые и не очень.
Самый нелюбимый вопрос мне на собеседованиях: "почему вы не подходите на эту должность/роль?".
Обычно, я настолько честен, прямолинеен, самокритичен и убедителен, что собеседующие после моего ответа даже не знают, что дальше спрашивать...
А какие вопросы не любите вы?
#байки #собеседования
У меня много любимых вопросов кандидатам, компаниям.
Если говорить о вопросах в мой адрес, то тоже есть любимые и не очень.
Самый нелюбимый вопрос мне на собеседованиях: "почему вы не подходите на эту должность/роль?".
Обычно, я настолько честен, прямолинеен, самокритичен и убедителен, что собеседующие после моего ответа даже не знают, что дальше спрашивать...
А какие вопросы не любите вы?
#байки #собеседования
😁7
Интересный пример того, как можно обойтись без менеджера. И все будет работать, якобы масштабироваться и развиваться.
Немного контекста:
«Обязанности менеджера распределены между тремя отдельными ролями: инженерами, лидами групп и коучами.
Инженеры. Все инженеры берут на себя роль технических руководителей и несут ответственность за достижение высокого технического уровня. Они самостоятельно определяют области, требующих улучшения, и они берут на себя ответственность за необходимые изменения. Будь то предложение по улучшению процесса, внедрение нового инструмента или усовершенствование существующей системы, инженеры имеют право инициировать эти улучшения. Все предложения обязательно документируются.
Лиды групп: отвечают за организацию группы для своевременного выполнения высококачественной работы. Они также являются «обычными» инженерами по совместительству и продолжают писать код.
Коучи: отвечают за развитие и поддержку подопечных в реализации их потенциала и определении следующих шагов в их карьере. Коучинг — это деятельность, которую сотрудники компании выполняют параллельно со своей основной работой, и это не штатная должность.»
PS почитал, улыбнулся, где-то по чертогам памяти вспышкам пробежала аналогичная история из моего опыта...
НИХЕРА оно не масштабируется 😂
Там нюансов до одного места и самый важный из них - люди. Инженеров, которые будут готовы работать и умеют работать в такой парадигме очень мало. И как только компания решит расти, все мгновенно вернется к традиционной модели управления.
#management #байки #процессы
Немного контекста:
«Обязанности менеджера распределены между тремя отдельными ролями: инженерами, лидами групп и коучами.
Инженеры. Все инженеры берут на себя роль технических руководителей и несут ответственность за достижение высокого технического уровня. Они самостоятельно определяют области, требующих улучшения, и они берут на себя ответственность за необходимые изменения. Будь то предложение по улучшению процесса, внедрение нового инструмента или усовершенствование существующей системы, инженеры имеют право инициировать эти улучшения. Все предложения обязательно документируются.
Лиды групп: отвечают за организацию группы для своевременного выполнения высококачественной работы. Они также являются «обычными» инженерами по совместительству и продолжают писать код.
Коучи: отвечают за развитие и поддержку подопечных в реализации их потенциала и определении следующих шагов в их карьере. Коучинг — это деятельность, которую сотрудники компании выполняют параллельно со своей основной работой, и это не штатная должность.»
PS почитал, улыбнулся, где-то по чертогам памяти вспышкам пробежала аналогичная история из моего опыта...
НИХЕРА оно не масштабируется 😂
Там нюансов до одного места и самый важный из них - люди. Инженеров, которые будут готовы работать и умеют работать в такой парадигме очень мало. И как только компания решит расти, все мгновенно вернется к традиционной модели управления.
#management #байки #процессы
Medium
Scaling Engineering Teams Without Traditional Managers
When I joined Alan, the engineering team consisted of roughly 20 people, and we firmly held the perspective that engineers should not…
🔥10❤1
Самая известная структура компании (модель масштабирования) имени компании: Spotify model.
Многие до сих пор пытаются внедрить то, что рассказывал Книберг в 2014 не особо вдаваясь в детали, причины и подноготную этого устройства. А между тем в Spotify уже давно все не так, как все привыкли себе представлять. И сложности ровно такие же, как у нас всех: менеджмент, синхронизация команд, развитие людей.
И неважно как у вас называются команды, их менеджеры, как команды объединены, важно как в работе учитываются эти моменты:
•Поставка ценности – все улучшения системы следует проверять, задавая вопрос: помогает ли это улучшение/эксперимент нам обеспечить ценность?
•Обеспечение ценности продукта – требует проведения экспериментов и выяснения того, что работает для реальных конечных пользователей.
•Автономия важнее управления и контроля – без автономии невозможно обучение, совершенствование, инновации или способность адаптироваться к меняющимся обстоятельствам.
•Синхронизация — вместо того, чтобы указывать людям, что делать как с функциями продукта, так и с архитектурой продукта, сосредоточьтесь на том, чтобы команды согласовывали свои планы с общей целью продукта.
•Кросс-функциональные продуктово-ориентированные команды (фиче-тимы) — вместо функциональных команд (база данных, бизнес-логика, пользовательский интерфейс).
•Инженерная культура, ориентированная на обеспечение качества и простоты: создайте конвейер непрерывной поставки, который позволит командам создавать ценность независимо друг от друга. По сравнению с конвейером, который требует ожидания, пока команда DevOps выполнит развертывание. Во многих организациях DevOps — это команда, следующая за функциональной командой, которая развертывает приложение. Это известный антипаттерн.
•Психологическая безопасность – ключевым элементом дружелюбности к эксперименту является создание среды, в которой мы можем признать, что рискуем и извлекаем уроки из этого процесса. Причудливое название этого явления – «психологическая безопасность».
•Постоянное совершенствование как особенность системы: команды никогда не перестают совершенствоваться. Нам необходимо создать культуру, которая будет способствовать такому мышлению.
•Моральный дух – готовность и настойчивость членов команды работать ради общего блага.
•Улучшение потока работы через систему — инструменты включают ограничение незавершенной работы, перекрестную профессиональную переподготовку и устранение узких мест. Вы можете измерить успех этого как с помощью Cycle Time и Lead Time.
Что еще почитать:
Spotify doesn’t use “the Spotify model” and neither should you.
#процессы
Многие до сих пор пытаются внедрить то, что рассказывал Книберг в 2014 не особо вдаваясь в детали, причины и подноготную этого устройства. А между тем в Spotify уже давно все не так, как все привыкли себе представлять. И сложности ровно такие же, как у нас всех: менеджмент, синхронизация команд, развитие людей.
И неважно как у вас называются команды, их менеджеры, как команды объединены, важно как в работе учитываются эти моменты:
•Поставка ценности – все улучшения системы следует проверять, задавая вопрос: помогает ли это улучшение/эксперимент нам обеспечить ценность?
•Обеспечение ценности продукта – требует проведения экспериментов и выяснения того, что работает для реальных конечных пользователей.
•Автономия важнее управления и контроля – без автономии невозможно обучение, совершенствование, инновации или способность адаптироваться к меняющимся обстоятельствам.
•Синхронизация — вместо того, чтобы указывать людям, что делать как с функциями продукта, так и с архитектурой продукта, сосредоточьтесь на том, чтобы команды согласовывали свои планы с общей целью продукта.
•Кросс-функциональные продуктово-ориентированные команды (фиче-тимы) — вместо функциональных команд (база данных, бизнес-логика, пользовательский интерфейс).
•Инженерная культура, ориентированная на обеспечение качества и простоты: создайте конвейер непрерывной поставки, который позволит командам создавать ценность независимо друг от друга. По сравнению с конвейером, который требует ожидания, пока команда DevOps выполнит развертывание. Во многих организациях DevOps — это команда, следующая за функциональной командой, которая развертывает приложение. Это известный антипаттерн.
•Психологическая безопасность – ключевым элементом дружелюбности к эксперименту является создание среды, в которой мы можем признать, что рискуем и извлекаем уроки из этого процесса. Причудливое название этого явления – «психологическая безопасность».
•Постоянное совершенствование как особенность системы: команды никогда не перестают совершенствоваться. Нам необходимо создать культуру, которая будет способствовать такому мышлению.
•Моральный дух – готовность и настойчивость членов команды работать ради общего блага.
•Улучшение потока работы через систему — инструменты включают ограничение незавершенной работы, перекрестную профессиональную переподготовку и устранение узких мест. Вы можете измерить успех этого как с помощью Cycle Time и Lead Time.
Что еще почитать:
Spotify doesn’t use “the Spotify model” and neither should you.
#процессы
👍9
Если вы хотите быстро улучшить результаты тестирования, замените «проверить X» на «ищите проблемы, связанные с X» М.Болтон
#мысли_вслух #testing
#мысли_вслух #testing
❤6
Период активного внедрения Agile/Scrum (для многих это до сих пор синонимы) в работу IT-команд совпал с моим становлением, как менеджера. И уже тогда у меня были вопросы “нафига нужен Scrum Master, если есть лид?” Ну то есть, чтобы что? Почему лид не может делать то, что ожидается от SM?
Версий было много, правильного ответа до сих пор нет (у меня нет, у теоретиков наверное есть). Есть только предположение, что далеко не каждый человек получивший менеджерские лычки и соответствующие полномочия сможет выстраивать в команде процессы, самоорганизацию и тп без подключения “дубинки” полномочий. А у SM какие полномочия? Только тру лидершип (чистое лидерство). И каждый вертится, как умеет...
И вот, не прошло и 20 лет, ты-дынц “Вашим следующим Scrum Master должен стать ваш менеджер”.
#management #процессы #байки
Версий было много, правильного ответа до сих пор нет (у меня нет, у теоретиков наверное есть). Есть только предположение, что далеко не каждый человек получивший менеджерские лычки и соответствующие полномочия сможет выстраивать в команде процессы, самоорганизацию и тп без подключения “дубинки” полномочий. А у SM какие полномочия? Только тру лидершип (чистое лидерство). И каждый вертится, как умеет...
И вот, не прошло и 20 лет, ты-дынц “Вашим следующим Scrum Master должен стать ваш менеджер”.
#management #процессы #байки
Scrum.org
Your Next Scrum Master Should Be Your Manager
In a significant shift from their previous stance, Ryan Ripley and Todd Miller, hosts of "Your Daily Scrum," now advocate for integrating the role of Scrum Master with delivery managers and directors, countering their earlier advice to avoid this practice.
👍1
В этот раз тег #holywar сразу в заголовке: можем ли мерять продуктивность?
Один из моих любимых вопросов на собесе: в чем разница между производительностью и продуктивностью. Обычно обширное поле для рассуждений.
А эта короткая старая статья в свое время похоже заложила фундамент того, что я сейчас понимаю под эффективной работой и сеньорностью. Это понимаешь только спустя годы :)
There's No Such Thing As Software Productivity
Тезисы:
• Разработка ПО не является деятельностью, которая обязательно производит что-либо
• То что делают хорошие разработчики - они устраняют проблемы
• Ты не можешь измерить разницу продуктивности между хорошим и плохим разработчиком потому что там нет ничего, что можно измерить
• Если мы смогли решить проблему, вообще ничего не создавая, то все, что мы на самом деле производим - деньги на ветер
PS рубрика "листая дневничок": это я наткнулся на свою запись в блоге про эту статью.
PS2 А хорошо, до сих пор хорошо: "Добавить нечего. Надо просто вбить себе это directly в мозг! Лучше гвоздями." (с) Шульга
#metrics #it_философия
Один из моих любимых вопросов на собесе: в чем разница между производительностью и продуктивностью. Обычно обширное поле для рассуждений.
А эта короткая старая статья в свое время похоже заложила фундамент того, что я сейчас понимаю под эффективной работой и сеньорностью. Это понимаешь только спустя годы :)
There's No Such Thing As Software Productivity
Тезисы:
• Разработка ПО не является деятельностью, которая обязательно производит что-либо
• То что делают хорошие разработчики - они устраняют проблемы
• Ты не можешь измерить разницу продуктивности между хорошим и плохим разработчиком потому что там нет ничего, что можно измерить
• Если мы смогли решить проблему, вообще ничего не создавая, то все, что мы на самом деле производим - деньги на ветер
PS рубрика "листая дневничок": это я наткнулся на свою запись в блоге про эту статью.
PS2 А хорошо, до сих пор хорошо: "Добавить нечего. Надо просто вбить себе это directly в мозг! Лучше гвоздями." (с) Шульга
#metrics #it_философия
👍2🔥2
Закон Парето (он же принцип 80/20):
80% результатов возникают из 20% причин, а 80% результатов возникают из 20% усилий.
Примеры из IT:
• 80% пользователей используют только 20% фичей
• 80% багов находятся в 20% кода
• 90% падений происходит из-за 10% ошибок
• 80% времени на фикс багов приходится на 20% от всех багов
• 80% изменений делается в 20% кода
• 80% кода пишется за 20% времени, оставшиеся 20% кода пишутся за оставшиеся 80% времени
Подробнее со ссылками на пояснения (не все уже открывается по ссылкам из статьи, но гуглится, при желании)
80% постов читают только 20% подписчиков 😃
#it_философия
80% результатов возникают из 20% причин, а 80% результатов возникают из 20% усилий.
Примеры из IT:
• 80% пользователей используют только 20% фичей
• 80% багов находятся в 20% кода
• 90% падений происходит из-за 10% ошибок
• 80% времени на фикс багов приходится на 20% от всех багов
• 80% изменений делается в 20% кода
• 80% кода пишется за 20% времени, оставшиеся 20% кода пишутся за оставшиеся 80% времени
Подробнее со ссылками на пояснения (не все уже открывается по ссылкам из статьи, но гуглится, при желании)
80% постов читают только 20% подписчиков 😃
#it_философия
👍7🤝1
"На каждом проекте, как ты его ни планируй, рано или поздно наступает фаза «Херачим!»" (c) чье-то из интернетов 2014
#мысли_вслух #it_философия
#мысли_вслух #it_философия
😁7💯5🔥3
Сегодня скучный пост. Пробую себя уговорить почитать очередные несколько статей про технические стратегии. Пока не знаю зачем, больше похоже на фантомные боли. Все вокруг так быстро меняется, что думать о чем-то глобальном и продолжительном кажется бессмысленным.
Немного рефлексии.
Что такое стратегия?
Посмотреть интернеты, доклады, книги - везде все вроде похоже, но понимание у всех все равно разное.
Вспоминая свой первый опыт “стратегирования”*, его результаты и последующую работу над реализацией стратегии, до сих пор не могу понять, почему оно забуксовало. Быстро порешав самые больные места дальше остановилось и больше не ожило. Но опыт был интересный.
*стратегирование - процесс разработки стратегии или выезд на “стратегическую сессию”.
Обычно самые сложные вопросы решаемые на “стратегировании” - это “зачем нам туда”, “чтобы что” и классическое “как мы поймем, что дошли” (интересно, кто-то вообще доходит?).
Часто считается, что стратегия - это сценарий, высокоуровневый недетализированный план достижения цели.
Причины разработки стратегии и ее цель первичны.
Цель "у нас должна быть стратегия" - не цель.
В этот момент у многих срывает крышу и они требуют от стратегии детализированного плана и шагов, которые нужно будет выполнить, превращая стратегию в набор тактических (конкретных) движений. Соблазнительная, но опасная ловушка.
В комментах хорошая картинка про хорошую/плохую стратегии.
Продолжение следует...
#it_философия #байки #стратегия
Немного рефлексии.
Что такое стратегия?
Посмотреть интернеты, доклады, книги - везде все вроде похоже, но понимание у всех все равно разное.
Вспоминая свой первый опыт “стратегирования”*, его результаты и последующую работу над реализацией стратегии, до сих пор не могу понять, почему оно забуксовало. Быстро порешав самые больные места дальше остановилось и больше не ожило. Но опыт был интересный.
*стратегирование - процесс разработки стратегии или выезд на “стратегическую сессию”.
Обычно самые сложные вопросы решаемые на “стратегировании” - это “зачем нам туда”, “чтобы что” и классическое “как мы поймем, что дошли” (интересно, кто-то вообще доходит?).
Часто считается, что стратегия - это сценарий, высокоуровневый недетализированный план достижения цели.
Причины разработки стратегии и ее цель первичны.
Цель "у нас должна быть стратегия" - не цель.
В этот момент у многих срывает крышу и они требуют от стратегии детализированного плана и шагов, которые нужно будет выполнить, превращая стратегию в набор тактических (конкретных) движений. Соблазнительная, но опасная ловушка.
В комментах хорошая картинка про хорошую/плохую стратегии.
Продолжение следует...
#it_философия #байки #стратегия
👍1
Сегодня тоже про стратегию, но нескучно, потому что автор не я.
"В жизни каждой организации неизбежно наступает период когда менеджеры в ней превращаются в стратегов.
Менеджер становится стратегом не сразу, не в один день.
Менеджер делает какое-то дело, его люди делают это дело.
Дело даже получается, так может повторится даже несколько раз.
Люди у менеджера учатся, проявляют инициативу.
И в какой-то момент менеджер понимает, что ему больше не нужно делать менеджерскую рутину. Что он может подумать о ней… о стратегии.
Стратегия, сука, непонятная.
Она вроде бы и есть, а вроде бы и нет. Вот с тактикой все просто - взял кусок работы, нарезал на спринты, ходишь на стендапы, решаешь проблемы команды, получаешь результаты и обратную связь.
А со стратегией все сложно - ты ее подумал, обсудил, проговорил с людьми. Может быть даже записал на бумажку и придал ей официальный статус.
Но ее нет. Физически ее нет.
Поэтому стратегу нужно, конечно, подумать эту вот самую стратегию, обсудить ее, проговорить ее и ... идти выполнять. Самому.
И тут собственно и наступает тот самый критичный для менеджера момент - кто-то может отвернуться (пусть и на время) от этой бездны стратегии, и пойти обратно в окопы, а кого-то засасывает эта метафизическая бездна.
Это конечно идеализированная картина мира, где только черное и белое, но (!!!)- конченых стратегов нужно отстреливать!" (с) Никита Макаров
#it_философия #стратегия
"В жизни каждой организации неизбежно наступает период когда менеджеры в ней превращаются в стратегов.
Менеджер становится стратегом не сразу, не в один день.
Менеджер делает какое-то дело, его люди делают это дело.
Дело даже получается, так может повторится даже несколько раз.
Люди у менеджера учатся, проявляют инициативу.
И в какой-то момент менеджер понимает, что ему больше не нужно делать менеджерскую рутину. Что он может подумать о ней… о стратегии.
Стратегия, сука, непонятная.
Она вроде бы и есть, а вроде бы и нет. Вот с тактикой все просто - взял кусок работы, нарезал на спринты, ходишь на стендапы, решаешь проблемы команды, получаешь результаты и обратную связь.
А со стратегией все сложно - ты ее подумал, обсудил, проговорил с людьми. Может быть даже записал на бумажку и придал ей официальный статус.
Но ее нет. Физически ее нет.
Поэтому стратегу нужно, конечно, подумать эту вот самую стратегию, обсудить ее, проговорить ее и ... идти выполнять. Самому.
И тут собственно и наступает тот самый критичный для менеджера момент - кто-то может отвернуться (пусть и на время) от этой бездны стратегии, и пойти обратно в окопы, а кого-то засасывает эта метафизическая бездна.
Это конечно идеализированная картина мира, где только черное и белое, но (!!!)- конченых стратегов нужно отстреливать!" (с) Никита Макаров
#it_философия #стратегия
🔥4
Закончим страт-рефлексию одной из лучших подборок материалов по технической стратегии.
Если уж кому повезет ею заниматься, будьте готовы.
https://lethain.com/strategy-notes/
Ну а дальше, весьма традиционно: "пни вперед - комбинация придет".
#management #стратегия
Если уж кому повезет ею заниматься, будьте готовы.
https://lethain.com/strategy-notes/
Ну а дальше, весьма традиционно: "пни вперед - комбинация придет".
#management #стратегия
Lethain
Engineering strategy notes.
Recently, I am thinking quite a bit about engineering strategy,
and as part of that, I have started re-reading previous resources
on the topic, and looking for new things to read while I refine
my point of view on what makes for good engineering strategy.…
and as part of that, I have started re-reading previous resources
on the topic, and looking for new things to read while I refine
my point of view on what makes for good engineering strategy.…
👍3
У меня в блоге было немного техники, даже когда я еще был, как говорят hands on в этой технике. Сейчас уж и подавно.
Только посты в английской версии блога (да-да была и такая) были техническими.
Но писал про то, что было интересно: готовишь например бюджет на следующий год для конференций, смотришь что-где-как, пишешь статью. Съездил/сходил на конфу - описал впечатления. Некоторые до буквально до недавнего времени были в топе поиска, потому что название конференции и статьи очень понравилось поисковым движкам, а контент они игнорировали.
Аншлаговые были статьи с точки зрения трафика. HR-ы (не мои) рассылали своим сотрудникам, для планирований 😄
А сейчас сдув пыль, можно посмотреть, какие они были эти конференции 10 лет назад...
Летопись конференц-движения 😂
#байки
Только посты в английской версии блога (да-да была и такая) были техническими.
Но писал про то, что было интересно: готовишь например бюджет на следующий год для конференций, смотришь что-где-как, пишешь статью. Съездил/сходил на конфу - описал впечатления. Некоторые до буквально до недавнего времени были в топе поиска, потому что название конференции и статьи очень понравилось поисковым движкам, а контент они игнорировали.
Аншлаговые были статьи с точки зрения трафика. HR-ы (не мои) рассылали своим сотрудникам, для планирований 😄
А сейчас сдув пыль, можно посмотреть, какие они были эти конференции 10 лет назад...
Летопись конференц-движения 😂
#байки
www.maxshulga.ru
IT-конференции в 2013 или где можно будет найти много IT-шников
Куда сходить, куда съездить, где поучиться в 2013? Во многих организациях уже начали планировать бюджет на программу обучения сотрудников...
❤3
Давно ничего не было про тестирование.
Слышал кто-нибудь про принципы "Современного тестирования"?
Да, Алан пишет, что это не совсем про тестирование, как его многие понимают, и не про "современное", а скорее про поставку ценности.
У меня очень откликается.
Самим принципам (первой их версии) уже больше 5 лет.
Принципы Modern Testing 2.0 (бета):
• Наш приоритет – развитие бизнеса.
• Мы используем такие модели, как бережливое мышление (Lean Thinking) и теорию ограничений (Theory of Constraints), которые помогают выявить, расставить приоритеты и устранить узкие места в системе.
• Мы являемся движущей силой постоянного совершенствования, адаптируем и оптимизируем наши практики, чтобы добиться успеха, вместо того, чтобы быть системой для выявления наших неудач.
• Мы глубоко заботимся о культуре качества в нашей команде: обучаем, руководим и воспитываем друг друга в направлении более зрелой культуры качества.
• Мы считаем, что только клиент может судить и оценивать качество нашего продукта.
• Мы активно используем данные, чтобы глубже понять, как клиенты используют наш продукт, а затем устранить разрыв между гипотезами о продукте и влиянием на бизнес.
• Мы расширяем возможности и экспертизу всей команды; понимая при этом, что эти действия могут уменьшить (или даже устранить) потребность в специализированных специалистах.
Тут можно почитать про принципы подробнее.
Еще интересно: Alan Page on Testing: From Past to Future
#testing #it_философия
Слышал кто-нибудь про принципы "Современного тестирования"?
Да, Алан пишет, что это не совсем про тестирование, как его многие понимают, и не про "современное", а скорее про поставку ценности.
У меня очень откликается.
Самим принципам (первой их версии) уже больше 5 лет.
Принципы Modern Testing 2.0 (бета):
• Наш приоритет – развитие бизнеса.
• Мы используем такие модели, как бережливое мышление (Lean Thinking) и теорию ограничений (Theory of Constraints), которые помогают выявить, расставить приоритеты и устранить узкие места в системе.
• Мы являемся движущей силой постоянного совершенствования, адаптируем и оптимизируем наши практики, чтобы добиться успеха, вместо того, чтобы быть системой для выявления наших неудач.
• Мы глубоко заботимся о культуре качества в нашей команде: обучаем, руководим и воспитываем друг друга в направлении более зрелой культуры качества.
• Мы считаем, что только клиент может судить и оценивать качество нашего продукта.
• Мы активно используем данные, чтобы глубже понять, как клиенты используют наш продукт, а затем устранить разрыв между гипотезами о продукте и влиянием на бизнес.
• Мы расширяем возможности и экспертизу всей команды; понимая при этом, что эти действия могут уменьшить (или даже устранить) потребность в специализированных специалистах.
Тут можно почитать про принципы подробнее.
Еще интересно: Alan Page on Testing: From Past to Future
#testing #it_философия
❤5
"Независимо от того, руководите ли вы менеджером или отдельным мега-разработчиком, ваша задача одна: вы всегда держите руку на пульсе и контролируете, какова их цель. Однако детали того, как достигается эта цель, являются деталями реализации, которые вы им делегируете" отсюда
🤝 очень откликается
#management
🤝 очень откликается
#management
👍5❤1
Му-Му — говорит коровка.
Гав-Гав — говорит собачка.
Еще два дня и релизим — говорят разработчики третий месяц.
А потом на ретро релиза...
Картинка (с) Maxim Dorofeev, ей недавно исполнилось 10 лет...
#it_memes
Гав-Гав — говорит собачка.
Еще два дня и релизим — говорят разработчики третий месяц.
А потом на ретро релиза...
Картинка (с) Maxim Dorofeev, ей недавно исполнилось 10 лет...
#it_memes
😁11
"The Definitive Guide to API Test Automation With Playwright"
Большой цикл статей про автоматизацию тестирования API с помощью Playwright.
#test_automation #tech_read
Большой цикл статей про автоматизацию тестирования API с помощью Playwright.
#test_automation #tech_read
Playwright Solutions
The Definitive Guide to API Test Automation With Playwright: Introduction
I have had a few folks ask if it's possible to do API testing with Playwright, the short answer YES! With this next series of posts I will walk through all the ins and outs of utilizing Playwright for all your API Testing needs. This will be the first article
👍1
"Интересно, сколько раз это должно повториться, прежде чем мы наконец запомним, что «сделано» от разработчика может означать «работа только начинается». Надо чаще с ними общаться" (с) чье-то из древних интернетов
#мысли_вслух
#мысли_вслух
🔥3😢2👍1