Тестирование мобильных приложений *

В жизни каждого фронтендера наступает момент, когда приходится перейти от родного привычного десктопа на разработку мобильной версии веб-приложения или даже начать работать над mobile-first решением, или еще страшнее — PWA-приложением.

И вот вы, фронтенд-разработчик, сидите с открытыми DevTools десктопного браузера, используете симуляцию мобильного устройства, и локально все идеально. А тестировщики все несут и несут баги. Верстка убегает, само веб-приложение тормозит, часть UI просто не достать пальцем, да и в целом жесты работают так, как им захочется.

Привет! На связи Полина, фронтенд-разработчик в Selectel. Раньше я тоже думала, что адаптив в десктопном браузере абсолютно такой же, как на телефонах. Да и вообще мобильный браузер — это просто браузер поменьше (спойлер — нет). В этой статье я расскажу об их различиях, что с этим делать, как прокинуть localhost на реальный телефон и получить DevTools от браузера в смартфоне, чтобы ловить поменьше багов на проде.

Когда работа в QA ограничивается только написанием тест-кейсов и автома��изацией, легко упустить из виду более широкую цель — реальное влияние на качество продукта. Настоящий QA — это про участие на всех этапах, включая прод, про понимание, как работает система в бою, и про осознанный подход к обеспечению стабильности и надёжности.

Я расскажу, как у нас в команде QA-инженеры участвуют в дежурствах на боевом контуре наравне с разработчиками: разбирают инциденты, анализируют причины сбоев и вносят улучшения в продукт и процессы. Поделюсь, какие компетенции для этого нужны, и как такой подход помогает QA не просто проверять, а действительно влиять на качество — не только после релиза, но и задолго до него.

Статья будет полезна и тимлидам с менеджерами, которые выстраивают процессы качества в команде. Она поможет по-новому взглянуть на роль QA, понять, как вовлечение инженеров в прод повышает зрелость команды и осознанность в подходе к качеству.

Подготовка к ISTQB давно стала своеобразным «обрядом посвящения» для тестировщиков.

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

Но есть проблема, о которой вслух говорят редко: готовиться к ISTQB всё ещё неудобно.

Куча устаревших сайтов, странные интерфейсы, вопросы 2011 года, закрытый контент, платные попытки, непонятные подписки, рекламные баннеры — всё это превращает нормальную учебную задачу в мучение.

Именно поэтому я решил сделать тот тренажёр, который мне самому хотелось бы использовать. Так появилась платформа ProSTQB — бесплатный удобный инструмент для подготовки ко всем уровням ISTQB, без рекламы, без paywall’ов и без боли.

Сегодня ProSTQB доступен сразу в трёх форматах: веб-версия, приложение для iOS и приложение для Android, что делает его одной из самых доступных платформ на рынке.

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

За годы работы в тестировании я убедился: то, что невозможно измерить — невозможно улучшить. В статье я разберу ключевые QA-метрики и объясню, как TMS помогает сделать картину качества действительно прозрачной.

Привет, Хабр! Производительность мобильного устройства важна не только для пользователей, но и для разработчиков приложений. После обновлений смартфон может работать медленнее, а новые версии игр и ПО предъявляют все более высокие требования к железу. Чтобы объективно оценить возможности устройства и сравнить их с эталонами, используют специальные приложения — бенчмарки. В статье разберем, какие из популярных инструментов применяются чаще всего и как правильно интерпретировать их результаты.

В статье рассматриваются исключения в Java: какие они бывают и как их можно обрабатывать. Простые объяснения и примеры помогут понять, как работать с ошибками в автотестах.

Чёрная пятница — долгожданный день для охотников за скидками и выгодными предложениями. Это своеобразный экзамен на прочность для разнообразных сервисов, финансовых организаций и банков, который, к сожалению, не все сдают, на «отлично».

Я — Дмитрий Тутов, руководитель направления нагрузочного тестирования в ПСБ. Сегодня поговорим про другую сторону Чёрной пятницы!

Поехали!

Привет, Хабр! Сегодня большинство компаний разрабатывают мобильные приложения, поэтому умение работать с ними становится почти обязательным скиллом. Мобильное приложение — это не просто веб в миниатюре, это отдельный мир со своей архитектурой, устройствами, операционными системами и ограничениями. В статье расскажем об основных особенностях мобильных платформ, с которыми тестировщики сталкиваются на практике. Подробности — под катом!

После ухода с российского рынка популярных систем вроде TestRail, Qase и Zephyr у команд появился запрос на отечественные TMS с удобным интерфейсом, различными интеграциями и встроенной аналитикой.

В статье разберём топ-3 отечественных TMS: сильные стороны, функциональность для ручных и автоматизированных тестов, интеграции, аналитику, AI и стоимость.

Привет, Хабр! Меня зовут Евгений Сабиров, я развиваю тестировщиков в Точка Банк. Много лет занимаюсь подготовкой докладчиков к конференциям, грейдирую и собеседую тестировщиков. И за это время не мог не заметить, насколько размыта зона ответственности этой роли: где-то тестировщик отвечает за коммуникацию с клиентами и проработку дизайна, где-то — только за написание автотестов, при этом про анализ требований даже не вспоминают. Такая размытость сама по себе нормальна: разным командам нужны разные навыки.

Проблемы начинаются тогда, когда тестировщик меняет работу или сталкивается с грейдами внутри компании. То, что ценилось в одной команде, может оказаться невостребованным в другой. Возникает естественный вопрос: какие знания и навыки должен иметь тестировщик, чтобы быть полезным в любой более-менее типовой команде?

В этой статье я попробую очертить роль тестировщика, выделить её ключевые обязанности и показать, как эти активности вписываются в процесс разработки. Это поможет самим тестировщикам яснее понимать ценность своей работы, а руководителям — более чётко распределять зоны ответственности внутри команды.

Привет! Меня зовут Андрей Максимкин. Я iOS-разработчик в hh.ru. В своих статьях (тут, тут и не только) мы уже не раз говорили о большой любви к тестам и их важной роли в нашем процессе разработки. В этой статье хочу поделиться опытом использования snapshot-тестов, начиная с этапа внедрения. Статья будет полезна для QA и iOS-разработчиков разных уровней. Обсудим не только теорию, но и напишем реальный snapshot-тест — как в нашей практике.

Вместо вступления

Сначала расскажем про snapshot-тесты и для чего они нужны. Snapshot тесты — это метод тестирования, который используется для защиты внешнего вида компонентов и интерфейсов от незапланированных изменений. Они позволяют зафиксировать эталонное состояние компонента и в дальнейшем использовать как образец. Это помогает выявлять изменения в пользовательском интерфейсе, которые могут возникнуть в результате обновлений кода.

В hh.ru мы активно разрабатываем нашу собственную дизайн-систему (ДС). Дело в том, что компоненты ДС могут иметь широкий набор свойств: цвета, размеры, скругления. Проверять корректность, например, цветов обычным ручным тестировщикам на длинной дистанции невозможно, поэтому возникла потребность автоматизировать проверки. Кроме того, при рефакторинге кода некоторые компоненты могут сломаться — хотелось бы находить такие проблемы сразу. Snapshot-тесты показались лучшим решением этих проблем.

Когда-то давно в hh.ru уже были snapshot-тесты. На тот момент они были написаны на экраны приложения. Эти экраны часто меняли свой дизайн, тесты вели себя нестабильно и падали, поэтому их приходилось переписывать. В итоге от snapshot-тестов отказались. Так что в своей новой попытке внедрения snapshot-тестов решили не писать тесты для экранов, а только для ДС. 

Каков наш статус тестирования?  Какая эффективность исправления дефектов?

В сегодняшней статье рассмотрим статус тестирования и эффективность исправления дефектов.

Полнота покрытия проекта тестами во многом предопределяет его качество, надёжность и безопасность, поэтому команды предсказуемо стремятся писать тесты на все методы и компоненты. Это имеет и обратную сторону: увеличение покрытия удлиняет прогоны, что, в свою очередь, сказывается на продуктовых метриках. В результате при разработке возникает необходимость искать баланс между покрытием и способами ускорения прогонов. Здесь у каждой компании свой подход.

Меня зовут Мария Рогова. Я iOS-разработчик в ОК. В этой статье я расскажу, с чего мы начинали, почему требовалась оптимизация и что мы предпринимали для ускорения прогона UI-тестов в iOS.

Статья посвящена использованию Gradle в автоматизации тестирования. Рассматриваются настройка проекта, управление зависимостями, запуск тестов и лучшие практики для QA-инженеров. Приведены готовые примеры конфигураций и сравнение с Maven.

За 8+ лет работы в тестировании я сталкивалась с разными подходами ведения базы знаний для тестировщиков на проектах. Где-то на проектах статей в базе знаний было так много, что глаза разбегались от количества информации, которую нужно было изучить на входе в проект. Но чаще попадались проекты, где базу знаний вели редкими набросками или не вели совсем. И это вызывало чувство безысходности в первые месяцы работы на проекте, так как информацию приходилось собирать буквально по крупинкам и не один месяц.

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

В условиях стремительных перемен в ИТ‑сфере специалистам по тестированию необходимо быть гибкими, осваивать новые подходы и непрерывно развивать лидерские и коммуникативные навыки. Это помогает оставаться конкурентоспособными вне зависимости от технологий.

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

Давайте разберемся, как понять, нужны ли вам автотесты? Или придем к мнению, что вам они не нужны (пока).

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

Сегодня доступно множество инструментов: Selenium, Playwright, Cypress и другие. Каждый имеет свои преимущества. Но в подавляющем большинстве наших проектов мы используем Selenium. Расскажу, почему мы сделали такой выбор.

Цель автоматизации — экономия

Главная задача автоматизации — снизить ручную нагрузку и минимизировать человеческий фактор. Рассмотрим на примере интернет-магазина. Если компания выпускает по 5 версий в месяц, перед каждым релизом необходимо проверять ключевые сценарии: добавление товара в корзину, оформление заказа, оплату. Регулярные ручные проверки требуют времени, увеличивают затраты и подвержены ошибкам.

Автотесты выполняют эти проверки быстрее и точнее. С экономической точки зрения, однократные инвестиции в разработку автотестов, как правило, окупаются за счет экономии на многократных ручных проверках.

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

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

Требования клиентов и гибкость технологий

Как IT-компания, мы сталкиваемся с разными требованиями заказчиков. Клиенты часто просят использовать определенный язык программирования, чтобы их команды могли поддерживать тесты. Например, если бекэнд написан на C#, то и автотесты предпочтительнее на нем.

Всем привет. Недавно понадобился мобильный браузер для работы на iOS и пока искал сделал сравнительный анализ. В статье выделены критерии оценивания, проанализированы преимущества и недостатки каждого из решений, рассказывается об интересном функционале.

Разработка завершена, ваше приложение получилось таким, каким вы хотели его видеть, и настало время показать его всему миру.

Но перед тем как приложение попадёт в руки пользователей, его должны одобрить модераторы App Store и Google Play. И вот тут начинается самое интересное. За последние годы требования стали такими, что даже опытные разработчики получают реджекты по полной программе. 

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