Подъехали первые полезные инсайды (не побоюсь этого слова) со стратсессии от нашего СТО Паши Притчина. Must see!

Сегодня Dodo стратсессия - всё. 4 дня плотного брэйншторминга позади. 2024 обещает быть интересным, QA будем усиливать крутанами, делать крутанские тесты, отвязываться от приемочного тестирования... Но обо всем по-порядку, получится или нет все задуманное - буду писать сюда. Stay tuned 🍿

А, да и ещё нужен спец по куберу/кафке/джаве/графанам-прометеям-егерям в мою команду QA Performance. У команды недавно появился топовый техлид, будет супер-интересно. Вакансия будет открыта скоро.
По деньгам будет норм, а написать можно мне в лс)

#books #learning #Java

Тут недавно мой друг, коллега по QA-хэдству, крутой спец по автоматизации на Java, с которым мы несколько лет бок о бок работали на многих проектах (PropellerAds, Simscale и не только) - Миша Сидельников - написал книгу Let's Automate IT.

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

А на фото я, Миша и сами знаете кто в офисе Codeborne. Знаете же? 🙂

#maven #java

А еще я сегодня впервые в жизни словил какую-то неведомую хрень, добавив зависимость в pom.xml и нажав кнопку "скачать зависимости". Еще раз. Я начинал с Java 1.6 в 2009 году. Я доработал до Java 21 и 2023 года. И впервые словил по-настоящему неведомую ошибку с мавеном! Сегодня день, когда maven для меня стал похож на gradle - ведь там неведомые ошибки возникают в каждом втором проекте 🥲 Надеюсь, следующий такой день будет еще через 14 лет.

#regression #testing #manual

Важный вопрос - если мы находим баг на регрессе - надо ли проверить, был ли он в предыдущей версии, которая на проде? Я считаю, что это первое, что необходимо проверить. Если баг был (а может и в пред-предыдущей версии, а может он там уже годами) - то это информация, которая говорит нам о том, что что-то не так с тестированием. Мы пропускали этот баг как минимум 1 раз (а может 101 раз). Надо написать на это тест. Может, это закрывается банальным юнит-тестом на три строки, может нужен e-2-e. А может просто нужен ручной тест-кейс, и не забывать его проверить на следующем регрессе. Может нужна галочка в чеклисте. Но энивэй - мы понимаем, что это свидетельство недостаточной надежности нашего релизного пайплайна.

Если же баг "новый" (то есть, его не было в предыдущей версии, мы его только занесли) - то у нас что-то не так с разработкой, мы плохо подумали об AC и DoD, может банально невнимательно написали код, что-то не учли. Да, тут тоже в итоге должен появиться тест или тест-кейс, но такой баг должен радовать QA инженера, который его нашел, а вот "старый" - должен огорчать.

У нас в DODO не везде есть практика разделения таких багов на "новый"/"старый", где-то баг - это просто "ща пофиксим и поедем в прод", никаких выводов из них не делается.

Я хочу это изменить.

А вы что думаете?

Ребята, не пропустите топовый контент завтра в рамках открытых занятий QA.GURU. Этот тот случай, когда другого такого эксперта, говорящего на русском языке, вы не найдете даже при большом желании🙂. Ну и подписывайтесь на Мишин канал, конечно же!

#java #automation

Хозяке java-автоматизаторам на заметку:

Периодически вижу подобные вопросы (и подобный код) тут и там:

Схема ответа:

{
  "users": [ 0 ],
  "groups": [ 0 ]
}

И класс для его маппинга

@Data
@AllArgsConstructor
@NoArgsConstructor
@Builder
@JsonIgnoreProperties(ignoreUnknown = true)
public class UserDataRegisterModel {
    private Integer type;
    private String name;
    private String data;
    private List<Integer> users;
    private List<Integer> groups;
}

Я не могу найти ни одной причины “модельным” классам (точнее, объектам) не быть immutable, уж во всяком случае, в тестах.

А начиная с Java 16 у нас есть ключевое слово record (на самом деле уже с 14, но там это была preview feature). Если вы его еще совсем не использовали, то о том, что это такое, советую послушать Тагира Валеева.

Тот же самый класс без всякого Lombok может выглядеть так:

public record UserDataRegisterModel (
   Integer type,
   String name,
   String data,
   List<Integer> users,
   List<Integer> groups
) {}

Да, иногда можно придумать (хотя, в действительности, с трудом) поводы менять состояние объекта, но для этого мы вправе написать метод внутри нашего рекорда:

public UserDataRegisterModel addType(int type) {
   return new UserDataRegisterModel(type, name, data, users, groups);
}

И пользоваться новым объектом. Ну, все как в любимом нами иммутабельном классе String.

Собственно, в учебном проекте моего курса qa.guru advanced все модели как на бэкендах, так и в тестах существуют в виде record. Чего и вам всем желаю и рекомендую. Вы же не на java 8? Selenide вот требует 17 🙂

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

#bugs #testing

Мы посчитали, что из заведенных саппортом багов за год пофиксили всего около 12%. Выглядит как жуткий перекос в бизнес-фичи и бесконечное разрастание баговых беклогов. Понятно, что оставшиеся 88% не блокеры, но, блин🥲 У кого как? Вы считаете такую метрику на стыке с кастомер саппортом?

#automation #этоневажно

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

Сегодня рассмотрим классику - PageObject (тут и далее как обычно все на Java).

Что важно для PageObject?

1) PageObject объект должен создаваться максимально просто - читай, через new (безо всяких PageObjectFactory)
2) Он должен быть immutable и никогда не иметь никакого shared mutable state - читай, все поля final , а static - только для immutable констант
3) Он должен использовать композицию, а не наследование для расширения функциональности (то есть, если у нас есть LoginPage с двумя полями логин и пароль, и RegistrationPage с тремя полями - логин, пароль, повторипароль, то мы не делаем RegistrationPage extends LoginPage). Вообще, наследование почти никогда не нужно в тестах на самом деле.

Все остальное, что я годами читаю в умных чатах по автоматизации, да и на code-review - не важно. Примеры:

- Стэпы должны быть в отдельном классе! Или наоборот - стэпы должны быть только в PageObject! - это вообще не имеет никакого значения, лишь бы было где-то прописано прямо в ридми. Никакой технической разницы нет, разве что вам приятно писать больше отдельных step-классов;

- Селектор должен быть CSS ! или XPATH!. Селектор вообще никому ничего не должен. В реальной жизни к нему только одно требование - селектор не должен быть всратым. Но это не зависит от того CSS он или XPATH

- Методы должны возвращать this! Или не должны! Или должны, но не всегда! - это не влияет никак ни на скорость написания тестов, ни на поддерживаемость, ни ну удобство рефакторинга.

- При композиции ты должен дублировать все методы вложенного объекта / Ты должен просто написать геттер! - можно и так и так

- Ассертов в пэйдж обжекте быть не должно - встречал и такое 🥲

- Имена полей должны начинаться со слова element! Или заканчиваться им!

и т.д. и т.п.

Обращайте внимание только на то, что действительно (технически) важно: иммутабельность, простота инициализации, композиция вместо наследования.

UPDATE от iLesnykh:

Бизнесу так-то вообще на весь код плевать, главное чтоб работало и деньги приносило. Но это же не делает код или то, какой он, неважным.

Думаю нет понятия "не важно". Важно всё, что важно команде. Просто есть разные приоритеты. Тут как в жизни: есть базовые потребности (допустим, Дима их описал выше – иммутабельность, композиция, инициализация) – и если самое важное покрыто, то мы начинаем искать смысл в менее важном (типа еда и жильё есть, next step – а какой бренд сумочки или сколько высота потолков). И это тоже своего рода важно, просто не важнее первого и не в ущерб балансу скорость/качество.

Ребят, а вдруг есть среди моих подписчиков кто-то, кто хотел бы поработать QA на стыке с бизнесом, то есть, автотестов особо писать не надо (можно и не уметь), а вот погрузиться в бизнес, понять как работают додо-курьеры, какие там проблемы и особенности, хотел бы?

Мы запускаем амбициозный проект переделки бизнесфлоу доставки нашей пиццы под кодовым названием "курьер-на-город". Там нужен qa , уровень middle+ и выше. Повторюсь - вакансия не про тесты пописать, а про погрузиться в бизнес, мыслить как курьер (и заказчик пиццы) и находить проблемы именно, в первую очередь, в недодуманных бизнес-сценариях.

Если кто-то заинтересован, напишите пожалуйста мне в ЛС или в комменты к посту. Созвонимся, все расскажу.

Интересный контент должен подъехать на следующей неделе - буду за круглым столом обсуждать обучение QA😈. Свою первую школу автоматизации внутри PropellerAds организовал 4 года назад, ещё до прихода в qa.guru. Мне определенно есть, что сказать )

Кстати, мы еще делаем небольшой QA митап в Москве - но, без моего присутсвия😔. 12 декабря в офисе Dodo Brands в Москве.

За меня там будет лидер гильдии Web QA Женя Иванченко.

В программе разговор о том, как командам быстрее передавать фичи бизнесу и писать эффективные ассерты в интеграционных тестах. Приходите, будет интересно! Ну и офис наш, в предновогоднюю пору, крутой 💔

Участвовать можно онлайн или оффлайн (пиццу есть точно удобнее оффлайн), регистрация по ссылке до 10 декабря 👉🏻 https://qa-dodo-spb.timepad.ru/event/2670046/

А почему не будет меня? Мы устраиваем съезд лидеров QA направлений DODO в Алмате ровно в эти же даты. Будем вживую прожаривать OKR-ы, родмапы и вот это все на 2024 год.

#Java #gradle #automation

Вчера один из моих студентов задал вопрос -

Добрый день! Кто может подсказать какой JDK 17 версии нужно поставить чтобы не было конфликтов и можно было использовать selenide 7? Если выбираю JDK 17 версии , то ловлю ошибку "Could not initialize class org.codehaus.groovy.reflection.ReflectionCache"

Ну и скрин с этой ошибкой.

Опыт не пропьешь - я сразу сказал, что, видимо, gradle в проекте / системе не той версии, которая нужна для Java 17 (это версии 7.6 и выше). Студент стал разбираться и - конец немного предсказуем - дело было действительно в старой версии gradle (6.7). Обновили и все заработало.

И тут у меня один вопрос - неужели невозможно, если уж вы делаете разбивки по версиям, которые совместимы с той или иной JDK, неужели совсем невозможно вывести понятное сообщение об ошибке - "Дружище, у тебя несовместимые версии". Как новичок должен разбираться в

Could not initialize class org.codehaus.groovy.reflection.ReflectionCache

?
У меня нет ответа.

#этоневажно

Об ачивке, формулировке, должности - SDET.
Что это такое? Что он должен уметь из того, что не должен уметь QA Automation Engineer?

Я глубоко убежден что эту формулировку придумали из двух соображений:

1) Потешить свое ЧСВ. Уж больно не охота называться "всего лишь QA". Как бы стоять в одном ряду с джуниором, закончившим курсы и прочитавшим пару книг. А я, мол, целый SDET, знаю про докер, CI/CD умею, написал свой собственный фреймворк для отправки HTTP запросов и обернул методы селенида / плэйрайта кучей своих очень необходимых оберток! Я не просто "QA" - который умеет написать тест из шагов, я целый SDET!

Это примерно как если бы условный fronted developer с какого-то момента начал называть себя Software Engineer In Browser. SEIB. Что я не просто там верстаю и джсоны парсить умею, я ого-го. Не правда ли звучит потешно - придумывать понтовую доллжность? Но SDET-ы, конечно, считают что это звучит гордо. Что им, наверное, за это надо платить больше, или что их больше зауважают "настоящие разработчики и инженеры"🙂

2) И второй аргумент - я не хочу ручного тестирования, я только пишу код. Этот аргумент тоже не выдерживает критики, т.к. любой код написанный кем либо - он не висит в воздухе. Вокруг него всегда есть что-то до и после. И если для написания теста (зафиксировать поведение системы) надо проверить что это поведение вообще соответствует ожидаемому руками - это не "стремно", а нужно. Если для написания теста надо разобраться, как поднять тестируемую систему в docker-compose и положить в нее тестовые данные - это просто надо уметь и мочь сделать.

Совершенно не важно, впишите вы себе в резюме эти 4 буквы или нет. Важно то - понимаете ли вы своя ЯП, понимаете ли вы - что такое DevOps практики, умеете вы сами работать с инфрой, скриптами на CI/CD, умеете ли вы сами поработать с обсервабилити, а не тупо смотреть на графики в графане, которые сделал кто-то до вас. Разберетесь вы с проблемами в вашем докере, или нет. Сможете ли принести Pull-Request в Аллюр, Селенид или любой другой опенсорс, когда найдете там баг. Сможете собрать свой образ браузера для Selenoid или понять, что не так с конфигом nginx, почему вы вдруг получаете ConnectionRefused. Сможете ли вы не писать свои фреймворки, а сделать так просто, как только можно. Сможете ли сделать простой DSL создания тестовых данных, будь то json или аннотации/декораторы над тестом. Это все умения Senior QA Automation - а 4 буковки еще ни разу не смогли мне объяснить - почему их надо величать именно так, а не иначе.

Не стремитесь повесить на себя такую ачивку, у самых крутых экспертов в их линкединах и резюме зачастую написано просто "QA", эксперта красят не 4 буквы SDET.

Маленькая новость выходного дня.

Сам забыл (и вспомнил благодаря рассылке в чате qa.guru), что сегодня последний день общедоступной скидки 10% на мой курс Advanced, которая прекрасно суммируется с моим промокодом. Итого, 15% скидка на курс, который я стартую уже в эту среду, 21 декабря. Залетайте смотреть кодовую базу, смотрите тесты, экстеншены и все-все все в репо. Именно этому будем три месяца учиться онлайн на лекциях со мной (в основном) и не только🚀. Кому интересно - welcome aboard!

А еще мы уже пишем учебное IOS приложение Niffler, заканчиваем с фигмой редизайна, и планируем писать Android приложение. Stay tuned!