QA индустрия - в кризисе.

Почему?

- Потому, что всем рассказывают как это просто - не надо уметь программировать, на это не учат в ВУЗах (по крайней мере, в РФ), а значит - это может каждый! (да - может, тут я не спорю);

- Потому, что большинство талантливых ребят, у которых хорошо получается - быстро уходят в разработку / продакты / etc, в связи с чем? См п. 1 - “как-то несерьезно быть тестировщиком, ведь это профессия для самых маленьких”. Толи дело целый разработчик! Там получается не всё и не у всех, но обратно в QA инженеры не возвращаются - гордость не позволяет;

- Низкие зарплаты. Вообще говоря, средний уровень соискателей на рынке труда в QA тоже не высокий - и тут, как бы, баланс. Но, серьезные (читай, умеющие в программирование и/или инфру, помимо крутого понимания тестирования) QA инженеры, опять таки, меняют профессию часто тупо из-за денег.

- Обратная сторона - если QA инженер понимает, что за свои год-два упорного труда начал выглядеть намного лучше большинства других тестировщиков вокруг, то хочет уже 100500 денег, потому что "ну а остальные же намного хуже? Вон какой у меня крутой код на {library name}". Совершая при этом ошибку - измеряя свой уровень относительно тех, кто заведомо слабее, а не относительно по-настоящему сильных спецов.

- Отсутствие понимания, что важно, а что нет. Мы можем годами спорить о CSS против XPATH или о том, могут быть if-чики в тестах и вокруг них, или не могут. Вместо того, чтобы за эти годы понять как работает твоя библиотека, что там за загадочная многопоточность и по каким архитектурным принципам вообще пишется софт.

- Отсутствие адекватного технического менеджмента, потому что столько сильных инженеров у нас нет, сколько нужно менеджеров. Нет их по перечисленным выше причинам. “Лидами”, “Тимлидами” становятся те, кто выделяются на общем невеселом фоне, но на этом часто техническое развитие и заканчивается, потому что приходится тупо проводить все время на созвонах;

А делать-то что?

Вот об этом тут и будем размышлять.

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

Ставьте ❤️, если будете смотреть онлайн, и остальные emoji - если хотите больше технических постов / воркшопов / докладов про JUnit 5 🚀

Вопрос на подумать перед выходными: почему 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.

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

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

Открываю шаблон вакансии - все красиво, вижу много интересного про команду, компанию, ценности, главный фокус и задачи, но совершенно пустой блок “Наши ожидания”.

Я подумал - а что, если попробовать описать ожидания без заунывного списка, типа:
- Знание и понимание Х ...
- Коммерческий опыт в Y не менее …
- Владение Z на уровне …
?

И написал такой текст:

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

Хотелось бы спросить у вас, друзья, понятно ли на уровне ощущений или еще как-то, какого же все-таки QA инженера я бы хотел найти? А может, вы и есть такой QA?

Как вы - понятно, а что делать нам?

В программе последнего Heisenbug есть 5 докладов со словами "Как мы":
- Как мы тестировали VK на Apple Watch;
- Как мы встраивали fuzzing-тестирование ... ;
- Как мы оптимизировали запуски е2е и дооптимизировались;
- Как мы автоматизировали тесты с несколькими пользователями;
- Как мы выгрузку из Greenplum в Kafka тестировали;

Для сравнения, на предыдущих, скажем, семи Heisenbug-ах (дальше уже не стал смотреть), в среднем, доклад "Как мы ..." встречается один раз на конфу (на многих вообще нуль раз, но, отличился 2022 Spring со своими 3-мя "Как мы").

А что, собственно, не так, спросите вы?

Никому, кроме ваших коллег в вашей же компании, не интересно "как вы".
Всем интересно "как это сделать мне?" Как мне сделать что-то похожее? Как мне в моей компании попробовать так же?
Но, я смотрю эти доклады в записи, и я слышу именно "Как мы". Мы написали классный инструмент (но он не опенсорс, сорян). Мы написали классную обертку над библиотекой (но показать не можем, сорян и даже объяснять, зачем ее писали, не будем). Мы имеем 100-500 слоев пирамиды тестирования и поэтому нам ок тестировать на моках.

Мы, мы, и еще раз мы.

Досадно, что на конференциях для QA все больше говорят "как мы сделали", а не "как тебе сделать".

Недавно меня спросил "в лоб" один из топов большой IT-компании - "У тебя сильная команда? Выбери из да и нет". Я на секунду задумался, потому что - мне кажется - мало кто из менеджеров оценивает силу своей команды категорически "сильная" / "не сильная". И уж точно не я. За эту секунду вспомнил огромное число технически сложных и амбициозных задач, которые мы делаем каждый день. Что-то делаю и своими руками, где-то еще пригождаются старые знания Java.

Мой ответ был - Да, у меня сильная команда.

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

Если кому-то из вас интересно следить за буднями (суровыми, трудовыми и правдивыми) нашей QA команды, приглашаю подписаться на наш канал QAжется, работает
Его ведет лидер нашего WEB-тестирования Женя Иванченко.

Сегодня стартовал созвоны 1-1 со своими ребятами по итогам Level Assessment. Это когда каждый сотрудник Dodo Engineering заполняет табличку со своими хардами (в чем продвинулся за пол года), проектами, в которых удалось принять участие и достигнуть успехов, а потом с менеджером осуществляется "калибровка" и определение итогового грейда. Грейд, само собой, привязан к з.п., ну, или наоборот 🥲. Я оцениваю часть по хардам для большинства своих ребят (QA инженеров), а по проектам - только у тех команд, для которых я прямой руководитель, владелец бюджета - команда Performance QA и Core QA team.

Что я думаю обо всем это? Ну, в Додо я впервые столкнулся со столько четко выстроенной и работающей системой, позволяющей более или менее объективно оценить рост, и понять направления, в которых надо копать дальше. Всю свою предыдущую карьеру я скорее рос по принципу "нормально делай - нормально будет", мне всегда везло с менеджерами (Игорь, Леша и, конечно, Вася - вам привет, если читаете), каждый из которых без всяких табличек и экселек по-достоинству ценил этот подход и вопросов "ну а что еще мне сделать, чтоб зарабатывать побольше" у меня лично никогда не стояло. Но, я понимаю, что не все - я 😂 Поэтому считаю LA благом.

Хочется спросить, а как вы растете, какие у вас инструменты (с т.з. взаимодействия с вашим менеджером) для этого есть?

Кстати, вот еще опрос (думаю - стоит ли писать на эту тему пост, если не актуально, то и не буду🥲)

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

Тестировщикам было бы лучше, если бы в 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), но, в конце концов, отказаться от примитивов в тестах для полей классов и рекордов - проще.

Сегодня анонсирован 4 поток моего авторского курса Advanced. Если в этом чате есть кто-то, кто думал пойти - то в скором времени я опубликую свой личный промокод на небольшую, но приятную доп. скидку. А опрос выше - мои мысли, что сделать с дипломной работой для 4 потока )

#JUnit5 #Java
ArgumentConverter - Why you are not Extension? (

Я не понимаю, почему он не является Extension-ом.
Не я один - есть issue в статусе waiting-for-interest.

Ведет он себя очень похоже на любой другой Extension;
Подключаем через @ConvertWith вместо @ExtendWith, имплементируем интерфейс с простым методом:

 public Object convert(Object o, ParameterContext parameterContext)

где Object o - Объект, что пришел к нам из датапровайдера;
возвращаемый Object - любой объект, который мы можем “создать” базируясь на полученном Object o, ну или прямо его и вернуть.

Так вот, о чем я тут думаю? Что, если у нас есть enum с типами юзеров (допустим, “админ” и “просто” юзер) и мы хотим написать параметризованный тест против них, который
1) создаст юзера с полученным типом перед тестом;
2) и сделает что-то с ними после теста? (условно, в AfterEachCallback);

Начнем c энама:

enum UserType {
   ADMIN("insert into ‘user’ (type...) values (admin...)"),
   COMMON("insert into ‘user’ (type...) values (common...)");
   public final String sql;
}

Напишем тест:

@EnumSource(UserType.class)
@ParameterizedTest
void usersParameterizedTest(@ConvertWith(UserCreator.class) User createdUser) {
}

И ArgumentConverter для него:

class UserCreator implements ArgumentConverter {
   @Override
   public Object convert(Object o, ParameterContext parameterContext) throws ArgumentConversionException {
       ResultSet result = executeScript(((UserType) o).sql); // create user
       if (result.next()) {
           return new User(result.getString("username"), (UserType) o);
       } else throw new IllegalStateException();
   }
}

Пока все логично? По-моему, вполне.

Осталось решить вопрос - а можем ли мы что-то сделать после теста с этими юзерами (удалить из БД - просто как пример)?

В Extensions такой вопрос просто бы не стоял - мы бы сохранили этих юзеров в ExtensionContext, а ключом был бы test-case-id (допустим, аннотация @AllureId над тестом), и имели бы доступ к ним в любых других Экстеншенах - в AfterEachCallback для нашей задачи.

Но, у нас нет ExtensionContext внутри ArgumentConverter! 🫤

Надо городить какие-то свои “ТестКонтексты” в которые это сохранять, и вытаскивать оттуда. Но это не красиво и странно, потому что вы явно в других местах привыкнете использовать ExtensionContext.

В действительности, я не вижу ни одной технической причины отсутствия ExtensionContext для ArgumentConverter (и до кучи и в ArgumentAggregator), а пока их там нет - предлагаю написать свой маленький дополнительный экстеншн, который дает нам возможность использовать ExtensionContext где угодно.

Ну, и пойдемте, что-ли, напишем ребятам из JUnit, что было бы здорово, наконец, сделать их Extension-ом? Issue в начале поста🙌

Друзья, подъехал мой персональный промокод на 4-й поток Advanced курса автоматизации тестирования на Java.
Он дает скидку 5%, которая суммируется с остальными скидками на сайте –
DTUCHSPROMO5

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