Home

Автор: Коршунова Александра

С нарастающими скоростями и распределёнными системами всё сложнее бывает создать приложение удобным для конечного пользователя. Программы обладают кучей фич. Но выполняют ли они то, что нужно юзерам? А скорость их выполнения достаточная? А производительность при выполнении не хромает? На эти вопросы помогает ответить нагрузочное тестирование (НТ).

Меня зовут Саша, я работаю в команде тестирования Ozon Fintech и расскажу про разнообразный спектр вариантов НТ: как именно мы его применяем и какие инструменты используем. Статья будет полезна тем, кто уже что-то слышал про НТ и хочет добавить его в свой проект, но пока страшновато. Давайте разбираться!

Автор: Энди Найт (Andy Knight)
Оригинал статьи
Перевод: Ольга Алифанова

Одна из самых больших проблем на пути становления отличным автоматизатором – это практика. Тестирование – это настолько же искусство, насколько и наука. Определение, где добавлять явные ожидания, как создавать устойчивые локаторы, и почему нужно проверять этот элемент, а не другой, требует времени. Обучение также требует наличия приложений со специфическими элементами или конечными точками, чтобы проверить определенные операции. К сожалению, при огромном количестве ресурсов по обучению автоматизации (вроде Test Automation University) количество публичных демо-сайтов, на которых можно попрактиковаться, практически ничтожно. Я с трудом нашел нравящиеся мне, и люди часто просят меня порекомендовать такие площадки.

Автор: Ольга Назина (Киселёва)

Тестирование стабильности или надежности (Stability / Reliability Testing) — проверка работоспособности приложения при длительном тестировании с ожидаемым уровнем нагрузки.

Если не перезагружать компьютер, рано или поздно начнет даже ворд тупить. Потому что «ну хватит уже, месяц ап-тайма, дай мне почистить внутренние кеши!». Или браузер — открыли вы кучу вкладочек, работает нормально. А через день-два-три-неделю начинает тормозить, пока не перезапустите. Это и есть надежность приложения — сколько он проработает в нормальном режиме?

Особенно важно для мобильных телефонов — вы вообще часто закрываете приложение? Я обычно просто жму на домашнюю кнопку, сворачивая его. А потом снова открываю. Приложения, не тестировавшиеся на надежность, постоянно зависают / вылетают / теряют соединение с сетью. 

Опубликован выпуск рассылки за начало марта.

В выпуске собраны ссылки на новые статьи, слайдкасты, отобраны самые интересные публикации в ленте блогов и темы на форуме.

Содержание рассылки доступно по ссылке.

Подписаться на рассылку

Автор: Филип Рик (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)
Оригинал статьи
Перевод: Ольга Алифанова

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

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

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