Всем привет!
19 сентября 2024 года мы уже проводим 5 митап Moscow QA совместно с с компанией  X5 Tech.

Приходите и вступайте в наше сообщество!

В последнее время я все больше уделяю внимание юнит тестированию, что связано с моим наставничеством Hexlet и выравнивание пирамиды на работе. И немного решил освежить основы при написании юнит тестов:

Всем привет! Меня зовут Алексей Иванов, и я очень люблю тестирование.

Несколько месяцев назад я заметил, что в Москве не хватает митапов по тестированию. Да, есть митапы, которые иногда проводят ребята из Альфа-банка, Озона, X5, но все они исходят от компаний, а не от сообщества как такового. И мы с небольшой командой организовали сообщество MoscowQA и провели первый митап в МТС AI.

29 февраля наш митап пройдет при поддержки компании Самолет.

В программе доклады инженеров из Самолета, Flipper Devices и moretv.

Всем привет, я пробовал в прошлом году сделать дайджест для qa инженеров, но в связи с событиями 24 февраля я не смог найти силы продолжить
В этом году я постараюсь делать дайджест на постоянной основе

И почему вас это должно волновать.

При компонентном тестировании вы тестируете более ранние этапы процесса разработки, и вместо тестирования всего приложения (или его большого фрагмента) вы тестируете более мелкие части приложения. С точки зрения Shift Left это очень важно.

«Начинайте тестировать как можно раньше» — эта фраза часто встречается в разных докладах и обучающих материалах. Это правда, чем раньше наши тесты найдут проблему, тем быстрее и дешевле мы ее решим. Это одна из главных причин эффективности CI. Часто встречаются команды, у которых очень много написанных автотестов, но они не используют тесты как подход к CI. Существуют различные причины, по которым команда считает, что эти тесты нельзя использовать в CI. Возможно, выполнение тестов занимает слишком много времени или они недостаточно надежны

Всем привет, до этого не было дайджестов для QA инженеров, я решил закрыть эту нишу, присылайте интересные статьи и будем делать дайджест вместе!

При рассмотрении термина «осмысленное тестирование» он выглядит как довольно странная абстракция, распространяющаяся на всю цепочку работы с программным обеспечением – от постановки задачи на разработку до деплоя. Что же значит слово «осмысленный» в данном контексте?

Если кратко, то создатель софта должен сосредоточиться на тестировании, приносящем пользу конечному продукту и его пользователям. Есть несколько подходов к осмысленному тестированию. Далее я расскажу о них, методиках, которые включены в эти подходы, и том, как реализовать новые знания в своей работе.

После многих лет работы в должности QA Engineer я решил поделиться некоторыми советами по общению с разработчиками. Далее описаны мои наблюдения по этому поводу.

Данное руководство позволит оценить требующийся уровень знаний для инженеров по автоматизации и инженер по разработке ПО в тестировании (SDET). Статья содержит конкретные критерии, которые должны стать ориентиром при необходимости перехода на новый уровень.

Добро пожаловать  на 2-й день челленджа #30DaysOfPlaywright!

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

При создании нового проекта я попытался использовать свою любимую библиотеку генерации случайных данных facker.js. Установилась версия facker@6.6.6.

Однако при попытке использовать привычные методы библиотеки выскакивала ошибка. Начав разбираться в проблеме, я перешел на github этой библиотеки. Обнаружилось, что весь исходный код удален. При этом был один коммит endgame, а в описании (Readme) текст – “Что на самом деле произошло с Аароном Шварцем?” (What really happened with Aaron Swartz?).

Добро пожаловать  на 1-й день челленджа #30DaysOfPlaywright!

Сегодня наша  цель – изучить руководство по началу работы с фреймворком, которое должно помочь настроить средство запуска Playwright Test в локальной среде разработки и подготовить его для  выполнения первого тестового прогона.

В этом месяце было решено изучить тему, которая привлекает лично меня – e2e-тестирование веб-приложений. Я хочу перейти от изучения основных концепций и инструментов к реализации эффективных стратегий кросс-браузерного тестирования в рабочих процессах разработки веб-приложений. Планирую сделать это с помощью Playwright.

Присоединяйтесь к #30DaysOfPlaywright. Давайте изучим инструменты, API и лучшие практики, по одному сценарию тестирования за раз!

Несмотря на то, что у этих фреймворков много общего, Puppeteer и Playwright развивались с разной скоростью, и сейчас Playwright набрал обороты и оставил Puppeteer позади.

Это привело к тому, что многие перешли с Puppeteer на Playwright. Это статья показывает, какие нужны шаги и какие новые возможности открывает этот переход. Пусть вас не смущает объем этой статьи, в большинстве случаев переход происходит быстро и безболезненно.

Перевод статьи Alister Scott: Five reasons why Playwright is better than Cypress

На основании проведенного сравнения, могу смело рассказать о причинах, почему Cypress все еще проигрывает конкуренцию.