Привет, Хабр. Пишу, потому что на текущем проекте прямо сейчас живу эту боль: всем включили Cursor «для скорости», а нормальных автотестов так и не завезли. Может, кто-то уже описывал этот кейс, но я не нашёл — поэтому делюсь своей ситуацией и тем, как это надо было делать с самого начала.
Привет! Меня зовут Ринат, я iOS-разработчик в Naumen. В компании я занимаюсь разработкой нескольких iOS-продуктов: клиента для SMP-сервера (Service Management Platform) и SDK чата.
В этой статье расскажу, как мы используем связку Proxyman + HAR, чтобы готовить mock-данные сетевых запросов для интеграционных UI-тестов одного из iOS-приложений. Такой подход выручает, когда для тестов нет возможности поднять сервер с нужным наполнением или сервер не предоставляет дополнительных методов API для имитации определенного сценария — например, переписка в чате с собеседником, обновление статуса заказа.
Какие инструменты и методы спасут от крушения в момент пика. И как выстроить устойчивость в мире маркетинга и распродаж.
В жизни каждого фронтендера наступает момент, когда приходится перейти от родного привычного десктопа на разработку мобильной версии веб-приложения или даже начать работать над 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+ лет работы в тестировании я сталкивалась с разными подходами ведения базы знаний для тестировщиков на проектах. Где-то на проектах статей в базе знаний было так много, что глаза разбегались от количества информации, которую нужно было изучить на входе в проект. Но чаще попадались проекты, где базу знаний вели редкими набросками или не вели совсем. И это вызывало чувство безысходности в первые месяцы работы на проекте, так как информацию приходилось собирать буквально по крупинкам и не один месяц.
В этой статье я хочу поделиться списком возможных тем для статей, которые могут быть полезными для наполнения базы знаний тестировщиков на проекте.
В условиях стремительных перемен в ИТ‑сфере специалистам по тестированию необходимо быть гибкими, осваивать новые подходы и непрерывно развивать лидерские и коммуникативные навыки. Это помогает оставаться конкурентоспособными вне зависимости от технологий.
Почти всегда можно услышать говорящую фразу «тесты нужны всегда», но увы, это неправда. С вопросом о необходимости автотестов на проекте рано или поздно сталкиваются все команды. Почти у всех есть сомнения, а не рано ли? Окупится ли время затраченное на них?
Давайте разберемся, как понять, нужны ли вам автотесты? Или придем к мнению, что вам они не нужны (пока).
