#Testing #Management #Bugs
Пятничное: зачем вам (или вашему менеджеру) считать число багов?
У нас в DODO🍕 есть несколько команд, которые пилят приложение Dodo Pizza. Я даже затрудняюсь назвать точное число - но оно всегда где-то между 5 и 7. У каждой из них свой PO, свой QA, и свой бэклог с досочкой в тасктрекере. Какая-то команда работает над "лояльностью" (это кэшбеки, промоакции и т.д. в приложении), какая-то работает над меню, какая-то над всем что касается геолокации и адресной системы и так далее.
От чего тут грустно мне?
Я не знаю на какой из множества досок посмотреть, а что у нас с багами? Мы их находим? Мы их фиксируем? Мы о них знаем? Существуют дубли одних и тех же багов на разных досках. Есть еще огромная доска "баги из саппорта", и где и в чем она пересекается с командными - тоже очень расплывчатая материя.
А я хотел бы хорошо понимать, сколько и каких багов мы (QA) находим.
Зачем?
Я часто слышу мнение - "Это ужасно неправильно считать баги и мерять эффективность QA багами"!
Я же думаю, что это так же странно, как говорить что разработчика нельзя мерить числом закрытых задач и пулл-реквестов. Можно и нужно. Как с багами, так и с PR-ми разработчиков имеет значение их вес, их суть. И дело не в том, что если у Васи число "42" а у Пети число "23", то, Вася в 2 раза лучше. Может, вес 23-х багов (PR-ов) выше, чем тех 42-х. Но эти 2 цифры - в любом случае объективная информация, которую можно анализировать.
А вот расплывчатое "я работаю над культурой и процессом, я не какой-то там багхантер" анализировать много сложнее. Часто за этим, к сожалению, скрывается вовсе отсутствие пользы для бизнеса.
Итак, я предлагаю пристально обратить внимание на метрику DRE
Выражается она простой формулой:
Простой пример: я нашел десяток багов в приложении Dodo Pizza у себя на телефоне;
Если мы при этом перед релизом нашли 100 других багов, то наше качество
А если мы перед релизом нашли 20 других багов, то наше качество
А если мы вообще не нашли багов у себя, то
За этот коэффициент можно и нужно бороться, и тут даже не имеет никакого значения, что у вас с автоматизацией, Ci/CD и прочим.
Давайте радоваться каждому новому багу, найденому нами (а не пользователями) и считать их. А в DODO я рано или поздно добьюсь появления единого, а не распределенного источника правды о багах наших продуктов.
Пятничное: зачем вам (или вашему менеджеру) считать число багов?
У нас в DODO
От чего тут грустно мне?
Я не знаю на какой из множества досок посмотреть, а что у нас с багами? Мы их находим? Мы их фиксируем? Мы о них знаем? Существуют дубли одних и тех же багов на разных досках. Есть еще огромная доска "баги из саппорта", и где и в чем она пересекается с командными - тоже очень расплывчатая материя.
А я хотел бы хорошо понимать, сколько и каких багов мы (QA) находим.
Зачем?
Я часто слышу мнение - "Это ужасно неправильно считать баги и мерять эффективность QA багами"!
Я же думаю, что это так же странно, как говорить что разработчика нельзя мерить числом закрытых задач и пулл-реквестов. Можно и нужно. Как с багами, так и с PR-ми разработчиков имеет значение их вес, их суть. И дело не в том, что если у Васи число "42" а у Пети число "23", то, Вася в 2 раза лучше. Может, вес 23-х багов (PR-ов) выше, чем тех 42-х. Но эти 2 цифры - в любом случае объективная информация, которую можно анализировать.
А вот расплывчатое "я работаю над культурой и процессом, я не какой-то там багхантер" анализировать много сложнее. Часто за этим, к сожалению, скрывается вовсе отсутствие пользы для бизнеса.
Итак, я предлагаю пристально обратить внимание на метрику DRE
Выражается она простой формулой:
(Баги найденные командой) / (Баги найденные командой + Баги найденные пользователями).
Простой пример: я нашел десяток багов в приложении Dodo Pizza у себя на телефоне;
Если мы при этом перед релизом нашли 100 других багов, то наше качество
100/(100+10) = 0.9;А если мы перед релизом нашли 20 других багов, то наше качество
20/(20+10) = 0.66;А если мы вообще не нашли багов у себя, то
0/10 🥲За этот коэффициент можно и нужно бороться, и тут даже не имеет никакого значения, что у вас с автоматизацией, Ci/CD и прочим.
Давайте радоваться каждому новому багу, найденому нами (а не пользователями) и считать их. А в DODO я рано или поздно добьюсь появления единого, а не распределенного источника правды о багах наших продуктов.
Please open Telegram to view this post
VIEW IN TELEGRAM
Testsigma Agentic Test Automation Tool
Defect Removal Efficiency: How To Calculate It For Test Automation
Learn what defect removal efficiency is and how to effectively calculate it for your test automation workflow, read now!
🔥31👾4❤2👍1
И я здесь. Будем сратегировать, в том числе, что же такое хороший QA. Попозже расскажу
❤6👍2
Forwarded from Стартап Продюсер⚡️
На этой неделе большая стратсессия IT Dodo Brands. Что важно — в оффлайне.
Широкий состав, единый контекст, дизрапт по всем направлениям.
В общем, делаем контент
Широкий состав, единый контекст, дизрапт по всем направлениям.
В общем, делаем контент
😁16
CFR. Он же - Сhange failure rate. Сколько процентов релизов от общего пришлось откатить и/или хотфиксить. Критически важен в мобильной разработке, с учетом специфики (долгая доставка хотфиксов до пользователей, невозможность принудительно заставить обновить аппку). Вопрос больше к Mobile QA / Mobile Developer в этом чате - а вы знаете, какой у вас CFR? Go обмениваться процентиками в комментах. Спойлер - у нас не очень.
🔥5
This media is not supported in your browser
VIEW IN TELEGRAM
Подъехали первые полезные инсайды (не побоюсь этого слова) со стратсессии от нашего СТО Паши Притчина. Must see!
😁37✍11🔥3👏3🤓3🤩2
Сегодня Dodo стратсессия - всё. 4 дня плотного брэйншторминга позади. 2024 обещает быть интересным, QA будем усиливать крутанами, делать крутанские тесты, отвязываться от приемочного тестирования... Но обо всем по-порядку, получится или нет все задуманное - буду писать сюда. Stay tuned 🍿
А, да и ещё нужен спец по куберу/кафке/джаве/графанам-прометеям-егерям в мою команду QA Performance. У команды недавно появился топовый техлид, будет супер-интересно. Вакансия будет открыта скоро.
По деньгам будет норм, а написать можно мне в лс)
А, да и ещё нужен спец по куберу/кафке/джаве/графанам-прометеям-егерям в мою команду QA Performance. У команды недавно появился топовый техлид, будет супер-интересно. Вакансия будет открыта скоро.
По деньгам будет норм, а написать можно мне в лс)
Telegram
Dmitrii Tuchs
Head of QA @ DODO Engineering | Teacher @ QA.GURU | Program Committee @ Codefest. My channel: https://t.iss.one/likeaduck
🔥23
#books #learning #Java
Тут недавно мой друг, коллега по QA-хэдству, крутой спец по автоматизации на Java, с которым мы несколько лет бок о бок работали на многих проектах (PropellerAds, Simscale и не только) - Миша Сидельников - написал книгу Let's Automate IT.
Я от всей души рекомендую ее к прочтению, многие из постулатов этой книги выведены, в том числе, из наших совместных попыток разобраться в так-себе-тестах, Миша - однозначно тот, к чьему мнению я сам всегда прислушиваюсь. Ну и цена вопроса - банановый раф или соевый латте 😁 Промокодик, опять же, на небольшую скидочку - TUCHS2023.
А на фото я, Миша и сами знаете кто в офисе Codeborne. Знаете же? 🙂
Тут недавно мой друг, коллега по QA-хэдству, крутой спец по автоматизации на Java, с которым мы несколько лет бок о бок работали на многих проектах (PropellerAds, Simscale и не только) - Миша Сидельников - написал книгу Let's Automate IT.
Я от всей души рекомендую ее к прочтению, многие из постулатов этой книги выведены, в том числе, из наших совместных попыток разобраться в так-себе-тестах, Миша - однозначно тот, к чьему мнению я сам всегда прислушиваюсь. Ну и цена вопроса - банановый раф или соевый латте 😁 Промокодик, опять же, на небольшую скидочку - TUCHS2023.
А на фото я, Миша и сами знаете кто в офисе Codeborne. Знаете же? 🙂
👍29❤17🤔2
#maven #java
А еще я сегодня впервые в жизни словил какую-то неведомую хрень, добавив зависимость в pom.xml и нажав кнопку "скачать зависимости". Еще раз. Я начинал с Java 1.6 в 2009 году. Я доработал до Java 21 и 2023 года. И впервые словил по-настоящему неведомую ошибку с мавеном! Сегодня день, когда
А еще я сегодня впервые в жизни словил какую-то неведомую хрень, добавив зависимость в pom.xml и нажав кнопку "скачать зависимости". Еще раз. Я начинал с Java 1.6 в 2009 году. Я доработал до Java 21 и 2023 года. И впервые словил по-настоящему неведомую ошибку с мавеном! Сегодня день, когда
maven для меня стал похож на gradle - ведь там неведомые ошибки возникают в каждом втором проекте 🥲 Надеюсь, следующий такой день будет еще через 14 лет.😱9😁7💔5🤔2🙏1
#regression #testing #manual
Важный вопрос - если мы находим баг на регрессе - надо ли проверить, был ли он в предыдущей версии, которая на проде? Я считаю, что это первое, что необходимо проверить. Если баг был (а может и в пред-предыдущей версии, а может он там уже годами) - то это информация, которая говорит нам о том, что что-то не так с тестированием. Мы пропускали этот баг как минимум 1 раз (а может 101 раз). Надо написать на это тест. Может, это закрывается банальным юнит-тестом на три строки, может нужен e-2-e. А может просто нужен ручной тест-кейс, и не забывать его проверить на следующем регрессе. Может нужна галочка в чеклисте. Но энивэй - мы понимаем, что это свидетельство недостаточной надежности нашего релизного пайплайна.
Если же баг "новый" (то есть, его не было в предыдущей версии, мы его только занесли) - то у нас что-то не так с разработкой, мы плохо подумали об AC и DoD, может банально невнимательно написали код, что-то не учли. Да, тут тоже в итоге должен появиться тест или тест-кейс, но такой баг должен радовать QA инженера, который его нашел, а вот "старый" - должен огорчать.
У нас в DODO не везде есть практика разделения таких багов на "новый"/"старый", где-то баг - это просто "ща пофиксим и поедем в прод", никаких выводов из них не делается.
Я хочу это изменить.
А вы что думаете?
Важный вопрос - если мы находим баг на регрессе - надо ли проверить, был ли он в предыдущей версии, которая на проде? Я считаю, что это первое, что необходимо проверить. Если баг был (а может и в пред-предыдущей версии, а может он там уже годами) - то это информация, которая говорит нам о том, что что-то не так с тестированием. Мы пропускали этот баг как минимум 1 раз (а может 101 раз). Надо написать на это тест. Может, это закрывается банальным юнит-тестом на три строки, может нужен e-2-e. А может просто нужен ручной тест-кейс, и не забывать его проверить на следующем регрессе. Может нужна галочка в чеклисте. Но энивэй - мы понимаем, что это свидетельство недостаточной надежности нашего релизного пайплайна.
Если же баг "новый" (то есть, его не было в предыдущей версии, мы его только занесли) - то у нас что-то не так с разработкой, мы плохо подумали об AC и DoD, может банально невнимательно написали код, что-то не учли. Да, тут тоже в итоге должен появиться тест или тест-кейс, но такой баг должен радовать QA инженера, который его нашел, а вот "старый" - должен огорчать.
У нас в DODO не везде есть практика разделения таких багов на "новый"/"старый", где-то баг - это просто "ща пофиксим и поедем в прод", никаких выводов из них не делается.
Я хочу это изменить.
А вы что думаете?
👍28💯8
Ребята, не пропустите топовый контент завтра в рамках открытых занятий QA.GURU. Этот тот случай, когда другого такого эксперта, говорящего на русском языке, вы не найдете даже при большом желании🙂. Ну и подписывайтесь на Мишин канал, конечно же!
Telegram
QA.GURU
Насколько важно учитывать функции универсального доступа при тестировании?
❓ Будем разбираться на бесплатном открытом уроке «Еще три способа управлять телефоном, которые стоит учитывать при тестировании» вместе с Mobile Head в Dodo Engineering, Мишей Рубановым.…
❓ Будем разбираться на бесплатном открытом уроке «Еще три способа управлять телефоном, которые стоит учитывать при тестировании» вместе с Mobile Head в Dodo Engineering, Мишей Рубановым.…
❤8
#java #automation
Хозяке java-автоматизаторам на заметку:
Периодически вижу подобные вопросы (и подобный код) тут и там:
Я не могу найти ни одной причины “модельным” классам (точнее, объектам) не быть immutable, уж во всяком случае, в тестах.
А начиная с Java 16 у нас есть ключевое слово record (на самом деле уже с 14, но там это была preview feature). Если вы его еще совсем не использовали, то о том, что это такое, советую послушать Тагира Валеева.
Тот же самый класс без всякого Lombok может выглядеть так:
Да, иногда можно придумать (хотя, в действительности, с трудом) поводы менять состояние объекта, но для этого мы вправе написать метод внутри нашего рекорда:
И пользоваться новым объектом. Ну, все как в любимом нами иммутабельном классе String.
Собственно, в учебном проекте моего курса qa.guru advanced все модели как на бэкендах, так и в тестах существуют в виде record. Чего и вам всем желаю и рекомендую. Вы же не на java 8? Selenide вот требует 17 🙂
Периодически вижу подобные вопросы (и подобный код) тут и там:
Схема ответа:
{
"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 🙂
YouTube
Тагир Валеев — Java 17 для тех, кто в танке
Подробнее о фестивале TechTrain: https://jrg.su/YR8JKw
— —
Не успели передохнуть от перехода на Java 11, а уже вот-вот выйдет Java 17! Кошмар, куда столько Джав! У вас не было времени следить, что там интересного произошло в трёх или пяти последних версиях?…
— —
Не успели передохнуть от перехода на Java 11, а уже вот-вот выйдет Java 17! Кошмар, куда столько Джав! У вас не было времени следить, что там интересного произошло в трёх или пяти последних версиях?…
❤21👍5🔥5
Мелочь, а приятно. Тем интереснее, что будет с действительно новым приложением в 2024 😈
Forwarded from Dodo Engineering
Не можем вам не рассказать!
Наше приложение Dodo Pizza🦤 заняло первое место на ежегодной российской конференции для рестораторов XVI Russian FoodService Forum. Поздравляем команду, которая создает и улучшает цифровой опыт наших гостей, а также всех коллег, причастных к этой победе!
Дальше будет круче и красивее! Мы в самом начале🔥
Наше приложение Dodo Pizza
Дальше будет круче и красивее! Мы в самом начале
Please open Telegram to view this post
VIEW IN TELEGRAM
🔥42🎉10👍3🏆1
#bugs #testing
Мы посчитали, что из заведенных саппортом багов за год пофиксили всего около 12%. Выглядит как жуткий перекос в бизнес-фичи и бесконечное разрастание баговых беклогов. Понятно, что оставшиеся 88% не блокеры, но, блин🥲 У кого как? Вы считаете такую метрику на стыке с кастомер саппортом?
Мы посчитали, что из заведенных саппортом багов за год пофиксили всего около 12%. Выглядит как жуткий перекос в бизнес-фичи и бесконечное разрастание баговых беклогов. Понятно, что оставшиеся 88% не блокеры, но, блин🥲 У кого как? Вы считаете такую метрику на стыке с кастомер саппортом?
#automation #этоневажно
Ввожу новый хэштег - #этоневажно. Дело в том, что я уже годы наблюдаю упертое желание потешить свое ЧСВ казалось бы важными постулатами в автоматизации, но большинство из них на самом деле не важны.
Сегодня рассмотрим классику - PageObject (тут и далее как обычно все на Java).
Что важно для PageObject?
1) PageObject объект должен создаваться максимально просто - читай, через
2) Он должен быть immutable и никогда не иметь никакого shared mutable state - читай, все поля
3) Он должен использовать композицию, а не наследование для расширения функциональности (то есть, если у нас есть
Все остальное, что я годами читаю в умных чатах по автоматизации, да и на code-review - не важно. Примеры:
- Стэпы должны быть в отдельном классе! Или наоборот - стэпы должны быть только в PageObject! - это вообще не имеет никакого значения, лишь бы было где-то прописано прямо в ридми. Никакой технической разницы нет, разве что вам приятно писать больше отдельных step-классов;
- Селектор должен быть CSS ! или XPATH!. Селектор вообще никому ничего не должен. В реальной жизни к нему только одно требование - селектор не должен быть всратым. Но это не зависит от того CSS он или XPATH
- Методы должны возвращать this! Или не должны! Или должны, но не всегда! - это не влияет никак ни на скорость написания тестов, ни на поддерживаемость, ни ну удобство рефакторинга.
- При композиции ты должен дублировать все методы вложенного объекта / Ты должен просто написать геттер! - можно и так и так
- Ассертов в пэйдж обжекте быть не должно - встречал и такое 🥲
- Имена полей должны начинаться со слова element! Или заканчиваться им!
и т.д. и т.п.
Обращайте внимание только на то, что действительно (технически) важно: иммутабельность, простота инициализации, композиция вместо наследования.
UPDATE от iLesnykh:
Ввожу новый хэштег - #этоневажно. Дело в том, что я уже годы наблюдаю упертое желание потешить свое ЧСВ казалось бы важными постулатами в автоматизации, но большинство из них на самом деле не важны.
Сегодня рассмотрим классику - 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 – а какой бренд сумочки или сколько высота потолков). И это тоже своего рода важно, просто не важнее первого и не в ущерб балансу скорость/качество.
Telegram
Ilia Lesnykh
Russian IT engineer, currently in Belgrade
🔥34❤6😢1👨💻1
Ребят, а вдруг есть среди моих подписчиков кто-то, кто хотел бы поработать QA на стыке с бизнесом, то есть, автотестов особо писать не надо (можно и не уметь), а вот погрузиться в бизнес, понять как работают додо-курьеры, какие там проблемы и особенности, хотел бы?
Мы запускаем амбициозный проект переделки бизнесфлоу доставки нашей пиццы под кодовым названием "курьер-на-город". Там нужен qa , уровень middle+ и выше. Повторюсь - вакансия не про тесты пописать, а про погрузиться в бизнес, мыслить как курьер (и заказчик пиццы) и находить проблемы именно, в первую очередь, в недодуманных бизнес-сценариях.
Если кто-то заинтересован, напишите пожалуйста мне в ЛС или в комменты к посту. Созвонимся, все расскажу.
Мы запускаем амбициозный проект переделки бизнесфлоу доставки нашей пиццы под кодовым названием "курьер-на-город". Там нужен qa , уровень middle+ и выше. Повторюсь - вакансия не про тесты пописать, а про погрузиться в бизнес, мыслить как курьер (и заказчик пиццы) и находить проблемы именно, в первую очередь, в недодуманных бизнес-сценариях.
Если кто-то заинтересован, напишите пожалуйста мне в ЛС или в комменты к посту. Созвонимся, все расскажу.
👍21🔥3🤔2
Интересный контент должен подъехать на следующей неделе - буду за круглым столом обсуждать обучение QA😈. Свою первую школу автоматизации внутри PropellerAds организовал 4 года назад, ещё до прихода в qa.guru. Мне определенно есть, что сказать )
👍16🔥3❤🔥1🤩1
Forwarded from QA.GURU | Автоматизация, ручное тестирование, карьера в QA
Об этом мы поговорим 7 декабря в 20:00 по Москве за круглым столом.
Сильнейшие специалисты отрасли: Инна Чернобровкина, Ян Акмеев и Дмитрий Тучс соберутся в прямом эфире, чтобы поделиться своим опытом и обменяться мнениями.
💡 Что мы обсудим?
• Пути и планы развития тестировщиков внутри компаний
• Сложности и ловушки при создании корпоративной школы
• Секреты формирования библиотеки полезных ресурсов для QA
• Взгляд на внешние курсы: стоит ли отправлять туда специалистов?
• Все за и против различных форматов обучения QA
• Актуальные варианты обучения для QA – инженеров внутри компаний
🔥 Мы приглашаем вас не просто послушать, но и активно участвовать в дискуссии! Задавайте свои вопросы в чате стрима и получайте ответы от наших экспертов.
Please open Telegram to view this post
VIEW IN TELEGRAM
❤17😱4⚡1❤🔥1🤓1
Кстати, мы еще делаем небольшой QA митап в Москве - но, без моего присутсвия😔. 12 декабря в офисе Dodo Brands в Москве.
За меня там будет лидер гильдии Web QA Женя Иванченко.
В программе разговор о том, как командам быстрее передавать фичи бизнесу и писать эффективные ассерты в интеграционных тестах. Приходите, будет интересно! Ну и офис наш, в предновогоднюю пору, крутой 💔
Участвовать можно онлайн или оффлайн (пиццу есть точно удобнее оффлайн), регистрация по ссылке до 10 декабря 👉🏻 https://qa-dodo-spb.timepad.ru/event/2670046/
А почему не будет меня? Мы устраиваем съезд лидеров QA направлений DODO в Алмате ровно в эти же даты. Будем вживую прожаривать OKR-ы, родмапы и вот это все на 2024 год.
За меня там будет лидер гильдии Web QA Женя Иванченко.
В программе разговор о том, как командам быстрее передавать фичи бизнесу и писать эффективные ассерты в интеграционных тестах. Приходите, будет интересно! Ну и офис наш, в предновогоднюю пору, крутой 💔
Участвовать можно онлайн или оффлайн (пиццу есть точно удобнее оффлайн), регистрация по ссылке до 10 декабря 👉🏻 https://qa-dodo-spb.timepad.ru/event/2670046/
А почему не будет меня? Мы устраиваем съезд лидеров QA направлений DODO в Алмате ровно в эти же даты. Будем вживую прожаривать OKR-ы, родмапы и вот это все на 2024 год.
qa-dodo-spb.timepad.ru
Cокращаем LeadTime в команде и повышаем эффективность ассертов автотестов / События на TimePad.ru
Приглашаем на встречу для QA при поддержке Dodo Engineering. Узнаем, как помочь команде быстрее передавать фичи бизнесу и писать эффективные ассерты в интеграционных тестах
❤8
#Java #gradle #automation
Вчера один из моих студентов задал вопрос -
Ну и скрин с этой ошибкой.
Опыт не пропьешь - я сразу сказал, что, видимо, gradle в проекте / системе не той версии, которая нужна для Java 17 (это версии 7.6 и выше). Студент стал разбираться и - конец немного предсказуем - дело было действительно в старой версии gradle (6.7). Обновили и все заработало.
И тут у меня один вопрос - неужели невозможно, если уж вы делаете разбивки по версиям, которые совместимы с той или иной JDK, неужели совсем невозможно вывести понятное сообщение об ошибке - "Дружище, у тебя несовместимые версии". Как новичок должен разбираться в
?
У меня нет ответа.
Вчера один из моих студентов задал вопрос -
Добрый день! Кто может подсказать какой 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
?
У меня нет ответа.
👍34🔥8❤3❤🔥2