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

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

Цель этой статьи - дать несколько советов и рекомендаций по управлению важнейшим компонентом тестирования сервисов, упомянутым в этой статье, а именно, барабанная дробь, ... тестированием производительности! 

Всем привет! Я Светлана Кирдяйкина, старший инженер по тестированию в Авито. Если вы задумываетесь про оптимизацию своего времени и улучшении тестирования — эта статья точно будет вам интересна. Здесь я постаралась простым языком описать факторы, на которые стоит обратить внимание перед тем, как начинать автоматизацию.

Привет, Хабр! Меня зовут Вика. В СберТехе я занимаюсь разработкой продукта Platform V Works:Test Data Management (TDM). Инструмент помогает QA генерировать необходимые синтетические тестовые данные по клику, а не обращаться к смежным командам и тратить на это время. Менеджерам TDM помогает сокращать time‑to‑market продуктов, поэтому лететь на другую планету ради тестов больше не придётся. В этом материале я расскажу, как мы поняли, что нам нужен отдельный инструмент для генерации, какие показатели у нас были в начале пути и к чему пришли сейчас. Поехали!

Как вы считаете, написание данных проверок исчерпывающе или в этом есть смысл, с учетом дефицита времени у QA инженеров?

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

И что же делать? Можно как вариант объединить баги шрифтов, размеров и прозрачности с одного экрана в одну задачу на исправление, и тогда приоритет у правки возрастет. Дополнительно хочу подсветить, что мы можем столкнуться с изменением одного экрана, который влияет на связанный функционал в остальных частях МП (если это старый UI баг).

Нужно ли тестировщику разбираться в базах данных? Короткий ответ: да, как минимум на том уровне, чтобы можно было успешно выявлять и локализовывать ошибки в их работе. На практике же проблемы в базах данных зачастую фрустрируют даже опытных QA-инженеров. Что-то где-то пошло не так, но что именно и где?

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

Под катом — наша шпаргалка по распространённым багам в работе баз данных. Разбили их по категориями, снабдили примерами и объяснили первопричины появления. Надеемся, будет полезно не только QA-специалистам, но и бэкенд-разработчикам начального уровня, а также всем, кто хочет углубить свои познания в области взаимодействия с БД.

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

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

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

Тестирование ПО — не магия, а ремесло. Но даже у самых опытных мастеров случаются промахи. Какие ошибки подстерегают тестировщиков на пути к качественному продукту? Давайте разберем их, добавив к каждой ситуации реальные примеры.

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

В современном мире мобильные приложения стали неотъемлемой частью нашей повседневной жизни. Их стабильная и правильная работа требует особого подхода к тестированию, особенно когда речь идёт о кросс‑платформенных приложениях, работающих в iOS и Android. В этой статье я поделюсь своим опытом и трудностями, которые могут встретиться в процессе тестирования приложений в упомянутых ОС.

В этой статье расскажу о сервисе QA Admin, который разработал с нуля для нашей компании. Основная цель сервиса — упростить подготовку тестовых данных и сократить время, необходимое на тестирование.

В разработке ПО мы часто сталкиваемся с ситуацией, когда большая часть дефектов концентрируется в относительно небольшом количестве модулей. Это явление называется скоплением дефектов (Defect Clustering). Принцип Парето (80/20) здесь прекрасно иллюстрирует ситуацию: 80% проблем обычно обнаруживается в 20% кода. Понимание причин этого феномена и умение идентифицировать "зоны риска" — ключ к эффективному тестированию.

Почему дефекты кучкуются?

Существует несколько причин, по которым дефекты имеют тенденцию скапливаться в определенных областях.

Как специалист по контролю качества с опытом работы на Java и Selenium, я с гордостью расскажу о Robot Framework.

Ты ищешь первую работу или решил сменить работу? Поздравляю! Впереди тебя ждет карусель интересных приключений: от собеседований и до ожидания обратной связи. Я провел немало собеседований, и у многих кандидатов есть одна общая ошибка — отсутствие подготовки. Они идут напролом, что заслуживает уважения, но можно облегчить себе путь, если подготовиться заранее. Ниже я опишу простые способы подготовки. Однако помни: не стоит затягивать с выходом на собеседования. Подготовка не должна превращаться в бесконечное "а вот этот вопрос изучу поглубже, этот курс пройду, еще видео посмотрю". Не превращайся в "вечного студента". Скорее всего, все нужные знания у тебя уже есть; главное — их УПАКОВАТЬ (как бы инфоцыгански это ни звучало).

Самопрезентация

Одна из самых важных частей собеседования, которая задает его тон. Здесь важно чувствовать себя уверенно и с интересом рассказывать о своем предыдущем опыте работы. Как можно себе помочь?

1. Заранее структурируй рассказ о себе.

Первый вопрос почти всегда — "Расскажите о своем предыдущем опыте". Поэтому тебе нужно подготовить монолог на несколько минут, в котором ты полно и убедительно представишь себя. Основные моменты:

- Информация о проекте (что это за проект; веб или десктоп; сколько % бэка, сколько фронта; функциональность проекта).

- Состав команды (сколько человек, какие роли, как вы взаимодействовали).

- Технологический стек (языки программирования; инструменты для тестирования; системы управления проектами и место хранения документации).

- Процессы в команде (как ставились и отслеживались задачи, взаимодействие с разработчиками, аналитиками и командой QA, как работали со срочными задачами и багами, частота релизов).

Недавно в гостях у канала AUTHORITY побывал руководитель отдела перспективных технологий компании Positive Technologies Николай Анисеня.

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

Привет, Хабр! Меня зовут Анна Асабина, я занимаюсь тестированием бэкэнда доменного направления в Рунити. В этой статье мы затронем основные понятия Test Management System и поговорим о плюсах и минусах внедрения TMS в проект. Также решим, какие важные черты должны присутствовать в качественной TMS. И, конечно же, расскажу о нашем пути к TestRail: как внедряли и на каких конкретных примерах используем.

Привет, меня зовут Сергей и я SDET-специалист в IT-компании SimbirSoft. В своей практике мне приходится тестировать как веб-, так и мобильные приложения на Android. Особенность тестирования мобилок в том, что шаги автотеста нужно максимально приблизить к действиям пользователя. О чем это я? Да все о том же — на смартфонах не кликают, а тапают; не закрывают по крестику модалки, а свайпают. Это как на флоте, эти все словечки понятны только тем, кто драил гальюн или бакланил из камбуза хлеб. 

В этой статье рассмотрим несколько методов скроллов класса TouchAction инструмента Appium, которые позволяют скроллить до нужного элемента или проверить свайп модального окна. И несмотря на то, что в новой версии Appium используются методы executeScript(), класс TouchAction все еще актуален. Поэтому я рекомендую к прочтению эту статью, в первую очередь, тем, кто использует в своих проектах Appium.

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

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

Привет, Хабр! Меня зовут Василина Кузнецова, я работаю инженером по тестированию в Ozon Tech. Я часто смотрю отдельные видео докладов с конференций. Полезными для себя находила доклады про особенности Selenium и Playwright в тестах фронта, про правильный процесс код‑ревью, когда вводила его в своей команде, про опыт того, как настроить процесс распространения знаний по фичам с командой, про борьбу с флаки‑тестами и многие другие. Да и просто для развития в тестировании, чтобы быть в ногу со временем, особенно когда был период работать единственным тестировщиком на проекте.

В этом году я решила более систематично подойти к вопросу и спланировать свой календарь посещения конференций (онлайн и офлайн). Для этого я начала с подборки российских QA‑конференций и митапов на ближайший год. У некоторых мероприятий ещё нет точных дат, поэтому за основу брала расписание текущего года.

Эта подборка будет полезна не только мне, но и другим тестировщикам, кто ещё мало участвует в конференциях, но хотел бы более активно посещать такие мероприятия, заводить новые профессиональные знакомства.

Итак, давайте начнём со списка конференций на 2025 год:

Усталость, осень, плохое настроение — очень важно учитывать в работе человеческий фактор . Если мы не проанализировали, на что он влияет, как мы можем понять критичность того, что мы им не управляем? И как им вообще управлять? Разберёмся вместе с Surf QA Team.