Home

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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