Home

Автор: Филип Рик (Filip Hric)
Оригинал статьи
Перевод: Ольга Алифанова

Возможно, вам нужно запускать ваши тесты в нескольких окружениях. Неоднократно видел, как люди делали что-то вроде этого:

cy.visit(Cypress.env('localUrl'))

Я большой поклонник использования Cypress.env() для хранения переменных, но есть способы куда лучше.

Автор: Максим Бугров, начальник отдела тестирования Департамента разработки клиентских систем и сервисов, Московская биржа

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

Но что делать, если вы приходите в проект, в котором исторически применялся подход «мороженки» тестирования, когда основную часть проверок закрывали ручным тестированием? При этом компания проходит трансформацию, и от вас ждут, что вы приведёте процессы в соответствие современным практикам и ускорите их?

Меня зовут Максим Бугров, я больше 8 лет работаю в тестировании ПО. На Московскую биржу я пришел летом 2021 года на позицию начальника отдела тестирования. Наш департамент преимущественно разрабатывает софт, который связывает клиентов и торгово-клиринговые системы Биржи. И я расскажу, как мы начали превращать мороженку в пирамиду — нас ждал огромный ледник задач.

Программа конференции по тестированию Heisenbug 2022 Spring почти готова — всего в ней будет 24 доклада. Вас ждут материалы о том, что сейчас происходит в мире тестирования и как делать работу так, чтобы коллеги смотрели на вас с неподдельным уважением.

Среди докладов:

– «Как перевести легаси-проект на Selenide». Спикер в деталях покажет, как внедрить фреймворк в старый проект с велосипедами и костылями так, чтобы никому не было очень больно.
– «Replay логов в качестве профиля нагрузки для MongoDB. Миф или реальность?» Рассказ о разработке нагрузчика для тестов capacity MongoDB. Сравним два варианта его реализации — на JS и на Java.
– «Why Java Test Frameworks are Overrated». Выясним, почему фреймворки для тестирования на Java переоценены, почему качество тестов для проекта важнее всего и как избавиться от излишнего усложнения кода.
– «Mocks vs Testcontainers». Нужны ли вообще моки, когда есть Testcontainers? Если мок не работает так же, как «настоящая» система, то в чем его польза? Можно ли избежать flakiness в интеграционных тестах? Об этом и многом другом узнаем из доклада.
– «Уберите из своего резюме "разработка QA-фреймворка"». Зачастую «запилил свой фреймворк» на деле означает «переусложнил свой код». Доклад позволит вам узнать, действительно ли оно вам нужно и почему для хорошего фреймворка достаточно четырех простых классов.

Online-часть пройдет 30 мая – 1 июня. А 21 июня — offline-день конференции в Санкт-Петербурге.

Подробности и билеты ждут вас на сайте конференции.

А этот промокод даст вам скидку при покупке персонального билета: softwaretesting2022JRGpc

Помимо Heisenbug, JUG Ru Group проведут весной-летом еще 6 конференций по разным направлениям: Java, JS, .NET, C++, мобильная разработка, распределенные и параллельные системы. Если что-то из этого вам интересно, покупать билеты на каждую конференцию необязательно. Для этого есть абонемент Full Pass, который дает доступ сразу ко всем семи, а стоит всего как два «отдельных» билета.

Переходите за подробностями на сайт Full Pass. Кстати, промокод выше действует и в этом случае.

А в качестве старта сезона JUG Ru Group проводят бесплатный фестиваль TechTrain. В программе — 9 докладов по разным IT-направлениям. В том числе — о плагинах для Selenide: зачем они нужны, как устроены и как написать свой. Подробности и регистрация ждут вас на сайте.

14 мая. Отправление — в 11:45. Choo-choo!

Автор: Кристин Джеквони (Kristin Jackvony)
Оригинал статьи
Перевод: Ольга Алифанова

В этом месяце я решила сделать что-то новенькое! Обычно мои статьи нацелены на тестировщиков, которые хотят прокачать свои навыки и лучше размышлять о том, что тестировать. Но в этот раз я хочу обратиться к тем, кто нанимает тестировщиков.

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

• Он, возможно, не сможет автоматизировать тесты вообще – все тестирование будет вручную, и это сильно замедлит релиз.
• Он будет плохо автоматизировать тесты, и вы получите нестабильные тесты, которым нельзя доверять, нуждающиеся в постоянной поддержке.
• Он будет плохо понимать технические концепции – другим членам команды придется тратить время, чтобы снова и снова объяснять их коллеге.
• Он не сумеет создать тест-стратегию – в итоге тестироваться будет не то, что нужно, а то, что нужно, не будет проверяться вообще.

Автор: Пермякова Ольга
Ссылка на оригинальную публикацию

Привет, я Оля, QA iOS. Наша команда выкатывает обновления для мобильного 2ГИС и следит, чтобы у него не упала производительность.

Изначально мы отслеживали это уже после попадания приложения в стор, что, конечно, было не очень эффективно. Если происходила просадка, приходилось срочно чинить и перезаливать приложение. Естественно, нам хотелось улучшить процесс и проверять производительность до выхода приложения в стор, а ещё лучше — на каждом этапе создания приложения.

Для этого теоретически подходили два инструмента — MetricKit и Performance Monitoring. Мы решили присмотреться к ним, потому что:

• MetricKit — продукт Apple, а значит будет поддерживаться, пока существует iOS;

• Performance Monitoring — продукт Firebase от Google. У нашей команды есть опыт использования Firebase Crashlytics, значит перейти на продукт от этого же производителя будет легко.

Автор: Саманта Коннелли (Samantha Connelly)
Оригинал статьи
Перевод: Ольга Алифанова

Я рекомендую всем соло-тестировщикам регулярно проводить bug bash/групповое тестирование. Этим можно заняться в конце спринта или цикла разработки функции. Вы приглашаете команду, запасаетесь закусками и напитками и вместе тестируете около часа.

Автор: Павел Новиков, QA Engineer

Прежде чем приступить к автоматизации тестирования, желательно проанализировать приложение. Чем больше приложение готово к автоматизации, тем меньше проблем будет в дальнейшем при разработке автотестов и анализе результатов.

Одним из ключевых факторов успеха автоматизации является тестируемость приложения. Благодаря тестируемости автотесты пишутся проще и быстрее. Например, для API это публичные методы, а для UI это HTML страница.

Если вы хотите понять, чем живет индустрия тестирования, посетите конференцию Heisenbug 2022 Spring. Она пройдет с 30 мая по 1 июня.

Программа еще формируется, но в ней уже есть:

• «Собственный нагрузчик для MongoDB. Ошибки, успехи, опыт». Доклад про нетривиальные проблемы нагрузочного тестирования и работу с replay-логами.
• «Воркшоп: CI/СD глазами тестировщика». Воркшоп, на котором вы узнаете, почему CI/CD — это не только автоматический запуск тестов, какие метрики нужно включить в пайплайн и как контролировать качество с помощью Quality Gates.
• «Уберите из своего резюме "разработка QA-фреймворка"». Выясним, почему «идеальный» фреймворк должен иметь около 4 публичных классов и почему иногда разработка собственного фреймворка скорее вредит.

Кроме того, 21 июня в Петербурге пройдет offline-день конференции. А это это дополнительная порция Q&A-сессий со спикерами и экспертами, тематических дискуссий и, конечно, докладов.

Переходите за подробностями и билетами на сайт Heisenbug.

Для тех, кто покупает билет за свой счет, действует скидка по промокоду: softwaretesting2022JRGpc. Она распространяется на online, online+offline и абонемент Full Pass, который открывает доступ ко всем конференциям JUG Ru Group весны и лета 2022. Помимо Heisenbug, это DotNext, HolyJS, JPoint, Mobius, Hydra, C++ Russia.