LikeaDuck🦆

Тестировщикам было бы лучше, если бы в Java не было вовсе примитивных типов данных. Уверен, что большинство из моих читателей помнят про них. Но в чем ценность этих примитивов в QA автоматизации? Кто-то скажет, что это все должно работать быстрее, потому, что есть какой-то стек и куча, и первый вроде бы быстрый, и примитивы вроде бы в нем живут. В действительности это так, но только для аргументов методов и локальных переменных в методах, но ни в коем случае не для полей объектов. Я далек от мысли, что это может оказать хоть какое-нибудь реальное влияние на скорость наших тестов. А вот кое что с примитивами по-настоящему плохо для тестировщика. Это значения по умолчанию для полей классов (class fields). Представим себе endpoint, который отдает нам json примерно такого содержания:

{"username":”dima”, “attemptsCount” : 0}

И представим тест, который проверяет бизнес-логику того, что у какого-то там пользователя действительно ноль попыток:

@Test
void apiTest() {
 Response resp = apiClient.request();
 Assertions.assertEquals(0, resp.attemptsCount());
}

* где

Response

классический data-класс с приватными полями, геттерами и сеттерами Что будет, если наш бэкенд случайно вообще перестает возвращать нам attemptsCount в респонсе? А будет вот что: И Jackson, и Gson по умолчанию прекрасно десериализуют {"username":”dima”} в объект java класса с двумя полями

private String username;
private int attemptsCount;

И в attemmptsCount вам просто будет подставлен 0 - потому, что так работают примитивы, у них есть значения по-умолчанию, и для int это - ноль. Тест просто останется зеленым. Что интересно, в Java с недавней поры есть record-ы которые дают строгий immutable объект с all-arg конструктором, а все поля - финальные. Но и тут нас ждет сюрприз - и Jackson, и Gson создаст инстанс record-а cо значением 0 по умолчанию! Вот этого ожидать вообще не приходится - сеттеров-то нет, а конструктор ждет 2-х аргументов. Но это факт. Если заменить int в нашем классе или record на Integer - то наш тест сразу и надежно начнет падать, т.к. null уж точно не равен нулю. Да, я знаю, что заставить тест падать можно и настройкой ObjectMapper (или Gson) при его создании или аннотациями наподобие @JsonProperty(required = true), но, в конце концов, отказаться от примитивов в тестах для полей классов и рекордов - проще.

Что меня мотивирует вести лекции по ночам (а делаю я это с 23 до 1 ночи)? Вот что

Кстати, вот еще опрос (думаю - стоит ли писать на эту тему пост, если не актуально, то и не буду🥲) - Есть кто-то, кто прям по-настоящему пишет автотесты на Java для SOAP веб-сервисов? И если да, то что вы используете для генерации тела сообщения (body) и всего сообщения (envelope)? Изначально вам, конечно, доступен wsdl тестируемого сервиса.

Сегодня стартовал созвоны 1-1 со своими ребятами по итогам Level Assessment. Это когда каждый сотрудник Dodo Engineering заполняет табличку со своими хардами (в чем продвинулся за пол года), проектами, в которых удалось принять участие и достигнуть успехов, а потом с менеджером осуществляется "калибровка" и определение итогового грейда. Грейд, само собой, привязан к з.п., ну, или наоборот 🥲. Я оцениваю часть по хардам для большинства своих ребят (QA инженеров), а по проектам - только у тех команд, для которых я прямой руководитель, владелец бюджета - команда Performance QA и Core QA team. Что я думаю обо всем это? Ну, в Додо я впервые столкнулся со столько четко выстроенной и работающей системой, позволяющей более или менее объективно оценить рост, и понять направления, в которых надо копать дальше. Всю свою предыдущую карьеру я скорее рос по принципу "нормально делай - нормально будет", мне всегда везло с менеджерами (Игорь, Леша и, конечно, Вася - вам привет, если читаете), каждый из которых без всяких табличек и экселек по-достоинству ценил этот подход и вопросов "ну а что еще мне сделать, чтоб зарабатывать побольше" у меня лично никогда не стояло. Но, я понимаю, что не все - я 😂 Поэтому считаю LA благом. Хочется спросить, а как вы растете, какие у вас инструменты (с т.з. взаимодействия с вашим менеджером) для этого есть?

Недавно меня спросил "в лоб" один из топов большой IT-компании - "У тебя сильная команда? Выбери из да и нет". Я на секунду задумался, потому что - мне кажется - мало кто из менеджеров оценивает силу своей команды категорически "сильная" / "не сильная". И уж точно не я. За эту секунду вспомнил огромное число технически сложных и амбициозных задач, которые мы делаем каждый день. Что-то делаю и своими руками, где-то еще пригождаются старые знания Java. Мой ответ был - Да, у меня сильная команда. У нас, в QA функции DODO, действительно, не мало старых проблем. Неоднозначных технических решений хватает. Система и подходы к тестированию выстраивались давно и там есть что менять. Ошибкой будет думать "Ну, раз там Дима Тучс, значит технически все отлично, все архитектурно красиво, ведь кажется Дима в этом что-то понимает". Нет, мы не идеальны и пока даже не рядом. Нет, у нас все еще мало образцовых тестов, на которых можно было бы учиться лучшим практикам (хотя, они есть). И все же, мы - сильная команда из 27 человек, перед которой сейчас стоят самые большие технические вызовы, которые когда-либо стояли перед QA-функцией DODO. Не сделать "какую-то автоматизацию". Надо сделать по-настоящему круто. Я уверен, мы сделаем. Если кому-то из вас интересно следить за буднями (суровыми, трудовыми и правдивыми) нашей QA команды, приглашаю подписаться на наш канал QAжется, работает Его ведет лидер нашего WEB-тестирования Женя Иванченко.

Как вы - понятно, а что делать нам? В программе последнего Heisenbug есть 5 докладов со словами "Как мы": - Как мы тестировали VK на Apple Watch; - Как мы встраивали fuzzing-тестирование ... ; - Как мы оптимизировали запуски е2е и дооптимизировались; - Как мы автоматизировали тесты с несколькими пользователями; - Как мы выгрузку из Greenplum в Kafka тестировали; Для сравнения, на предыдущих, скажем, семи Heisenbug-ах (дальше уже не стал смотреть), в среднем, доклад "Как мы ..." встречается один раз на конфу (на многих вообще нуль раз, но, отличился 2022 Spring со своими 3-мя "Как мы"). А что, собственно, не так, спросите вы? Никому, кроме ваших коллег в вашей же компании, не интересно "как вы". Всем интересно "как это сделать мне?" Как мне сделать что-то похожее? Как мне в моей компании попробовать так же? Но, я смотрю эти доклады в записи, и я слышу именно "Как мы". Мы написали классный инструмент (но он не опенсорс, сорян). Мы написали классную обертку над библиотекой (но показать не можем, сорян и даже объяснять, зачем ее писали, не будем). Мы имеем 100-500 слоев пирамиды тестирования и поэтому нам ок тестировать на моках. Мы, мы, и еще раз мы. Досадно, что на конференциях для QA все больше говорят "как мы сделали", а не "как тебе сделать".

Cообщение в slack*:

Мы в юните сейчас будем открывать вакансию на QA в команду К9, давай с тобой засинхроним ожидания от кандидатов? Есть вот такой шаблон вакансии, можешь сюда добавить тех. требования, пожалуйста? 

Открываю шаблон вакансии - все красиво, вижу много интересного про команду, компанию, ценности, главный фокус и задачи, но совершенно пустой блок “Наши ожидания”. Я подумал - а что, если попробовать описать ожидания без заунывного списка, типа: - Знание и понимание Х ... - Коммерческий опыт в Y не менее … - Владение Z на уровне … ? И написал такой текст: Наши ожидания В первую очередь, как бы странно это не звучало - мы бы очень хотели, чтобы ты радовался(ась) и считал(а) своим самым важным результатом нахождение интересных, разнообразных и нетривиальных багов. Безусловно, тут будет много ручной работы (редизайн тяжело будет тестировать сходу автотестами), но вакансия не чисто о ручном тестировании; Для нас самый крутой QA инженер - тот, который(ая) докажет нам, что продукт не работает, а не тот, который(ая) скажет “я все проверил(а), прошел(а) необходимые чек-листы и наборы кейсов, можно релизить, замечаний нет”. Мы глубоко убеждены, что у нас (как и в любом большом продукте) всегда есть много багов, и мы счастливы каждому новому багу в нашем багтрекере, а не их отсутствию и фразе “я все проверил(а), все работает”; Автоматизация. Куда же без нее! В целом, у нас уже везде настроен CI/CD с автоматическим регрессом: прогоняются unit и e2e тесты. Тесты, как и продуктовый код, пишем на Swift или Kotlin. В UI-тестах используем нативные фреймворки. Для нас является обязательным условием твоя готовность писать автотесты под одну из платформ, у нас для этого большой бэклог на автоматизацию, множество задач по рефакторингу существующих тестов, и главное - убежденность, что команда (и QA этой команды) несет полную ответственность за автоматизацию тех фич, которые мы делаем; Во время знакомства мы не будем спрашивать про ScreenObject и селекторы, а вместо этого посмотрим на какой-то наш реальный код тестов на Swift или Kotlin (по твоему усмотрению) и пообсуждаем, что тебе в нем нравится, что нет, что бы ты реализовал(а) по-другому и так далее. Будем обсуждать код, а не теоретические знания 🙂 Резюмируя, пункты 1 и 2 подразумевают, что ты классный(ая) QA, а пункт 3 - что ты знаешь, понимаешь и практически используешь автоматизацию тестирования чего-либо (не обязательно мобилки). _________ Хотелось бы спросить у вас, друзья, понятно ли на уровне ощущений или еще как-то, какого же все-таки QA инженера я бы хотел найти? А может, вы и есть такой QA?

Вопрос на подумать перед выходными: почему java-автоматизаторы боятся JPA (Hibernate)? Ну, на первый взгляд, причины тут очевидны: Только лишь спецификация JPA в виде PDF содержит 662 страницы сухого текста, и даже просто загуглить ее уже проблема - запрос “JPA Specification” не дает нужной ссылки на первой странице, надо искать “Jakarta Persistence”. Конечно, никто ее не читает (в том числе и я🥲). А если уж на вашем проекте используется JPA (ну, или Spring Data JPA), то вся эта магия там работает с использованием аннотаций @PeristenceContext, @PersistenceUnit или @Autowired в случае Спринга. А в тестах у нас этих аннотаций нет; Так же у нас нет Transaction-manager-a (и сколько вообще можно этих умных слов?!1) Последний гвоздь в крышку гроба JPA в тестах забивают Entity-классы - с SQL мы все умеем работать со своего QA-джуниорства, а что там эти ваши @OneToMany(mappedBy = "friend", fetch = FetchType.EAGER, cascade = CascadeType.ALL, orphanRemoval = true) означают - кто-ж его знает без чтения тех самых 662 страниц😁 Однако, я убежден, что для большинства типичных задач для работы с БД из тестов - JPA - лучшее и ВНЕЗАПНО самое простое решение. Entity-классы можно взять у ваших же разработчиков, а если проект, условно, на PHP (у меня так было), то сгенерить в IDEA; C equals() и hashCode() на момент написания этого поста окончательно разобрались ребята из jpa-buddy; Вместо полной спецификации JPA для 90% задач будет достаточно того, что описано со 137 по 162 страницы книги “Изучаем Java EE 7”, автор Э. Гонсалвес. Глава имеет говорящее название “Java Persistence API”🙌 Вместо аннотаций @PeristenceContext, @PersistenceUnit или @Autowired надо будет написать 3 (три) класса и один файл persistence.xml с типичной (copy-paste) структурой. Что это за 3 класса, я рассказывал в своем докладе Уберите из своего резюме «разработка QA-фреймворка» Ну, или можно просто взглянуть на них: 1, 2 и 3. А еще, я рассказываю обо все этом на своем авторском курсе qa.guru Advanced.

Фух, выдохнул. Доклад, мне кажется, получился удачным, я б даже сам пересмотрел😁 Теперь хочется немного отдохнуть от JUnit-a (хотя, кого я обманываю, завтра в 22-00 лекция по расписанию 🥲). А ещё мы второй день в DODO🏠 осваиваем новую для нас позицию QA Tech Lead - он появился у нас в Performance QA Team, а я меж тем хочу, чтобы их было трое к концу года. А вы встречали позицию QA Tech Lead (технический архитектор и менеджер небольшой команды в одном лице)? И если встречали (или, вы сами - он), то го обсуждать, где обитают эти фантастические ... спецы

Небольшое затишье, и у него есть причина - готовлюсь к докладу на Heisenbug Autumn. Точнее, это будет воркшоп, где мы будем писать Extension-ы, говорить про ExtensionContext, ThreadLocal и, в конце концов, создадим максимально простое и рабочее решение интеграции тестов с Oauth 2 code-flow. Бонусом - имплементируем 2 способа создания preconditions для тестов (глобально для тестрана и индивидуально для теста). Ставьте ❤️, если будете смотреть онлайн, и остальные emoji - если хотите больше технических постов / воркшопов / докладов про JUnit 5 🚀

QA индустрия - в кризисе. Почему? - Потому, что всем рассказывают как это просто - не надо уметь программировать, на это не учат в ВУЗах (по крайней мере, в РФ), а значит - это может каждый! (да - может, тут я не спорю); - Потому, что большинство талантливых ребят, у которых хорошо получается - быстро уходят в разработку / продакты / etc, в связи с чем? См п. 1 - “как-то несерьезно быть тестировщиком, ведь это профессия для самых маленьких”. Толи дело целый разработчик! Там получается не всё и не у всех, но обратно в QA инженеры не возвращаются - гордость не позволяет; - Низкие зарплаты. Вообще говоря, средний уровень соискателей на рынке труда в QA тоже не высокий - и тут, как бы, баланс. Но, серьезные (читай, умеющие в программирование и/или инфру, помимо крутого понимания тестирования) QA инженеры, опять таки, меняют профессию часто тупо из-за денег. - Обратная сторона - если QA инженер понимает, что за свои год-два упорного труда начал выглядеть намного лучше большинства других тестировщиков вокруг, то хочет уже 100500 денег, потому что "ну а остальные же намного хуже? Вон какой у меня крутой код на {library name}". Совершая при этом ошибку - измеряя свой уровень относительно тех, кто заведомо слабее, а не относительно по-настоящему сильных спецов. - Отсутствие понимания, что важно, а что нет. Мы можем годами спорить о CSS против XPATH или о том, могут быть if-чики в тестах и вокруг них, или не могут. Вместо того, чтобы за эти годы понять как работает твоя библиотека, что там за загадочная многопоточность и по каким архитектурным принципам вообще пишется софт. - Отсутствие адекватного технического менеджмента, потому что столько сильных инженеров у нас нет, сколько нужно менеджеров. Нет их по перечисленным выше причинам. “Лидами”, “Тимлидами” становятся те, кто выделяются на общем невеселом фоне, но на этом часто техническое развитие и заканчивается, потому что приходится тупо проводить все время на созвонах; А делать-то что? Вот об этом тут и будем размышлять.