Особенности тестирования web-приложений интегрированных с социальными сетями

25 января 2016
Ольга Лукавенко, QA

Особенности тестирования веб-приложений, интегрированных с социальными сетями

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

clip_image001

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

Самый распространенный пример, с которыми сталкивался едва ли не каждый, — отображение виджета с фотографиями из Instagram или отображение ленты Facebook на одной из панелей веб-страницы.

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

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

clip_image003

Количество социальный сетей обусловлено не только высоким спросом на них, но и разными целевыми аудиториями. Актуальной задачей становится интеграция с несколькими социальными сетями. Поэтому в приведенной выше схеме отображено взаимодействие с API нескольких социальных сетей. Важнее всего, что каждая соцсеть возвращает ответ разного вида. Для решения этой проблемы в нашем случае был добавлен Network-модуль, который приводит ответы всех АPI к одной структуре.

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

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

Изменение структуры ответа API как ключевое отличие систем, интегрированных с соцсетями

У этого события может быть несколько причин:

  1. Запланированный релиз новой версии API.
  2. Баги со стороны соцсети, которые выплыли наружу в результате релиза новой версии API или продукта в целом.
  3. Необходимость незапланированного релиза API, чтобы исправить то, что было поломано.

Здесь хочется акцентировать внимание на том, что, чем выше уровень интеграции системы с социальной сетью и чем больше количество социальных сетей, тем выше риск дефектов, обусловленных изменением кода third-party-приложения. Если говорить о глубине возникновения багов, дефекты, вызванные изменением API социальной сети, — наименьшее из зол, т. к. в этом случае мы точно уверены, что проблема касается только конкретной социалки. Но есть подводный камень: изменение API стороннего приложения — событие, не зависящее напрямую от нас, и зачастую гораздо быстрее поправить на своей стороне, чем ждать реакции разработчиков социальной сети.

Диаметрально противоположно обстоит дело с багами, вызванными любыми изменениями в ядре нашего приложения. Если это баг нашей системы, необходимо выяснить, воспроизводится ли он для определенного и конкретного случая интеграции, или баг задел взаимодействие со всеми социальными сетями. Во-первых, это даст нам возможность определить наличие других багов на ранних стадиях. Во-вторых, таким образом мы определим область, которой должны уделить большее внимание на регрессии. Положительный момент — как раз то, что ситуацию полностью контролируем мы, без зависимости от third-party API.

Импакт-анализ vs регрессионное тестирование

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

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

clip_image005

Рассмотрим импакт-анализ и его необходимость на житейском примере.

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

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

Что же делать, если неправильные решения были приняты изначально, и теперь QA-команда тонет в бесконечном количестве регрессионых кейсов?

Оптимизация регрессии с применением импакт-анализа предполагает четыре варианта:

  • Проверять все.
  • Проверить только определенные кейсы.
  • Уменьшить количество кейсов в каждом сьюте, убрав менее приоритетные.
  • Проверить все, расставив приоритеты проверкам.

clip_image007

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

На разных этапах развития продукта каждый подход можно использовать оптимально.

Изначально это будет тестирование всего, т. к. приложение находится в начальной стадии, и тестирование занимает меньше времени, чем разработка. С ростом регрессии (в нашем случае — с ростом количества социальных сетей), имеет смысл уменьшать количество кейсов в сьюте или количество сьютов в зависимости от того, какие изменения были в спринте.

Приоритезация — неотъемлемая часть тест-дизайна и применима абсолютна всегда.

Первое, что должен помнить любой тестировщик, — сначала всегда идет смок-тест, построенный как test-to-pass.

Такую классификаццию впервые я увидела в книге Software Testing Рона Паттона. Суть абсолютно аналогична позитивному и негативному сценарию тестирования, однако филофофия, как по мне, более корректная.

clip_image009

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

Data related issues возможны везде, но при интеграции с соцсетями вероятность их возникновения стремится к бесконечности

На этом закончим со спецификой флоу и остановимся на обсуждении данных.

clip_image011

Как известно, в любом проекте нужно учитывать пользовательские данные. Так, Facebook предоставляет одни типы данных — например новостная лента, содержащая текст, картинки, ссылки, Twitter — текстовые посты не более 140 символов, Instagram — набор изображений и видеофайлов.

Поэтому, прежде чем приступать к тестированию интеграции с соцсетью, вы должны стать полноценным пользователем этой социальной сети и четко понимать, что, как и для чего делается. Это может звучать глупо, если мы говорим про Facebook. Но, если вы берете LinkedIn и пользуетесь им как соискатель, скорее всего, не знаете о многих возможностях, которые эта соцсеть предоставляет работодателям. В таком случае вы должны понять, как происходит взаимодействие HR-специалистов друг с другом, как они просматривают резюме, как появляются новые вакансии в LinkedIn и т. д. Таким образом, когда вы сталкиваетесь с соцсетью, которой раньше не пользовались или пользовались бегло, обязательно запланируйте время на изучение ее нюансов.

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

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

  • Опишите все возможные события на стороне клиента.
  • Определите самые частые из них.
  • Создайте тесты на основе этих данных.

Lifehacks

Парочка очевидных лайфхаков напоследок.

Во-первых, придумайте простой способ управления учетными записями в соцсетях, которыми пользуетесь для тестирования. Если интегрируетесь, допустим, с Facebook, — создаете, скажем, три учетных записи. Всё, что нужно, — запомнить эти три учетных записи и пароли к ним. Но потом добавляются и другие соцсети, и в каждой из них нужна не одна учетная запись, потому что учетные записи выполняют разные функции. И рано или поздно вы столкнетесь с тем, что тратите много времени на то, чтобы разобраться, какая учетная запись за что отвечает. Поэтому с самого начала работы в таком проекте позаботьтесь об удобном управлении учетными записями.

У нас, например, была интеграция с семью соцсетями, и каждая предоставляла больше одного способа интеграции. В итоге у нас было 19 интегрированных каналов — это очень много! И у каждого канала было больше трех учетных записей для тестирования — каждая отвечала за различные типы проверок. Для управления всеми учетными записями мы использовали Evernote, но, на самом деле, можно использовать что угодно: Excel, Google Docs, блокнот…  И несмотря на то, что этот совет довольно банален и тривиален, о систематизации многие забывают.

Во-вторых, смотрите логи прямо во время тестирования. Конечно, для наблюдения за системой можно использовать New Relic, но это платный инструмент, на который заказчик может и не захотеть выделить бюджет. Поэтому мониторьте систему мануально, и логи — только один из подходов.

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