🤘 "Mad Devs" ищет AQA инженера с опытом автоматизации тестирования для digital-банкинга в Казахстане.

⚙️ Что нужно будет делать:
- Автоматизация регрессионных тестов мобильных приложений (сначала Android, потом iOS);
- Покрытие автотестами интеграционного слоя системы.

✅ Наши ожидания:
- Знание типов и методологий тестирования;
- Опыт автоматизированного тестирования от 2 лет;
- Понимание жизненного цикла ПО;
- Опыт работы с инструментами тест-менеджмента и багтрекерами, втч. TestRail и Jira);
- Знание высокоуровневого языка программирования Java;
- Опыт автоматизации тестирования, знание различных инструментов для автоматизации, втч. TestNG;
- Опыт написания и поддержки актуальности тестовой документации: тест-кейсы, тест-планы, отчёты о тестировании;
- Умение работать с Jira, Git, Confluence;
- Опыт ручного тестирования мобильных приложений iOS и Android;
- Опыт тест-дизайна, тестирования требований;
- Опыт работы с Java/Selenium/Appium.

🔴 Откликнуться на вакансию
👉 Посмотреть открытые вакансии

#СоветыНачинающимЛидам
Цели Тимлида.

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

Основные цели тимлида:
1. Обеспечивать качество в своем проекте и следовать инженерным практикам. При этом качество может быть:
- Техническое;
- Бизнесовое;
- Персональный успех.
2. Команда не блокирует свою работу событиями как внутри, так и извне.
3. Нагружать команду равномерно задачами в рамках их компетенций.

Начнем с того, что разберем: Как тимлид следит за качеством и что такое техническое качество в принципе.

А ведь действительно? Мы все и всегда говорим за качество, но при этом слово настолько высокоуровневое, что каждый может понимать его по-своему. Со стороны целей мы описали три качества, которые могут быть, но это больше все-таки про пользу или велью. А как-то качество сформировать не получилось и поэтому, наш Тимлид Андрей "Чак" Минкин пустился в ресерч.

Что таки Чак наресерчил? В книжке Metrics and Models in Software Quality Engineering, Second Edition рассматривается качество с разных сторон и популярные мнения по поводу этого сводятся к тому, что качество может быть как-то обсуждено, но не может быть измерено или взвешено. Однако, со стороны инженерии, качество должно быть определено, измеримо, должно мониториться, управлятся и улучшаться.

В книге The Economics of Software Quality авторы попытались дать следующие определения для качества:
- Элегантность(Эргономичность) или красота в глазах смотрящего;
- Пригодность к использованию во многих целях;
- Удовлетворенность пользовательским требованиям, как явно, так и скрыто;
- Свобода от дефектов, возможно Six Sigma уровни;
- Высокая эффективность убирания дефектов;
- Высокая надежность при эксплуатации;
- Просто в изучении и просто в использовании;
- Чистота документации и пользовательских мануалов;
- Простота доступа к пользовательской поддержке;
- Быстрое устранение зарепорченных проблем.

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

Разработчик, хоть и протестирует свое творение, но он никогда не задастся целью сломать его. ☝️ А вот задача QA специалиста и заключается в том, чтобы найти, или создать то сочетание условий, при которых программа перестанет работать. Более того, у QA есть специальные тулы, которые он умело использует для того, чтобы сломать программу.

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

#СоветыНачинающимЛидам

Дядя Боб говорил, что для качества важны:
- Расширяемость
- Сопровождаемость

То есть можно вносить изменения в предсказуемые сроки.

При этом, книга Metrics and Models in Software Quality Engineering, Second Edition говорит еще о важной роли кастомера, ссылаясь еще на одну книгу 70 года "Я знаю это, когда я вижу это" следующие вещи:

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

И у вас больше нет ничего другого, кроме того, как продавать им эти гарантии. У вас нет ничего больше для продажи, чем качество.

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

Новый #Кибирд уже на канале 🔥

Андрей "Чак" Минкин (Teamlead, CTO, co-founder Mad Devs) и Дмитрий Кононенко (Project Manager) поговорят на темы необходимости каждой из ролей, важности работе с людьми, а не только с кодом, сроками и скоупом.

Го смотреть: https://youtu.be/WzZ7SKuruAY

4 songs to code with... 🎷

Жениш - наш Backend Developer, часто слушает музыку во время написания кода. Жениш говорит, что именно эти композиции помогают ему настроиться на работу и создают "вайб программирования", ну что ж... давайте слушать!

🎶 Avicii, Jonas Blue, Kygo, Calvin Harris, Alok, Robin Schulz
🎶 twenty one pilots - Ride
🎶 twenty one pilots: Car Radio
🎶 3 PM Coding Session - Lofi Hip Hop Mix

#СоветыНачинающимЛидам

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

В следующих постах мы расскажем про техническое и бизнесовое качество. Появились вопросы? Задавайте их в комментариях.

🤘 "Mad Devs" ищет Golang developer в финтех проект, который разрабатываем для одного из стартапов в США.

⚙️ Что нужно будет делать:
- Разрабатывать новую архитектуру проекта;
- Покрывать код юнит и интеграционными тестами;
- Рефакторить код в legacy-проекте;
- Ревьюить работы и MR-ы других участников команды;
- Вести задачи в JIRA;
- Писать техническую документацию по продукту.

✅ Наши ожидания:
- 1,5+ лет опыта в разработке и поддержке - коммерческих продуктов вышедших в Production на Go;
- Опыт в разработке и поддержке HTTP API включая подготовку и создание Swagger документации;
- Хорошее знание SQL, а также работа с PostgreSQL в Go;
- Опыт написания миграций в Golang;
- Опыт в использовании Docker и применения Docker-Compose;
- Английский не ниже Intermediate.

🔴 Откликнуться на вакансию
👉 Посмотреть открытые вакансии

#СоветыНачинающимЛидам

Бизнесовое качество - все про бабки. А где бабки - там сроки. Нужно приходить к решению важной проблемы в разумное время и своевременно отслеживать эффективность проекта. C помощью показателя ROI можно проанализировать насколько выгодным или невыгодным является проект или продукт.

Если ты не в курсе что такое бизнес и экономическое мышление, зачем тебе скиллы в маркетинге и как рассчитать ROI, то стоит эту штуку начать изучать, читать книги или общаться с более скилловыми лидами.

5 книг которые стоит прочесть тимлиду:

- Джедайские техники. Как воспитать свою обезьяну, опустошить инбокс и сберечь мыслетопливо, Дорофеев Максим.
- Бизнес с нуля. Метод Lean Startup для быстрого тестирования идей и выбора бизнес-модели, Эрик Рис.
- Цель. Процесс непрерывного совершенствования, Элияху Голдратт.
- Cтоит изучать Chaos Engineering и практики, которые даются в этом подходе. Частично эти подходы можно применять к людям, например Game Day
- Думай медленно… Решай быстро, Даниэль Канеман.

Сегодня Sebastien Goasguen провел тренинг и воркшоп по Kubernetes и Knative для нашей команды. Мы считаем невероятно крутой возможностью не только работать, но и развиваться вместе! 🤘🏻

Если вы - мидл, то вы поймете, о чем пост.

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

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

Хотите стать сеньором? Ведите себя как сеньор:
✅ Берите на себя ответственность;
✅ Проявляйте инициативу;
✅ Работайте для того, чтобы принести ценность, а не выполнить задачу.
✅ Посмотрите выпуск #Кибирд "Плато мидла" или что мешает стать сеньором? 🙂

#СоветыНачинающимЛидам

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

Список вещей, с помощью которых можно добиться качества в проекте:
- Линтеры
- Пайплайны
- Докер
- Тесты
- Мониторинг
- Клауд ошибки
- Клауд логи
- Обсервабилити
- Ридмихи
- Архитектурные схемы
- Перелинковка на правила работы
- Перелинковка на цели и ограничения
- Контроль валидности заполнения задач
- Линковка задач, коммитов и MR
- Автоматизация всего этого процесса дальше

#Кибирд взорвет все чарты! 💣

В гостях "юбилейного" выпуска сооснователь лучшей школы программирования в Центральной Азии Attractor School Максииим Косяков! 🥳Олег Пузанов и Максим Косяков рассказывают про Инженерную Культуру с которой к сожалению мало кто знаком по настоящему. Ждём от вас лайки, коменты и подписки!

Погнали смотреть ➡️ https://youtu.be/P68pyAEJcuI

Вы все еще верите, что общаться в IT вовсе необязательно? Да, так и было раньше, когда профессия программиста была относительно новой, а разработчики работали над проектом в одном офисе.

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

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

#СоветыНачинающимЛидам

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

Большую часть проблем с твоей командой придется решать самостоятельно, однако, часть проблем, которые ты решить не можешь - тебе нужно эскалировать, например на HR.

Для этого ты можешь проводить 1:1 митинги, где вы спокойно говорите либо за жизнь, либо за работу, либо о наболевшем. Эти митинги повышают доверие к тебе, как лиду.

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

Используй возможности тусоваться с командой вне проекта и не забывай хвалить человека за успешную работу.

🤘 "Mad Devs" ищет Python разработчика для разработки финтех проекта.

⚙️ Что нужно будет делать:
- Разрабатывать и развивать бэкенд (новые фичи, доработка текущих, работа над улучшением кодовой базы);
- Интеграция с платежными системами;
- Активно участвовать в выяснении и обсуждении - требований к функционалу, предлагать решения с учетом особенностей системы и вашего предыдущего опыта;
- Участвовать в планировании архитектуры новых сервисов, переработки и оптимизации существующих.
- Планировать и декомпозировать user stories в задачи;
- Принимать участие и проводить code review.

✅ Ожидаем от кандидата:
- 4+ лет опыта разработки на Python/Go;
- Уметь писать тестируемый код;
- Уметь работать в Docker;
- Базовые знания PostgreSQL (Уметь написать простой селект с несколькими жойнами);
- Уметь работать с Git и решать Merge конфликты;
- Опыт работы с CI/CD;
- Уметь писать SOLIDный код.

🔴 Откликнуться на вакансию
👉 Посмотреть открытые вакансии

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

О чем говорит модель обучения которую ты видишь на картинке? Давай рассмотрим простой пример.
1. Опыт
- Менеджер пришел донести обратную связь до сотрудника.
- Наорал на него матом.
- Сотрудник обиделся и уволился.
- Рефлексия.
2. Обдумываем этот опыт
- Обратную связь надо доносить, пусть и эмоционально, но это важная информация.
3. Модель
- Давайте обидчивость и стрессоустойчивость проверять на собеседовании.
4. Практика
- Набираем людей.
- Снова орем матом.
- Снова человек увольняется.
- Идем на пункт один и запускаем второй цикл. Цикл замкнулся.

В момент рефлексии стоит делать следующие вещи:
- Ресерч.
- Общаться с коллегами по цеху (другими лидами) и задавать вопросы.

У тебя в любом случае будет сопротивление обучению, а об этом мы расскажем в следующем посте.

Тестирование - эту стадию некоторые компании просто игнорируют или как минимум недооценивают, но в Mad Devs такой подход недопустим.

Почему мы уделяем тестированию столько времени, чтобы убедиться, что решение действительно работает так, как надо?

Причин на это множество:
♻️ Мы не хотим тратить деньги клиента и свое время на пост-вылавливание множества багов, если можно не накапливать баги, а тестировать все в процессе работы над продуктом.
♻️ Мы не хотим разработать проект с множеством уязвимостей. В конце концов, мы - профессионалы, и мы делаем все максимально качественно.
♻️ Мы любим то, чем мы занимаемся.

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

#СоветыНачинающимЛидам

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

Как это делать? Можно, формировать запрос и смотреть на эту ситуацию с разных сторон и искать проблемы. Начни со своей карьерной мечты. Кем видишь себя? О чем конкретно мечтаешь? Этот вопрос и будет частично формировать видение(V). Не бойся задавать себе вопрос "Зачем?". Именно "зачем", а не "почему" - это важно для того, чтобы прийти к своей конечной цели и сформулировать результат. Задай этот вопрос из раза в раз для более декомпозированного понимания для чего нужно обучение. Помни, что у тебя что-то болит сейчас. Что это? О чем оно? Что конкретно и в какой сфере это болит?(D).

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

Как охладить Air с 85 до 75 градусов? А вот так!