Специалист по ремонту компьютерного оборудования, моддер и видеоблогер VIK-on представил тестер оперативной памяти DDR5 для ноутбуков. Модуль выполнен в виде платы размером с плашку ОЗУ SO-DIMM и оснащён дисплеем для отображения ключевых параметров слота ОЗУ. Устройство способно отслеживать напряжение памяти и активность шины SPD, что позволяет понять — видит ли система установленные модули ОЗУ. Тестер оснащён специальной кнопкой, которая позволяет вывести на экран 5 последних POST-кодов (в настоящий момент эта функция доступна только на ноутбуках Asus на базе плат Quanta).
Нейросети в QA. Подборка важнейших кейсов применения.
Искусственный интеллект в QA – это уже не теория из будущего, а практический инструмент, доступный здесь и сейчас. Пока одни спорят, заменит ли ИИ тестировщика, другие уже используют его, чтобы избавиться от рутины и сосредоточиться на действительно сложных задачах.
Нейросети способны взять на себя генерацию тестовых данных, помочь в написании автотестов, проанализировать тысячи строк логов и даже превратить технический отчет в понятный документ для бизнес-команды. В этом коротком посте я собрал подборку конкретных кейсов, которые помогут вам сделать работу быстрее, качественнее и интереснее.
Кейсы по использованию нейросетей в QA
Генерация тест-кейсов на основе требований
Подготовка позитивных и негативных тестовых данных
Адаптация и улучшение баг-репортов
Перевод сценариев в формат Gherkin (Given-When-Then)
Генерация идей для негативного тестирования
Автоматический анализ логов ошибок
Помощь в написании автотестов и шаблонов
Конвертация технической информации в пользовательские инструкции
Голосовое управление заведением баг-репортов и создания чек-листов
Генерация финальных отчётов по тестированию
Помощь в написании автотестов: генерация кода, шаблонов и отдельных функций для фреймворков автоматизации
Подготовка баг-таблиц и чек-листов
Создание слайдов по итогам тестирования
Автоматическая сверка ожидаемого и фактического поведения
Генерация SQL-запросов на основе текстового запроса
Перевод технических отчётов для бизнес-аудитории
Проверка качества текста / интерфейса (UX-копирайтинг)
Генерация данных для нагрузочного тестирования
Сравнение версий документации / требований
Сбор фидбэка из отзывов пользователей (тематический анализ)
Создание чат-ассистента по документации и API
Анализ требований на предмет неясностей, противоречий и неполноты
Прогнозирование областей с высокой вероятностью дефектов
Этот список – лишь небольшая часть того, как нейросети могут усилить работу QA-инженера. Главный вывод прост: ИИ не заменяет специалиста, а становится его личным ассистентом – мощным, быстрым и безотказным. Он помогает находить неочевидные сценарии, экономить часы на подготовке данных и отчетов и, в конечном счете, повышать качество продукта. В своем коротком посте я представил лишь самые популярные примеры того как можно использовать нейросети в работе QA, но в полной коллекции под названием "70 кейсов применения нейросетей для QA" вы найдете их гораздо больше.
Сегодня, 9 сентября, в мире ИТ вспоминают первый компьютерный баг
В 1947 инженеры Гарвардского Mark II под руководством Грейс Хоппер разбирались с поломкой реле. В какой-то момент они нашли причину — внутри застряла настоящая моль. Её аккуратно извлекли, приклеили в журнал отладки и подписали: «Первый реальный случай бага».
До этого слово “bug” использовали в инженерной среде, но именно этот случай сделал его легендой ИТ.
Забавно, что сама моль сохранилась — её до сих пор можно увидеть в Смитсоновском институте.
С тех пор баги перестали быть буквальными насекомыми, но последствия стали куда серьёзнее.
Вспомнить хотя бы Heartbleed — уязвимость в OpenSSL, обнаруженную в 2014-м. Одна ошибка в библиотеке, которая отвечает за шифрование, открыла доступ к памяти миллионов серверов по всему миру. Пароли, ключи, данные — всё оказалось под угрозой. В СМИ её называли «самым громким багом десятилетия».
Через несколько лет весь мир обсуждал уже Log4j. Казалось бы, скромная библиотека для логирования на Java, использующаяся в тысячах приложений. В декабре 2021 обнаружили, что через неё можно удалённо выполнить произвольный код. За считаные часы уязвимость стала глобальной катастрофой: под угрозой оказались банки, облачные сервисы и даже игровые платформы вроде Minecraft.
В обоих случаях баг оказался не меньше, чем та самая моль в реле. Только если в 1947-м инженер мог достать насекомое пинцетом и продолжить работу, то сегодня одна ошибка в коде способна обрушить бизнес-систему мирового масштаба.
И это, пожалуй, самое важное напоминание: в ИТ нет «мелких багов». Любая ошибка может стать той самой «молью», остановившей работу огромной машины.
Как строить эффективное тестирование ИИ-моделей в бигтехе?
Меня зовут Валентин, я — руководитель направления тестирования моделей машинного обучения в Альфа-Банке. Моя команда занимается тестированием ML-моделей и модельных сервисов для наших клиентов уже более четырех лет, и более трех из них я погружен в наши процессы QA.
За несколько лет прошел путь от линейного тестировщика до руководителя команды из 8 человек, и в этой статье рассказываю о своем опыте. О том, как:
начал как единственный тестировщик ML-моделей в Альфа-Банке, совмещая функциональное и нагрузочное тестирование, что оказалось очень сложно из-за ограниченных ресурсов и растущего потока задач,
понял необходимость расширения команды,
столкнулся с выбором между кросс-функциональной командой и специализацией,
продумал подход к делегированию задач,
начал автоматизацию тестирования на основе Postman-коллекций, Pytest и Allure, интегрированную в CI/CD через Jenkins и Airflow, что ускорило и упростило тесты…
Эта статья будет полезна:
• тем, кто только начинает выстраивать процессы тестирования моделей; • начинающим тимлидам QA-команд до 10 человек; • тем, кто просто хочет познакомиться с примером организации QA-процесса с нуля.
Новая глава в твоей QA-карьере может начаться через три, два, один…
Упрощенная схема стенда для тестирования базовой станции LTE
Как насчет того, чтобы сменить привычную тестовую среду на что-то новое? Например, на тестовый стенд с BBU, RRU, симулятором ядра сети и т. д. И сделать это еще до осенних холодов.
Инженеры YADRO из дивизиона Телеком ищут коллег, которые присоединятся к тестировщикам-автоматизаторам. Нужны QА-инженеры с опытом работы в автоматизации тестирования от 2 лет и уверенным знанием Python. Приветствуется опыт работы с Linux и понимание сетей, базирующихся на TCP/IP.
Продолжаем набор специалистов в ИТ-команду SSP SOFT
Привет Хабр! Уже конец лета и не пора ли серьезнее подумать о новой работе — а мы продолжаем нанимать. Предлагаем реальные задачи, прокачку скиллов и бенефиты «в рынке». Никакой бюрократии и скуки — мы нацелены на то, чтобы вы получали удовлетворение от работы.
✔️ Гарантируем интересные задачи ✔️ Для каждого нового сотрудника есть наставник ✔️ Центр компетенций помогает прокачивать навыки ✔️ С нами ты можешь работать из любой точки мира ✔️ Для экстравертов у нас есть офисы в Москве и Томске ✔️ Оптимальный Work Life Balance ✔️ ДМС со стоматологией, обучение от компании и бонусная программа.
📢 На этой неделе мы ищем (см. ссылки на описание вакансий у каждой позиции):
👉 Не обязательно откликаться через hh — присылайте резюме напрямую нашему HR в Telegram: @sspsoft или на почту: job@ssp-soft.com. Не забудьте сопроводительное письмо с фразой «Нашел вас на Хабр», чтобы резюме рассмотрели по-возможности быстрее.
Войти в hardware-тестирование можно с любым бэкграундом. В команде HW QA в YADRO есть специалисты, которые ранее не работали с серверами, и те, кто с первого дня уверенно пользуется осциллографом. От новых сотрудников не ожидают готовых экспертных знаний — важны мотивация и желание разбираться. Остальному обучают внутри команды.
В первую неделю — оформление, знакомство с командой, лабораторией, стендами и процессами, закрепление ментора. За 14 дней — полное погружение в работу с BMC. В первый месяц поощряется командное взаимодействие.
На 2–4 неделе — изучение Linux, устройства продуктов, компонентов, прошивок и инструментов, работа по чек-листам: запуск тестов, анализ результатов. Ко второму месяцу — доступ к целевой платформе, документации и задачам среднего приоритета.
После адаптации определяется вектор роста и формируется индивидуальный план развития с обозначением компетенций и точек роста.
Пример использования матрицы компетенций для оценки сотрудников
Сейчас команда ищет HW QA-инженера в департамент разработки аппаратных средств. Задачи — тестирование инженерных образцов, валидация компонентов, настройка стендов, автоматизация, работа с BIOS, BMC и прошивками.
Напомним, кто мы: компания SSP SOFT занимается заказной разработкой и IT-аутсорсингом. Наши спецы помогают внешним клиентам реализовывать задачи в e-commerce, финтехе, медтехе, управлении инфраструктурой и других отраслях.
Рабочие места в офисах в Москве (отличная локация в ЦАО) и в Томске, а также у нас много сотрудников, которые работают удаленно из разных регионов России. Формат «онлайн» или «оффлайн» обсуждаем.
📢 Кого мы сейчас приглашаем (это описание вакансий в hh, а ниже прямые контакты с нашим HR для быстрого отклика):
Мы ценим сотрудников — работа без лишней бюрократии — только задачи, которые приносят результат и удовлетворение от процесса, участие в реальных проектах, развитие профессиональных навыков.
🎁 Наши бонусы: ДМС со стоматологией, обучение за счет компании, бонусная программа.
👉 В SSP SOFT мы рассматриваем найм не как «закрытие вакансии», а как включение нового человека в команду — с вниманием к развитию и прицелом на долгосрочную совместную работу.
Пишите с резюме нашему HR в Telegram: @sspsoft Или присылайте резюме на почту: job@ssp-soft.com.
И как это экономит ресурсы, улучшает продукт и снижает количество переделок
Одна из ключевых проблем, с которыми сталкиваются компании, заказывающие разработку — это разрыв между ожиданиями и реальностью. Причины бывают разные: неполное или неструктурированное ТЗ, размытые пользовательские сценарии, неучтённые роли или ветвления логики, которые всплывают на стадии разработки и тестирования.
Команда Doubletapp приняла решение: QA подключаются к проекту на этапе первого ознакомления с ТЗ от заказчика, ещё до оценки, дизайна и начала разработки. Этот подход сильно влияет на качество итогового продукта и помогает заказчику получить то, что действительно нужно — без множества итераций «переделать» и «добавить, потому что забыли».
Ниже расскажем, как у нас выстроен процесс, какие задачи берут на себя QA, и почему мы считаем, что раннее подключение тестирования — это не просто хорошая практика, а основа устойчивой разработки.
Роль QA в нашей команде: не только тестирование
Наши QA участвуют в проекте с первых дней.
Структурируют поступившее от заказчика ТЗ
Выделяют функциональные блоки
Формируют уточняющие вопросы
Работают над схемами и диаграммами логики
Проверяют, насколько требования реализуемы и согласованы между собой.
Наша задача на этом этапе — перевести бизнес-язык заказчика на язык разработки и одновременно выловить противоречия и пустые места в логике до того, как они станут багами.
QA плотно взаимодействуют с селлерами и лидами разработки и помогают им формализовать требования. Это снижает нагрузку на менеджеров и ускоряет проработку проекта.
Как это работает на практике
Заказчик приходит с ТЗ. Оно может быть подробным, а может состоять из тезисов, что хотелось бы реализовать в продукте.
QA разбивают информацию на структурные блоки — экраны, роли, сценарии, ограничения, точки перехода.
Составляют вопросы, которые передаются в команду, ответственную за коммуникацию с заказчиком.
Параллельно разработчики начинают верхнеуровневую оценку трудозатрат. Они тоже собирают вопросы, если логика не до конца ясна.
Все вопросы объединяются, уточняются и через менеджеров идут в диалог с заказчиком.
Такой процесс позволяет уточнить максимум информации до старта разработки и значительно уменьшает риск изменения требований на лету.
Когда это спасло проект
Один из проектов, с которым мы работали, сопровождался очень подробным бизнес-ТЗ — документ содержал более 70 страниц описания сервиса. Всё выглядело детально и проработанно.
Однако при формировании схемы ролей и доступов наши QA обнаружили логические противоречия: несколько ролей получали доступ к функциям, к которым не должны были иметь отношения. Это было связано с тем, что в тексте документа не было визуального представления логики переходов, и ошибки остались незамеченными.
На этом этапе проблема была решена за один день — без этой работы её бы пришлось исправлять на этапе тестирования, переделывая часть кода и логику авторизации.
Внутренние процессы: как это устроено
Мы работаем по agile: QA входят в спринты наравне с разработкой. Внутри спринта QA выполняют не только тестирование, но и работу, близкую к системной аналитике: анализ, структурирование, детализация, согласование требований, построение логики.
Тест-кейсы и баг-репорты ведём в YouTrack и Qase, используем CI/CD, чтобы как можно раньше получать обратную связь по стабильности продукта.
Зачем это заказчику
Когда QA работают с самого начала, заказчик получает
Прозрачную архитектуру с понятной логикой
Согласованные требования, переведённые в схемы
Минимум доработок в процессе разработки
Экономию времени — на исправление неочевидных ошибок
Повышенное доверие команды к требованиям — все понимают, что делают и зачем
Если вы находитесь в поиске команды, которая помогает не просто писать код, а проектирует продукт вместе с вами, задаёт неудобные вопросы до начала разработки и экономит вам месяцы правок — значит, вам нужен именно такой подход.
Standoff Hacks пройдет в Индии, и ты можешь полететь туда вместе с нами!
→ Во-первых, на нашей платформе активно багхантят ребята из Индии. → Во-вторых, наш следующий ивент Standoff Hacks пройдет 13 сентября в Ахмадабаде. → А в-третьих — у тебя есть шанс попасть на него за наш счет!
🔎 Для этого тебе нужно... Багхантить (surprise)! И набрать с момента публикации этого поста до 18 августа как можно больше баллов по этим публичным программам:
Тестируем микросервисное приложение с кучей интеграций — четыре совета из практики
На одном из финтех-проектов наша команда тестирования столкнулась с серьезными вызовами: нестабильные партнерские API, отсутствие тестовых сред у партнеров, лимиты на запросы и риски всё сломать одним обновлением.
В этом посте — примеры, как команда с этим справилась и как можно поступить в похожих ситуациях. Эта подборка может сэкономить кому-то часы (а то и дни) работы.
🛠️ Внешние сервисы без тестовых контуров
Решение: собственный мок-сервис на основе WireMock.
Как он работает:
тестировщик задает нужный ответ и отправляет его через HTTP-запрос в БД;
нужные вызовы подменяются в конфигурации;
при тестировании запрос уходит не во внешний API, а в мок, который отдает нужный ответ.
Моки у нас кастомные, конфигурируются через Swagger, и не завязаны напрямую на CI/CD — это упрощает запуск и дает гибкость.
Плюс: так мы не зависим от внешних API, которые то работают, то нет.
💸Платные вызовы и лимиты на тестовые запросы
Решение: изолированные стенды и замещение моками везде, где возможно.
Если API-партнер дает 150 вызовов в месяц, а вам нужно 500 на автотесты — моки опять же спасают. Мы блокируем обращения к реальным API на командных стендах и заменяем их заглушками. Проверку живых интеграций оставляем только на пред-проде.
Плюсы:
не сжигаем бюджет;
эмулируем ошибки и нестандартные ответы;
ускоряем тесты без зависимости от внешней стороны.
🔄 Нестабильность интеграционных тестов
Решение: изоляция и моки как защитный слой.
Микросервисная архитектура — это боль, когда один упавший сервис ломает релиз. Поэтому мы:
эмулируем нестабильные вызовы моками;
изолируем свою часть и фокусируемся на ее стабильности;
прогоняем тесты на командных стендах — быстро, стабильно и без флуктуаций от партнеров.
🤝 Десятки команд, завязанных на общий процесс
Решение: интеграционные проверки и ревью на совместимость.
Когда много команд делают один продукт, любое изменение может зацепить чужой модуль. Мы выстроили систему так, чтобы ошибки ловились до мерджа, а не после инцидента. Что помогло:
общие тестовые фреймворки и единый подход к интеграционным тестам;
сценарии, которые включают зависимости от других команд;
проверка обратной совместимости: если что-то ломает чужой функционал — фича не проходит MR.
В SSP SOFT открыты новые вакансии в ИТ-команды: ищем мидлов, сеньоров и лидов
Мы в SSP SOFT — команда, которая занимается заказной разработкой и активно ведет проекты по модели ИТ-аутсорсинга. Наши специалисты помогают внешним клиентам реализовывать задачи в e-commerce, финтехе, медтехе, управлении инфраструктурой и других отраслях.
Во 2-м полугодии 2025 года мы усиливаем несколько ключевых направлений. Если вы уверенно чувствуете себя как профи, цените системный подход и хотите работать в зрелой команде — присоединяйтесь.
Аналитика и системный анализ • Аналитик DWH • Аналитик 1С (Регламентированный учет) • Бизнес-аналитик (Промтех) • Системный аналитик (ИБ)
Разработка • Lead Python Developer • Android-разработчик (Senior) • Fullstack-разработчик (C#, React) • Разработчик 1С (ЗУП) • Разработчик Angular • Разработчик MS SQL • Data Engineer
Тестирование и поддержка • Automation QA Engineer • Automation QA Engineer (Python) • Automation QA Engineer (Java) • ITSM-инженер
Как мы подходим к найму:
В SSP SOFT мы рассматриваем найм не как «закрытие вакансии», а как включение нового человека в команду — с вниманием к развитию и прицелом на долгосрочную совместную работу.
🧩 Наши специалисты нередко входят в состав аутсорс-команд, работающих с внешними клиентами. Поэтому важно не только владение инструментами, но и софтскиллы: умение выстраивать коммуникацию, брать ответственность за сроки и качество своей работы.
🧭 Как устроен процесс найма и адаптации:
1️⃣ Собеседование с HR и руководителем направления, 2️⃣ Техническое интервью с нашими экспертами, 3️⃣ Индивидуальный план онбординга — с учетом ваших сильных сторон, 4️⃣ Испытательный срок — с поддержкой наставника, 5️⃣ Подключение к серьезным задачам — когда вы полностью готовы.
Есть множество видов тестирования, их классифицируют по различным признакам: уровню, целям, степени автоматизации, знаниям о системе, а также типу проверяемых сценариев (функциональные и нефункциональные). Расскажем подробнее о реализации разных видов тестов, которые проводятся в лабораторных условиях:
Модульные (unit) и компонентные (component) тесты реализуют сами разработчики. Они позволяют проверить корректность работы отдельных модулей и компонентов на ранней стадии.
Бокс-тестирование предполагает интеграцию нескольких компонентов базовой станции в рамках единой среды. В этом режиме используются симуляторы пользовательских устройств и ядра сети.
Системное тестирование охватывает проверку сквозных (end-to-end) сценариев на реальной аппаратной платформе. В отличие от бокс-тестов, здесь задействуются реальные пользовательские терминалы и максимально приближенная к коммерческой опорная сеть.
Нагрузочное тестирование и тестирование стабильности позволяют оценить работу системы под высокой нагрузкой в течение длительного времени. Это важно для подтверждения отказоустойчивости и стабильной производительности.
Выделим полевое тестирование. Оно позволяет в реальных радиоусловиях с реальными абонентскими терминалами протестировать описанные выше процедуры. Для такого тестирования используется специальный автомобиль, в котором установлено оборудование для проведения drive-тестов.
Внутри автомобиля для полевого тестирования
Во время drive-тестов используются разные модели пользовательских устройств. Это важно для нормализации результатов и получения объективной оценки поведения системы при работе с многообразием смартфонов.
В статье Ивана Политова и Антон Васина, инженеров из департамента разработки и проектирования опорной 5G-сети в YADRO, читайте подробнее, как в компании тестируют телеком-продукты.
10 задач, в которых AI действительно помогает QA-инженеру
Этот пост – саммари пилота нейросетей на реальном проекте. На тесте было несколько моделей: DeepSeek, Qwen, Gemma.
Вот универсальный список задач по тестированию, с которым все они справляются хорошо:
– анализ логов и stack trace; – поиск причин неочевидных ошибок в пайплайне; – генерация SQL-запросов и объяснение незнакомых конструкций (например, JSONB); – экранирование кавычек в больших XML-фрагментах; – автоматическая генерация тест-кейсов из BPMN- или XML-схем; – генерация случайных данных для теста; – сравнение параметров (включая UTF-8 кодировку) при ошибках интеграции; – проверка SQL-запросов, XSD (XML) и JSON-схем на соответствие структуре; – подсказки по фиксам в случае ошибок, связанных с отсутствием логов; – преобразование описаний ТЗ в чек-листы (но только если текст написан понятно и ТЗ описано подробно, подойдет не для всех и нужно внимательно ревьюить результаты); – написание сниппетов для postman.
Вывод ожидаем: ИИ все еще не заменяет тестировщика, но ускоряет работу. Главное – не забывать проверять то, что получилось.
Проект Zero Day Initiative (ZDI) сообщил о проведении соревнований Pwn2Own Ireland 2025, которые состоятся в середине октября 2025 года в Ирландии. Участникам предложено продемонстрировать эксплоиты для ранее неизвестных уязвимостей (0-day) в смартфонах, мессенджерах, беспроводных точках доступа, устройствах для умного дома, принтерах, сетевых хранилищах, системах видеонаблюдения и устройствах виртуальной /дополненной реальности. Атака должна быть проведена на самые свежие программы и операционные системы со всеми доступными обновлениями и в конфигурации по умолчанию.
Мероприятие примечательно готовностью выплатить миллион долларов за выявление в мессенджере WhatsApp ошибки, позволяющей удалённо выполнить код без действия пользователя (0-click). За удалённо эксплуатируемую уязвимость в WhatsApp, требующую действий пользователя (1-click), премия составляет 500 тысяч долларов, за уязвимость, приводящую к захвату учётной записи - $150 тысяч, а за получение удалённого доступа к данным пользователя, микрофону или камере - $130 тысяч.
В категории "мобильные телефоны" за удалённую эксплуатацию уязвимости в смартфонах Google Pixel 9 и Apple iPhone 16 назначена премия 300 тысяч долларов. При этом введена новая категория - взлом устройства при подключении по USB c размером премии $75 тысяч. За удалённый взлом 3D-шлема Meta Quest 3/3S и умных очков Meta Ray-Ban назначено вознаграждение в $150 тысяч. Максимальный размер премии за взлом устройств умного дома и сетевых хранилищ составляет $50 тысяч, систем видеонаблюдения - $30 тысяч, а принтеров - $20 тысяч.
Привет! Ищу комьюнити тестировщиков. Готовлюсь к конференции и нужна ваша помощь) Исследую вопросы формального vs исследовательского тестирования. Не могли ли бы вы пройти короткий анонимный опрос на 5 минут. Помогите собрать стату и исполнить мечту :)
Про опрос: 13 вопросов на да/нет/наверно. Он опосредован и анонимен, даже я не вижу, кто его заполнял
От вибростендов до полевых испытаний: тесты Hardware QA в реальных условиях
Как понять, выдержит ли стойка или сервер поездку через всю страну в контейнере или грузовике? Чтобы проверить, готово ли оборудование к реальной транспортировке, команда HW QA использует целый комплекс инструментов и методов:
Вибростолы воспроизводят типичные транспортные нагрузки — от тряски в грузовике до промышленных вибраций. Оборудование фиксируется на платформе, и на него подаются колебания заданной частоты, амплитуды и направления. Вибротесты стоек показывают, как сервера реагируют на тряску: анализ ускорения и спектр вибраций (частоты до 10–40 Гц).
Датчики ускорений фиксируют рывки и удары, чтобы оценить реальные перегрузки компонентов.
Полевые испытания: перевозят стойки по России, ставят датчики и собирают реальные профили нагрузок в зависимости от типа грузовика и подвески.
Вибротест стойки: проверяем, как сервера выдерживают тряску при перевозке
Почему это важно? Даже один отвалившийся кабель в пути может сделать стойку непригодной к использованию.
Это лишь часть арсенала Hardware QA в YADRO. В статье директор департамента верификации и контроля качества Игорь Попов рассказал, как команда проверяет стойки и серверы на прочность, какие инструменты используют и как команда инженеров моделирует реальные условия работы оборудования.
А зачем вообще проводить исследования? А вот интересно посмотреть на сферу глазами тех самых ребят, кто каждый день работу эту самую работает, узнать, где больше всего болит и где можно усилиться — то есть в будущем предложить решение, которого ещё нет или чего мало.
Так появилось исследование тестировщиков 👇
Ещё можно углубиться в лендинг: https://qa-survey-2025.2gis.ru. Посмотреть разные цифры: собирали данные скрупулезно по профильным каналам, 1000 QA-инженеров начали опрос, 570 стойко ответили на все 45 вопросов!
К слову, и про статистику сбора данных: 37% тестировщиков проходили опрос на Android, 29% на iPhone, 23% на Windows, 9% на MacOS и даже 2% c Linux.
Заглядывайте и пишите, за что взгляд зацепился, обсудим!
То самое, которым пользуетесь вы, ваши друзья и соседи. Через него проходит >90% заказов. Вы будете тестировать UI, логику, аналитику и пуши, следить за стабильностью релизов и качеством пользовательских сценариев. У нас отлаженная инфраструктура: автоматизация, фермы с эмуляторами, симуляторами и реальными девайсами.
Фундамент всех приложений Ozon: библиотеки авторизации, аналитики, performance-метрики. Вы будете проверять их стабильность, писать автотесты и автоматизировать процессы. Команды Ozon используют эти библиотеки каждый день — и от их качества зависит работа всей мобильной разработки.
Что общего во всех командах:
— Кроссплатформенная автоматизация на Python и Appium.
— Сложные, нетривиальные задачи — как в ручном тестировании, так и в автоматизации.
— Фичи, которые вы тестируете, видят миллионы пользователей — включая ваших друзей и родных.
