Привет и добро пожаловать!
Меня зовут Никитенко Вадим. Я эксперт по тестированию, спикер, и на данный момент отвечаю за качество в Raiffeisen broker.
За свою карьеру я много чего попробовал: android, web, backend разработку, создание навыков для виртуальных ассистентов и, конечно же, QA.
Это бложек без цензуры про все вышеперечисленное. Здесь я буду публиковать новости, свои мысли и накипевшее про работу в IT.
Если ты уже это читаешь, спасибо за проявленный интерес. Присоединяйся!
Меня зовут Никитенко Вадим. Я эксперт по тестированию, спикер, и на данный момент отвечаю за качество в Raiffeisen broker.
За свою карьеру я много чего попробовал: android, web, backend разработку, создание навыков для виртуальных ассистентов и, конечно же, QA.
Это бложек без цензуры про все вышеперечисленное. Здесь я буду публиковать новости, свои мысли и накипевшее про работу в IT.
Если ты уже это читаешь, спасибо за проявленный интерес. Присоединяйся!
🔥9
Vadim Nikitenko pinned «Привет и добро пожаловать! Меня зовут Никитенко Вадим. Я эксперт по тестированию, спикер, и на данный момент отвечаю за качество в Raiffeisen broker. За свою карьеру я много чего попробовал: android, web, backend разработку, создание навыков для виртуальных…»
В конце июня буду выступать на второй конференции Сибирь.js с докладом про моки и параллелизацию в Playwright
Постараюсь играюче рассказать про сложные вещи простыми словами 👾
Постараюсь играюче рассказать про сложные вещи простыми словами 👾
👍4🎉2
Как мы...
Пиздец, больше всего на свете бесят доклады на IT-конференциях наподобие "Как мы внедрили...", "Как мы построили...", "Как мы улучшили...". На последних 2 конференциях по QA, на которых я был, я запомнил, как минимум, 7 таких выступлений.
Я, конечно, очень рад за вас, что вы такие молодцы и идете к успешному успеху, но мне-то что с этим делать, блять? Расскажите, как мне сделать что-то, а не как вы делали что-то...
Сука, и еще, как правило, такие доклады заканчиваются слайдами "Наши планы". Ну вы серьезно?
Такие эгоцентричные доклады имеют право на существование максимум на каких-то внутрикорпоративных митапах. Мне-то на кой хуй сдалась ваша внутренняя кухня?
Пиздец, больше всего на свете бесят доклады на IT-конференциях наподобие "Как мы внедрили...", "Как мы построили...", "Как мы улучшили...". На последних 2 конференциях по QA, на которых я был, я запомнил, как минимум, 7 таких выступлений.
Я, конечно, очень рад за вас, что вы такие молодцы и идете к успешному успеху, но мне-то что с этим делать, блять? Расскажите, как мне сделать что-то, а не как вы делали что-то...
Сука, и еще, как правило, такие доклады заканчиваются слайдами "Наши планы". Ну вы серьезно?
Такие эгоцентричные доклады имеют право на существование максимум на каких-то внутрикорпоративных митапах. Мне-то на кой хуй сдалась ваша внутренняя кухня?
🔥7👍3🐳2😁1
Береги Maven смолоду…
В последнее время широкое распространение получил метод атак Java приложений под названием MavenGate.
Если мы посмотрим на структуру любого проекта на основе Gradle/Maven с точки зрения объявления зависимостей, то, как правило, она будет содержать:
1) Репозитории зависимостей, такие как mavenCentral(), jcenter() и т.д.;
2) Зависимости обычно используют формат groupId:artifactId:version, например org.junit.jupiter:1.1.1. Сборщик просматривает список доступных репозиториев и ищет в нем указанную зависимость нужной версии.
В публичных репозиториях, таких как mavenCentral(), любой желающий может добавлять и распространять свои библиотеки. При этом регистрация GroupId осуществляется с помощью доменного имени. Например, чтобы опубликовать что-то в org.junit.jupiter, вам нужно создать DNS TXT-запись для домена jupiter.junit.org. Такое подтверждение личности предотвращает подмену зависимостей, позволяя разработчикам безопасно использовать зависимости и плагины в своих проектах, если они доверяют их создателям.
Однако что произойдет, если разработчик забросит свой проект и не продлит регистрацию доменного имени? Злоумышленнику будет достаточно:
1) Найти заброшенные зависимости в публичном репозитории;
2) Купить соответствующий домен;
3) Подтвердить свои права на groupId с помощью DNS TXT-записи;
4) Выпустить новую версию библиотеки с внедренным вредоносным кодом и ждать, пока разработчики обновятся до нее;
Компания oversecured провела исследование по уязвимым либам в mavenCentral:
1. По доменам: 3,710 из 26,163 или 14.18%;
2. На основании приватных github-репо: 291 из 7,523 или 3.86%;
Цифры впечатляют...
В последнее время широкое распространение получил метод атак Java приложений под названием MavenGate.
Если мы посмотрим на структуру любого проекта на основе Gradle/Maven с точки зрения объявления зависимостей, то, как правило, она будет содержать:
1) Репозитории зависимостей, такие как mavenCentral(), jcenter() и т.д.;
2) Зависимости обычно используют формат groupId:artifactId:version, например org.junit.jupiter:1.1.1. Сборщик просматривает список доступных репозиториев и ищет в нем указанную зависимость нужной версии.
В публичных репозиториях, таких как mavenCentral(), любой желающий может добавлять и распространять свои библиотеки. При этом регистрация GroupId осуществляется с помощью доменного имени. Например, чтобы опубликовать что-то в org.junit.jupiter, вам нужно создать DNS TXT-запись для домена jupiter.junit.org. Такое подтверждение личности предотвращает подмену зависимостей, позволяя разработчикам безопасно использовать зависимости и плагины в своих проектах, если они доверяют их создателям.
Однако что произойдет, если разработчик забросит свой проект и не продлит регистрацию доменного имени? Злоумышленнику будет достаточно:
1) Найти заброшенные зависимости в публичном репозитории;
2) Купить соответствующий домен;
3) Подтвердить свои права на groupId с помощью DNS TXT-записи;
4) Выпустить новую версию библиотеки с внедренным вредоносным кодом и ждать, пока разработчики обновятся до нее;
Компания oversecured провела исследование по уязвимым либам в mavenCentral:
1. По доменам: 3,710 из 26,163 или 14.18%;
2. На основании приватных github-репо: 291 из 7,523 или 3.86%;
Цифры впечатляют...
👍4
Тестировщики ищут ошибки?
Это один из первых вопросов, который задают люди, недавно узнавшие о QA. И, кажется, вопрос простейший, на подкорке интуитивно понятно, как на него ответить, однако сформулировать это почему-то сложно для человека «с улицы».
Я попытался это сделать так:
Да, тестировщики находят ошибки. Другими словами, мы находим всё, что может навредить продукту: от некорректной функциональности до проблем с доступностью для людей с ограниченными способностями. Некоторые коллеги предпочитают говорить, что мы находим «дефекты». С академической точки зрения это более точная формулировка, но в общении я стараюсь её не использовать. Она расстраивает программистов, а у меня и так хватает проблем. К тому же я знаю, каково это — быть по другую сторону баррикад.
Тестировщики выявляют потенциальные риски. Мы обращаем внимание на ситуации, которые могут привести к ошибкам. Мы определяем, что поведение продукта может пойти «не так», даже если не было такого прецедента. Это может быть узкое горлышко в производительности, уязвимости безопасности, ux т.д.
Тестировщики находят/решают проблемы с тестируемостью. QA-инженеры влияют на те аспекты продукта, которые затрудняют обеспечение качества. Расширенные логи, нужное состояние приложения, тестопригодность кода — если вы не обеспечиваете это самостоятельно или, как минимум, не просите об этом разработчиков, то это ваша вина.
Тестировщики находят артефакты. Иногда мы сталкиваемся с ситуациями, которые кажутся проблемами, но на самом деле являются следствием того, как мы проводим тестирование. Иногда эти «проблемы» недостижимы в реальных условиях, но их всегда полезно обсудить и подумать, действительно ли к ним невозможно прийти.
Тестировщики находят альтернативы. Иногда мы замечаем удивительные и интересные особенности, которые не угрожают ценности продукта, но могут указывать на его скрытые возможности или нестандартные способы использования. При этом некоторые из этих особенностей могут быть даже неизвестны разработчикам. Таким образом мы расширяем доменные знания о продукте.
Тестировщики находят улучшения. Часто мы находим области, в которых продукт может быть лучше. Бывает, что это осознанная экономия при создании mvp, на которую пошла команда. А иногда - копеечная функциональность, о которой просто-напросто никто не подумал.
Что бы вы еще добавили?
Это один из первых вопросов, который задают люди, недавно узнавшие о QA. И, кажется, вопрос простейший, на подкорке интуитивно понятно, как на него ответить, однако сформулировать это почему-то сложно для человека «с улицы».
Я попытался это сделать так:
Да, тестировщики находят ошибки. Другими словами, мы находим всё, что может навредить продукту: от некорректной функциональности до проблем с доступностью для людей с ограниченными способностями. Некоторые коллеги предпочитают говорить, что мы находим «дефекты». С академической точки зрения это более точная формулировка, но в общении я стараюсь её не использовать. Она расстраивает программистов, а у меня и так хватает проблем. К тому же я знаю, каково это — быть по другую сторону баррикад.
Тестировщики выявляют потенциальные риски. Мы обращаем внимание на ситуации, которые могут привести к ошибкам. Мы определяем, что поведение продукта может пойти «не так», даже если не было такого прецедента. Это может быть узкое горлышко в производительности, уязвимости безопасности, ux т.д.
Тестировщики находят/решают проблемы с тестируемостью. QA-инженеры влияют на те аспекты продукта, которые затрудняют обеспечение качества. Расширенные логи, нужное состояние приложения, тестопригодность кода — если вы не обеспечиваете это самостоятельно или, как минимум, не просите об этом разработчиков, то это ваша вина.
Тестировщики находят артефакты. Иногда мы сталкиваемся с ситуациями, которые кажутся проблемами, но на самом деле являются следствием того, как мы проводим тестирование. Иногда эти «проблемы» недостижимы в реальных условиях, но их всегда полезно обсудить и подумать, действительно ли к ним невозможно прийти.
Тестировщики находят альтернативы. Иногда мы замечаем удивительные и интересные особенности, которые не угрожают ценности продукта, но могут указывать на его скрытые возможности или нестандартные способы использования. При этом некоторые из этих особенностей могут быть даже неизвестны разработчикам. Таким образом мы расширяем доменные знания о продукте.
Тестировщики находят улучшения. Часто мы находим области, в которых продукт может быть лучше. Бывает, что это осознанная экономия при создании mvp, на которую пошла команда. А иногда - копеечная функциональность, о которой просто-напросто никто не подумал.
Что бы вы еще добавили?
🔥2
Если не писать юнит-тесты, то...
Кажется, что в 2к24 рассуждать на тему важности модульных тестов — бессмысленная и бесперспективная затея. Так ли это?
Я попросил 5 Senior Java Developer и 5 QA-инженеров продолжить фразу «Если не писать юнит-тесты, то...», и вот что получилось:
Ответы разработчиков:
1. Ты сам себе насрешь за шиворот;
2. Сэкономишь кучу времени и нервов, но получишь пизды от тестлида;
3. Вносить любые изменения в код становится больно и опасно;
4. Ничего не гарантирует верную работу функционала;
5. Можно сэкономить кучу времени;
Ответы тестировщиков:
1. Не словить первые баги;
2. Нужно быть готовым тратить больше времени на локализацию дефектов;
3. Каждый раз будешь сидеть на пороховой бочке;
4. Возрастут некоторые риски по проекту, такие как расширение кодовой базы и внесение изменений, а также потянет за собой увеличение времени на разработку и тестирование, а также будет под вопросом цель — стабильный рост проекта, так как за эту цель по большей части отвечают юнит-тесты;
5. Тогда мы не знаем, работает ли наше приложение, как задумывалось, на этапе разработки, а также увеличиваем трудозатраты при дальнейшем рефакторинге или расширении кода, поскольку не можем быть уверены наверняка, что не сломали что-то работающее;
В моей нерепрезентативной выборке 40% разработчиков, суммарный опыт работы которых больше моего возраста, готовы пренебречь юнит-тестами ради экономии времени для чего-то более полезного. При этом 100% тестировщиков, которые не пишут юнит-тесты, убеждены в их необходимости и важности.
Короче, простора для срача еще предостаточно.
Кажется, что в 2к24 рассуждать на тему важности модульных тестов — бессмысленная и бесперспективная затея. Так ли это?
Я попросил 5 Senior Java Developer и 5 QA-инженеров продолжить фразу «Если не писать юнит-тесты, то...», и вот что получилось:
Ответы разработчиков:
1. Ты сам себе насрешь за шиворот;
2. Сэкономишь кучу времени и нервов, но получишь пизды от тестлида;
3. Вносить любые изменения в код становится больно и опасно;
4. Ничего не гарантирует верную работу функционала;
5. Можно сэкономить кучу времени;
Ответы тестировщиков:
1. Не словить первые баги;
2. Нужно быть готовым тратить больше времени на локализацию дефектов;
3. Каждый раз будешь сидеть на пороховой бочке;
4. Возрастут некоторые риски по проекту, такие как расширение кодовой базы и внесение изменений, а также потянет за собой увеличение времени на разработку и тестирование, а также будет под вопросом цель — стабильный рост проекта, так как за эту цель по большей части отвечают юнит-тесты;
5. Тогда мы не знаем, работает ли наше приложение, как задумывалось, на этапе разработки, а также увеличиваем трудозатраты при дальнейшем рефакторинге или расширении кода, поскольку не можем быть уверены наверняка, что не сломали что-то работающее;
В моей нерепрезентативной выборке 40% разработчиков, суммарный опыт работы которых больше моего возраста, готовы пренебречь юнит-тестами ради экономии времени для чего-то более полезного. При этом 100% тестировщиков, которые не пишут юнит-тесты, убеждены в их необходимости и важности.
Короче, простора для срача еще предостаточно.
🍾3
Ручник...
У меня одного при слове "ручник" возникает ассоциация с недоразвитым, ни на что не способным пиздюком, посаженным на цепь?
Постоянно слышу это слово от всех в адрес тестировщиков, которые не умеют в автоматизацию. Причем и от самих тестировщиков тоже. Уебищнее всего слышать фразу от какого-нибудь QA-лида на конференции, типа "я своим ручникам поставил задачу...". Не специалистам по обеспечению качества, не qa-инженерам, и даже не мануальным тестировщикам. Ну спасибо, что не тормозам! Даже если это и не так, непроизвольно складывается впечатление о ЧСВ с максимальным доминированием над прирученными хомяками.
Вы хоть раз видели, чтобы в вакансии было написано "мы ищем в команду сильного ручника"? Индустрия лет 15 шла от тестировщика к qa-инженеру, чтобы это звучало ебче, а тут, блять, ручник.
Никто не хочет быть ручником...
У меня одного при слове "ручник" возникает ассоциация с недоразвитым, ни на что не способным пиздюком, посаженным на цепь?
Постоянно слышу это слово от всех в адрес тестировщиков, которые не умеют в автоматизацию. Причем и от самих тестировщиков тоже. Уебищнее всего слышать фразу от какого-нибудь QA-лида на конференции, типа "я своим ручникам поставил задачу...". Не специалистам по обеспечению качества, не qa-инженерам, и даже не мануальным тестировщикам. Ну спасибо, что не тормозам! Даже если это и не так, непроизвольно складывается впечатление о ЧСВ с максимальным доминированием над прирученными хомяками.
Вы хоть раз видели, чтобы в вакансии было написано "мы ищем в команду сильного ручника"? Индустрия лет 15 шла от тестировщика к qa-инженеру, чтобы это звучало ебче, а тут, блять, ручник.
Никто не хочет быть ручником...
🤣19👍8❤3🤡1
Мой доклад стал лучшим (по мнению зрителей) на конференции СИБИРЬ.JS 2024. Второе место, хотя доклад был не менее крутым, получил Дима Тучс с темой про CI/CD в QA.
В своем докладе я рассказывал про моки и параллелизацию в Playwright на примере web-игры, которую самостоятельно реализовал. Получил очень много положительных отзывов и от начинающих тестировщиков, и от qa-экспертов, что вдвойне приятно. Раскрывать сложную тему для людей с разным уровнем подготовки всегда трудно. По-видимому, у меня это получилось.
Всем огромное спасибо! Как появится запись в открытом доступе, выложу ее здесь 😊
В своем докладе я рассказывал про моки и параллелизацию в Playwright на примере web-игры, которую самостоятельно реализовал. Получил очень много положительных отзывов и от начинающих тестировщиков, и от qa-экспертов, что вдвойне приятно. Раскрывать сложную тему для людей с разным уровнем подготовки всегда трудно. По-видимому, у меня это получилось.
Всем огромное спасибо! Как появится запись в открытом доступе, выложу ее здесь 😊
❤15👍8🎉5
Ситуация: вы освободили джуна джина, который в знак благодарности предлагает вам любую CLI утилиту, которая облегчила бы вашу работу/жизнь. Не обязательно она должна быть связана с QA, но если у вас есть запрос, связанный с тестированием, будет вдвойне круто узнать, что болит. Если запроса нет, то можно пофантазировать и написать дичь. Что бы вы попросили?
🔥3
Начиная с версии 3.3 в Spring Boot была добавлена расширенная поддержка для Testcontainers с Artemis, как это было ранее сделано для PostgreSQL в 3.1.
С новой поддержкой можно легко настроить контейнер для Artemis и использовать его в ваших тестах:
Это демо примерчик, и никто вам не мешает всю конфигурацию вынести в отдельный @TestConfiguration класс.
Расширенная поддержка Artemis позволяет разработчикам/тестировщикам сосредоточиться на написании тестов, а не на настройке окружения. Да и выглядит все очень лаконично.
Больше не обязательно ебаться с @DynamicPropertySource или ApplicationContextInitializer. В общем, заебись!
С новой поддержкой можно легко настроить контейнер для Artemis и использовать его в ваших тестах:
@SpringBootTest
@Testcontainers
public class MyArtemisTests {
@Container
@ServiceConnection
static ArtemisContainer artemisContainer = new ArtemisContainer("activemq-artemis:latest");
@Test
void contextLoads() {
}
}
Это демо примерчик, и никто вам не мешает всю конфигурацию вынести в отдельный @TestConfiguration класс.
Расширенная поддержка Artemis позволяет разработчикам/тестировщикам сосредоточиться на написании тестов, а не на настройке окружения. Да и выглядит все очень лаконично.
Больше не обязательно ебаться с @DynamicPropertySource или ApplicationContextInitializer. В общем, заебись!
👍4🍾2
Буду выступать 17–18 октября в Санкт-Петербурге на Heisenbug Autumn 2024. В докладе расскажу про 7 смертных грехов тестирования. Приходите пообщаться, если будете на конференции!
🔥14
This media is not supported in your browser
VIEW IN TELEGRAM
До Heisenbug 2024 остался ровно месяц... Ждете?
🔥13
Друзья из Ozon Tech 28-29 сентября проводят конференцию E-CODE, которая пройдет онлайн и оффлайн в Москве по адресу Ленинская Слобода, 26 с.15. Ребята подготовили насыщенную программу с интересными докладами. И да, конфа абсолютно бесплатная!
E-CODE 2025 — IT-конференция от Ozon Tech // 13 и 14 сентября // Москва и онлайн
Инфраструктура и DevOps, С# и Go, iOS и Android, машинное обучение, тестирование, менеджмент, приглашенные гости.
👍6
Media is too big
VIEW IN TELEGRAM
Буду выступать 16 ноября на конференции Codetalks в Алматы с докладом, который называется "Пробуждение силы QA". Он будет про Playwright. Обещаю, будет эпично. Вот вам небольшой трейлер к докладу!
🔥10❤1
Clock - одна из самых интересных фич в Playwright последних минорных версий. Данное API появилось в версии 1.45.0. Эта штука позволяет управлять временем внутри браузера. Теперь можно без заморочек тестировать приложения, которые завязаны на даты, таймеры, таймауты и прочие моменты, связанные с течением времени.
Выглядит максимально просто. Конструкция ниже установит для браузера 1 января 2000 года:
Вызвав в консоли DevTools
Вы получите именно эту дату - 2000-01-01.
Но, естественно, Clock не будет работать, например, в сервисах с синхронизацией времени через API. Если web периодически запрашивает текущее время с удаленного сервера (NTP или REST), Playwright не изменит данные, которые приходят с сервера с помощью Clock API. Для этого понадобятся моки. Тоже самое касается JWT, завязанных на время, или, например, время в БД. Если приложение делает запросы к БД, которая использует серверное время для вычислений, то изменить это время, конечно же, не получится. Браузер only.
Выглядит максимально просто. Конструкция ниже установит для браузера 1 января 2000 года:
await page.clock.setFixedTime(new Date('2000-01-01'));Вызвав в консоли DevTools
new Date()
Вы получите именно эту дату - 2000-01-01.
Но, естественно, Clock не будет работать, например, в сервисах с синхронизацией времени через API. Если web периодически запрашивает текущее время с удаленного сервера (NTP или REST), Playwright не изменит данные, которые приходят с сервера с помощью Clock API. Для этого понадобятся моки. Тоже самое касается JWT, завязанных на время, или, например, время в БД. Если приложение делает запросы к БД, которая использует серверное время для вычислений, то изменить это время, конечно же, не получится. Браузер only.
playwright.dev
Clock | Playwright
Accurately simulating time-dependent behavior is essential for verifying the correctness of applications. Learn more about clock emulation.
🔥8👍4
Мой доклад "Пробуждение силы QA" с конференции Codetalks, которая прошла 16 ноября в Казахстане, Алматы. Спасибо большое организаторам за очень оперативный монтаж.
Посмотреть запись можно на разных платформах:
Youtube
VK Video
Rutube
👉 Оставить анонимный отзыв о докладе вы можете по ссылке
Посмотреть запись можно на разных платформах:
Youtube
VK Video
Rutube
👉 Оставить анонимный отзыв о докладе вы можете по ссылке
🔥18❤3👍3
Forwarded from Heisenbug — канал конференции
#видеозаписи
Рубрика #ТестоваяСреда возвращается! Прошедший Heisenbug завершался докладом с необычной подачей, а теперь публикацию видеозаписей начнём с этого доклада.
В нём фигурирует Playwright, но интересно может быть и тем, кто не пользуется этим инструментом.
YouTube | VK Видео
Скачать презентацию с сайта Heisenbug
Рубрика #ТестоваяСреда возвращается! Прошедший Heisenbug завершался докладом с необычной подачей, а теперь публикацию видеозаписей начнём с этого доклада.
В нём фигурирует Playwright, но интересно может быть и тем, кто не пользуется этим инструментом.
YouTube | VK Видео
Скачать презентацию с сайта Heisenbug
👍9🔥4❤2❤🔥2