Пост ниже не реклама, точнее не совсем она.

Мы только-только запустили новый поток моего авторского курса java advanced (более 50 занятий от меня и Миши Рубанова) в QA.guru. Если вдруг вы хотели на него попасть, то сейчас самое время успеть, а если вам интересно, что там и как там, приходите в пятницу меня послушать:

🎄 Пирамида тестирования, или как перестать бояться deploy на продакшен и встретить Новый год без багов!

Друзья, привет!

У нас с QA.GURU для вас специальный новогодний подарок – финальный открытый урок в этом году, и он будет суперполезным и праздничным! Уже в эту пятницу, 27 декабря, в 18:00 по МСК, мы разберем, как строить пирамиду тестирования, чтобы ваш код не рухнул, как новогодняя елка, когда на нее прыгнул кот 😼

🎅 Стрим буду вести я🌲

✨ На встрече вы узнаете:

• Как правильно выстроить пирамиду тестирования, чтобы проект держался крепко и уверенно.
• Где заканчиваются юниты, начинаются интеграции и появляется немного end-to-end тестов.
• Какие тесты реально спасают ваши нервы и продакшен, а какие просто красиво смотрятся в отчете.

🎄 Звездой на вершине новогодней елки станет написание тестов для микросервисного Spring Boot проекта Niffler-NG:

• Юнит-тесты (JUnit + Mockito) – чтобы убедиться, что методы работают не хуже, чем новогодние скидки.
• Интеграционные тесты (spring-test + h2db) – чтобы проверить, как работает наше REST API
• End-to-end тесты — чтобы выглядело красиво, а не только просто работало.

И все это за 1 час!

Регистрируйтесь по ссылке и зовите коллег, друзей и всех, кто хочет встретить праздники с прокачанным QA-навыком!

С наступающими праздниками, и до встречи на стриме!

Сегодня ровно 3 года в DODO.

Чем я могу гордиться? Успешной борьбой за то, что бы вилки QA Auto и QA Performance были такими же высокими, как у разработчиков. Полным ребилдом наших нагрузочных тестов своими руками, а затем - наймом лида, закрывшего собой вопросы нагрузочного тестирования "под ключ". Вообще, мы собрали очень крутых лидов для всех направлений тестирования (Mobile, Web, Perf и Drinkit). Горжусь выстроенными взаимодействиями с CIO, CTO и продактами, благодаря которым нам не мешают внедрять то, что мы хотим, тестировать - как мы хотим, а мы не мешаем релизить, менять инфру и требования на лету. Технически - внедрили TestOps, Playwright, Kaspresso, написали тестов на flutter приложение курьера, создали уникальное для рынка self-service решение для работы с нагрузкой. Собрали топовую команду тестирования в наш второй по размеру, но не по значимости бизнес - Drinkit - и эта команда завела 574 бага за 2024 год🥲. Мы стали считать баги, и мы не витаем в абстрактных процессах "сделать так, что бы багов не было". Мы стали писать код на собеседованиях. Мы продолжаем релизить ядро нашей системы - DODO IS - без ручного тестирования вообще.

Нас уже 31 QA инженер, мы выросли в 2 раза. Закрываем по 6-7 OKR на свою QA гильдию каждый квартал, и нам все еще есть куда стремиться.

Мы выступаем на конференциях и митапах, и у нет-нет, да и приходят кандидаты, которые хотели бы работать именно с нами.

А я - все еще хочу работать именно в DODO 🍕

Про премии 📈

Премии, на мой взгляд, обычно бывают трех видов (с двумя из них я сталкивался в своей работе, третий знаю в теории):

1) Просто "Пришла радость откуда не ждали" - это когда на Новый Год (или ДР компании, или на 8 Марта, в общем, в дени ИКС) всем приходит push из банка о поступлении 13-й з.п. Вне зависимости от должности, успехов и так далее - назовем его условно "благодать ❤️"

2) Когда компания ставит прозрачные цели (всем вместе заработать за квартал 100 рублей, всем вместе продать 3 ящика пива, выкопать 854 метра траншеии и так далее), и если цель достигается - все сотрудники получают push из банка о премии. Тут может быть дифференцацция от стажа, может быть должности - но важно, что это не некий персональный KPI Васи-тестировщика или менеджера, это - компания делится достигнутым успехом со всеми - назовем ее условно "успехшэринг 📈"

3) Когда у конкретного Васи-тестировщика или (что чаще в реальной жизни) менеджера по продажам или рекрутера есть персональный KPI: заведистолько-то багов или автотестов, продай столько-то зановесок, найми столько-то других Василиев. Обычно сопровождается маленьким базовым окладом и премия является неотъемлемой частью совокупного дохода и требует персональной борьбы за KPI. Назовем такую премию "личныйкнутопряник 👔"

Есть еще четвертый тип - у топ-менеджеров C-lvl (чаще CEO/CIO), но, тут не о них.

Так вот, я в своей карьере постоянно встречался с типами 1(благодать) и 2(успехшэринг). И это было клево, клево во всех смыслах - все радовались на новый год, все старались в меру своих сил и талантов помогать компании заработать / выкопать / продать побольше и потом опять-таки радовались.

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

Теперь важный факт: В DODO нет премий. Вообще никаких 🥲

А на вопросы почему - приводятся аргументы о недостатках кнутоприянка, которые объективно есть, но не приводят аргументов о преимуществах двух других типов, которые тоже объективно есть.

Ниже будет опрос, хочу подискутировать 🦆

Если не премии, то что?

Прошлый мой пост про премии был бы не полным без рассуждения о том, что же предлагают нам те работодатели, которые не платят премии, и DODO Brands в частности?

У нас это оклады по верху рынка + опционы.

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

10 апреля этого года отвечал на вопрос о зарплатах QA у нас, и без контекста это выглядит действительно странными цифрами: от 128 до 540.

Все дело в том, что позиция QA в нашей сетке грейдов поднимается довольно высоко - от 11 грейда до 7-го (для контекста: C-lvl обитает в 1-4). итого 128 - это минимальная зарплата на 11 грейде, 540 - была максимальной для QA на 7-м. Почему "была"? Потому что на 2025 год у нас будет новая сетка окладов , которая для некоторых грейдов выше до 20% относительно окладов 2024 года.

Итого, отвечая на прямой вопрос - можно ли зарабатывать, скажем, порядка 6000$ будучи QA (да, максимального грейда, то есть техлидом)? Да. Сложно ли это? Безусловно. Но эта возможность закреплена в нашей сетке грейдов, а значит, она есть.😁

Выше рынка ли такие зарплаты? Я считаю, что на данный момент для СНГ рынка - да, а причина тому - именно тот факт что наши C&B (компенсэйшн энд бенефитс) специалисты закладывают премии в оклад.

Почему это лучше?

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

Допускаю, что в коментах будут те, у кого и оклад 100500, и еще и премии каждый квартал (и я понимаю, что по мировым меркам мы, конечно, не FAANG), но мне хочется верить, что кто-то из вас примет вызов стать QA 7 грейда в DODO в 2025 году.

Всех с новым годом!🎄

#java

Сегодня впервые воспользовался ключевым словом yield в Java, описывая банальный switch-case:

   return switch (action) {
      case ADD -> ...;
      case ACCEPT -> ...;
      case REJECT -> ...;
      case DELETE -> {
        userDataClient.remove(username, input.username());
        yield ...;
      }
    };

Я такой - "о, а return из функции -> {} тут уже не работает" и стал смутно вспоминать, что должен же быть какой-то иной способ. Решил погуглить, когда оно там появилось, оказалось что аж в 13 Java - вот так и живешь годами не используя целое ключевое слово.

Вывод - советую читать релиз ноуты того, что в вашем резюме, как бы банально это не казалось 🥲

#graphql

Как известно, спецификация graphql предусматривает информирование об ошибке одновременно с возвратом той части данных, которые удалось получить. И, в связи с этим, референсная frontend библиотека apollo даже имеет три стратегии обработки таких ответов:

1️⃣ игнорировать errors, если пришло хоть что-то в data
2️⃣ игнорировать data, если пришло хоть что-то в errors
3️⃣ не игнорировать ничего (и data и errors предлагается обрабатывать самостоятельно как вы хотите)

Глядя на эти политики, меня не покидает ощущение, что варианты 1️⃣ и 2️⃣ как будто сужают спецификацию, что для меня бы, как гипотетического бэкендера, выглядело странно: почему ты игнорируешь то, что я старательно тебе вернул? 😁

А вариант 3️⃣ представлен красивым примерчиком frontend-кода:

function ShowingSomeErrors() {
  const { loading, error, data } = useQuery(MY_QUERY, { errorPolicy: "all" });

  if (loading) return <span>loading...</span>;
  return (
    <div>
      <h2>Good: {data.goodField}</h2>
      <pre>
        Bad:{" "}
        {error.graphQLErrors.map(({ message }, i) => (
          <span key={i}>{message}</span>
        ))}
      </pre>
    </div>
  );
}

Внимание вопрос: если вы работаете с GraphQL, то какая стратегия обработки ошибок используется у вас?
И, если это 3️⃣ (не игнорировать ничего), то весь ваш фронтенд действительно обмазан и обработкой data, и обработкой error для всех запросов, где есть nullable fields?

Копаясь в вещах случайно обнаружил завалявшуюся часть своих бэйджиков с конференций.

Моей первой крупной конференцией, не считая митапов, был Heisenbug весной 2018 года, где я сразу занял почетное 8 место 😁 из 30+ докладов.

Сейчас за спиной уже около 20 конференций, три программных комитета (прямо сейчас мы готовим QA секцию Codefest.15, пишите, если интересно выступить✍️ ), но, сил делать доклады сейчас почти не осталось. Всю свою энергию рассказывать и делиться я трачу на запись ~50 видосов своего авторского курса. Записывать приходится по вечерам и ночам, вид у меня (как говорят) - усталый, но, таким образом я оцифровываю весь свой технический QA опыт, который неизбежно будет таять с этим менджерством, в котором я уже 4-й год. Об этом, кстати, ни разу не жалею🤘

Предлагаю в треде делиться своими любимыми спикерами и докладами, на любые IT темы. Свой список тоже напишу ⬇️

Раз уж выяснилось, что треды к постам работают как-то странно, то дублирую отдельным постом мой топ спикеров, которых рекомендую к просмотру 📺

Итак, мой топ спикеров (в случайном порядке, со ссылками на некоторые доклады):

Андрей Солнцев - доклады из серии WTF {что-то} - простыми словами про тредпулы, конекшнпулы, архитектуру и кучу всего еще. Доклады про TDD, крутые воркшопы для начинающих;

Владимир Ситников - любые технические доклады про JVM мир. Один из топовых инженеров, кто регулярно делится экспертизой;

Алексей Шипилёв - самое понятное объяснение действительно сложных нюансов JVM - тут про GC, про устройство стринга под капотом и прочие виртуальные потоки;

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

Евгений Борисов - тут просто топ-1 спикер на русском про Spring, но и не только о нем есть его доклады;

Вячеслав Смирнов - любой доклад технически грамотен, выверен и интересен. Особенно запомнились доклады про JMeter, websocket;

Никита Липский - не самое простое, но интереснейшее погружение в JVM и не только;

Тагир Валеев - тот у кого вы можете бесплатно учиться Java, и автор очень интересных докладов про фичи JDK (и если лень читать релиз ноутсы), тонкости Stream API ;

Евгений Пешков - один из немногих в моем списке совсем не джавист, интересно про перформанс С# и не только;

Иван Пономарёв - очень приятно слушать, темы интересные (есть доклады про testcontainers, про Java и Kotlin)

Роман Елизаров - перед тем, как читать Java Concurrency in Practice, посмотрите его видео про теорию многопоточного программирования, и скорее всего - вы не сможете остановиться

❓Писать ли тесты на том языке, на котором сделан продукт ❓

Этот вопрос все еще иногда мелькает в обсуждениях. И даже вызывает холивары🙂

Есть три обстоятельства, которые помогают найти нам ответы на этот вопрос:

1) Мобильная автоматизация уже отменила этот выбор де-факто, апиум умрет, у него нет выбора. Поэтому тут только Kotlin и Swift, и если вы работаете или планируете работать с мобилками - уже можно и нужно приучаться к одному языку со своим проектом. Но, что если вам не нужна мобилка или вы почему-то имеете аргументы в пользу appium?

2) Рынок труда. Заколебешься искать QA auto с чем-то, кроме питона, джавы или JS/TS. Почему? Ну, а) курсы и б) джуны пишут свой первый автотест в компании синьеров, которые тоже учили питон, джаву или JS/TS. И смотрят на них. Короче, замкнутый круг, и если у нас продукт на GO, Rust или даже очень распространенных PHP и C# - то экономически и менеджерски может быть выгодно тупо писать тесты на чем-то другом. Мы так и делали в PropellerAds: сервисы на Go и что-то на PHP, тесты - на Java. Но это именно менеджерское и экономическое решение, а не потому, что питон или джава созданы всевышним для автотестов.

3) Польза для компании, улучшение dev experience, итоговое качество продукта - на мой взгляд растет, если QA и разработчики буквально общаются на одном языке. Если QA ставит свой апрув на PR разработчика и наоборот. Именно QA инженер должен влезать в код разработчика, а не разработчик "якобы поможет нам с тестами". Чуете разницу? Аргументация "выберем язык бекенда, нам помогут написать автотест" - в большинстве случаев ложная, разработчику своих дел хватает. А вот "освоим язык и платформу своего продукта что бы глубоко разобраться как он работает" - крутая аргументация, у нее только один недостаток - QA инженеру приходится не сидеть на жопе ровно с питоном или джавой, а изучать постоянно что-то новое 😁

А вы как думаете?

Опять рубрика "Баг или Фича" в IDEA:

1) Имеем JUnit Extension, который кладет в context List<CategoryJson> :

final List<CategoryJson> result = new ArrayList<>();
           context.getStore(NAMESPACE).put(
                  context.getUniqueId(),
                  result
              );

2) Имеем желание прокинуть этот List<T> через ParameterResolver в виде массива в аргументы теста:

  @Override
  public boolean supportsParameter(ParameterContext parameterContext, ExtensionContext extensionContext) throws ParameterResolutionException {
    return parameterContext.getParameter().getType().isAssignableFrom(CategoryJson[].class);
  }

  @Override
  @SuppressWarnings("unchecked")
  public CategoryJson[] resolveParameter(ParameterContext parameterContext, ExtensionContext extensionContext) throws ParameterResolutionException {
    return (CategoryJson[]) extensionContext.getStore(NAMESPACE).get(extensionContext.getUniqueId(), List.class)
        .stream()
        .toArray(CategoryJson[]::new);
  }

3) А теперь самое интересное 🙂 Этот код - работает, но IDEA его подсвечивает: Can be replaced with Collection.toArray(). Соглашаемся, и наш метод resolveParameter принимает вид:


1️⃣было :

    return (CategoryJson[]) extensionContext.getStore(NAMESPACE).get(extensionContext.getUniqueId(), List.class)
        .stream()
        .toArray(CategoryJson[]::new);

2️⃣стало :

return (CategoryJson[]) extensionContext.getStore(NAMESPACE).get(extensionContext.getUniqueId(), List.class).toArray();

И тест с таким кодом не запускается, мы имеем ошибку:

java.lang.ClassCastException: class [Ljava.lang.Object; cannot be cast to class [...model.CategoryJson; ([Ljava.lang.Object; is in module java.base of loader 'bootstrap'; [...model.CategoryJson; is in unnamed module of loader 'app')

C точки зрения моего понимания - все ок, мы действительно потеряли Method Reference CategoryJson[]::new и теперь наш массив имеет тип Object[] (хотя под капотом там на самом деле CategoryJson[] 🥲), но, потеряли-то мы его просто согласившись через ALT + ENTER с подсказкой IDEA. При этом весь контекст (в виде type casting), казалось бы, есть - ну убери просто лишний stream(), зачем убирать CategoryJson[]::new ?

Ребят, если есть пара минут, пройдите, пожалуйста, опрос от нашего ДОДО-шного QA Mobile лида, на предмет - интересно ли вам что-то поизучать по специфике Mobile тестирования, быть может, сделаем что-то крутое по итогу 🙌

Предлагаю угадать целиком заголовок слайда с одного из online занятий Дмитрия. Или тему занятия. В качестве приза - экскурсия по офису Додо (Алматы, Москва или Питер, о дате и времени договоримся) и пиво за мой счет 🍺

Итак, определить справеделивого победителя предыдущего соревнования не удалось (а на кону - экскурсия в офис ДОДО в Мск / Спб / Алматы и пиво за мой счет после этого в баре), поэтому, я написал класс Konyagi. Там все, кто отметился в комментариях. Завтра в 15-00 по московскому времени будем разыгрывать в прямом эфире 🚀

А тем временем, у нас открыта вакансия Senior Backend QA 🚀- в самый высоконагруженный и важный для бизнеса сервис - MAPI (бэкенд нашего мобильного приложения Dodo Pizza).

MAPI написан на C#, и тесты там на нем же. Там много, много интеграционных тестов на эндпойнты и бизнес-сценарии (пишут их, в основном, разработчики), полноценное и точное по профилю покрытие нагрузочными тестами (пишут и поддерживают их ребята из команды Performance QA), и ранее в MAPI никогда не было выделенной роли QA инженера.

Что хотим?

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

Рассматриваем хороших инженеров и без опыта в C#, но готовых получить этот опыт у нас. Если интересно и есть вопросы - пишите в тред или в ЛС.