Привет, Хабр! Меня зовут Настя, я работаю в команде тестирования мобильных приложений компании FunСorp.

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

Если повезло, то кандидат знает о необходимости проверки сетевого взаимодействия, но, за редким исключением, его знания ограничены Rewrite или Breakpoints.

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

Общее

• Блочное (Unit testing) — тестирование одного модуля в изоляции.
• Интеграционное (Integration Testing) — тестирование группы взаимодействующих модулей.
• Системное (System Testing) — тестирование системы в целом.

Введение

Практика

О чём это всё

В данной статье я постараюсь описать пример инфраструктуры для автотестов Android приложений (mobile automation), а именно, среду для проведения тестранов UI автотестов на эмуляторе Android девайса в виртуальной среде.

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

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

Проблема

У каждого из нас есть не менее одной идеи на миллион. Но далеко не у каждого получается воплотить свои задумки в жизнь. Этому есть ряд причин, о которых написано немало книг и статей. Известно также, что реализовать свои идеи не получается даже у крупных компаний с большим опытом, крутой командой и немалым бюджетом. Для примера можно посмотреть на «кладбище» проектов компании Google или «морг» Microsoft. Трудно представить, что у этих компаний столько много не получившихся проектов, на которые были потрачены немалые деньги и время.

Что делать? Какое решение? В этой статье собрана большая часть методов проверки гипотез, также рассказывается о новом термине «претотипирование» с примерами известных компаний.

Непрерывная доставка и развертывание (с общей аббревиатурой CD) далеко не новые концепции. Десять лет назад Джез Хамбл и Дэвид Фарли опубликовали книгу «Continuous Delivery». Патрик Дебуа в 2009 году организовал конференцию «DevOpsDays» и создал хэштег #DevOps (также пишется как devops, devOps или Devops).

Конечно, концепция CD для некоторых команд в новинку. По этой теме есть множество курсов и публикаций, помогающих организациям успешно внедрять CD. Как и в любой практике, когда вы разберетесь с основами, появятся проблемы, которые нужно решить. В январе 2020 года мне посчастливилось посетить новую конференцию DeliveryConf, на которой слушатели могут получить более глубокие технические знания о непрерывной интеграции (CI) и непрерывной доставке. Основываясь на том, что я узнала там, о чем могу рассказать из своего опыта и опыта сообщества, мне бы хотелось поделиться некоторыми задачами, с которыми сегодня могут столкнуться некоторые команды в вопросах CD.

Задача:

Теория:

• как облегчить процесс тестирования мобильных приложений в целом;
• о специфике работы с сетью, внутренними и внешними сервисами, платформах iOS и Android;
• какие процессные решения и изменения позволят вам развиваться быстрее и вводить культуру тестирования в отделе разработки;
• какие существуют полезные инструменты и решения для тестирования, отладки, мониторинга и миграции пользователей.

Как облегчить процесс тестирования?

• Набор интеллект-карт на все случаи жизни: test insane, ministry of testing
• Эвристики, мнемоники: I SLICED UP FUN (моя любимая), COP FLUNG GUN, SFDPOT, LONG FUN CUP