Синхронизация данных о сотрудниках между различными системами и платформами становится всё более актуальной задачей в условиях современного бизнеса. Это помогает компаниям улучшить процессы управления персоналом, повысить производительность труда и закрыть кейсы по обучению и сертификации. Однако эффективность этого процесса напрямую зависит от качества интеграций системы с внешними сервисами, что, в свою очередь, требует тщательного тестирования.
Меня зовут Любовь, я работаю QA‑инженером в компании iSpring. Моя команда и я занимаемся тестированием различных аспектов нашего продукта, включая его интеграции с другими сервисами. Наш главный продукт — iSpring Learn — это LMS (система управления обучением), основная задача которой — обеспечение эффективного обучения и адаптации пользователей.
Часто наши клиенты обращаются с запросом на реализацию интеграции платформы iSpring Learn с уже существующими в их компании сервисами. Это позволяет быстро и безболезненно синхронизировать базу пользователей и созданную оргструктуру. В качестве примеров таких сервисов могут выступать Битрикс24, 1C, E‑Staff или Huntflow, если речь идёт о подборе персонала.
В процессе работы мы внедряли некоторые интеграции вместе с нашими партнёрами, работавшими на аутсорсе, которые предоставляли нам готовые решения по синхронизации между сервисами. Это было не только технически сложным, но и интересным опытом, поскольку требовалось строить эффективное взаимодействие не только между сервисами, но и между командами разных компаний. В этой статье я хотела бы поделиться своими заметками о важных нюансах при тестировании таких интеграций и о том, что могло бы улучшить процесс разработки и тестирования, если бы мы знали об этом заранее.
На что обратить внимание при тестировании интеграции
Максимально полное ТЗ
Когда вы работаете с внешней компанией-партнёром, они, как правило, не имеют полного представления о всех особенностях вашей внутренней системы, в том числе как реализованы и функционируют те или иные модули, что они принимают, а что отдают.
Для того чтобы упростить процесс разработки и сделать его максимально подходящим для вашей системы, рекомендуется предоставить партнёрам спецификации API запросов с расширенными вариантами их использования. Это поможет партнерам лучше понять, как работает ваша система, и как эффективно использовать ее возможности.
Для примера возьмём некую HR систему, с которой будет синхронизироваться наша LMS. Мы хотим передать нового пользователя и присвоить ему роль «Администратор подразделения». Выбираем данную роль, запускаем синхронизацию и получаем 400-ю ошибку. Что могло пойти не так?
В ТЗ указано, что пользователь с такой ролью может быть создан, но что-то не работает.
Изучив запрос, можно обнаружить, что для роли "Администратор подразделения" обязательно должны быть указаны подразделения, которыми этот администратор будет управлять. Теперь мы знаем, в чем проблема: при создании пользователя с ролью "Администратор подразделения" в запрос нужно также передать список управляемых подразделений.
Добавление пользователя с ролью "Администратор подразделения" В этой ситуации, как минимум, нужно предусмотреть правильную обработку ошибок, и, как максимум, провести ревью требований, где будут описаны используемые запросы, и убедиться, что запросы при отправке будут учитывать все обязательные поля.
Необходимо помнить, что могут быть обязательные поля или другие специфические требования и со стороны внешнего сервиса, с которым будет происходить синхронизация. Эти нюансы следует учитывать при разработке и тестировании. Хорошей практикой будет изучение функционала нового сервиса и проработка различных кейсов до начала разработки.
Хотя тестировщик обычно не участвует в составлении технического задания, рекомендуется провести ревью всех пунктов. В процессе этого ревью могут всплыть дополнительные кейсы, которые могут добавить ещё несколько уточнений в текущее ТЗ.
Коммуникации
При разработке и тестировании интеграций часто возникают ситуации, когда одна сторона ждёт выполнения работы другой. Это может быть связано с разницей во времени, различными рабочими графиками или другими обстоятельствами. Без эффективной коммуникации процесс может затянуться и стать менее продуктивным.
Для контроля замечаний можно использовать такие инструменты, как Trello или Google Docs. Они позволяют организовать информацию в удобной форме, а также выделить цветами пункты в соответствие с их статусом. Это поможет всем участникам процесса быть в курсе текущего состояния дел и эффективно управлять своим временем.
Зависимость
Работая с партнёрами, особенно если они находятся в другом часовом поясе, возможны сложности из-за несовпадения рабочего времени. Одной из таких проблем может быть отсутствие возможности быстрого решения технических проблем, так как тестовое окружение может выйти из строя в любой момент, и это не всегда происходит в рабочее время.
Кроме того, если у вас нет полного контроля над процессами пересборки, мержей и отладки тестовой среды, и все, что у вас есть, - это URL страницы, то могут возникнуть значительные задержки с обеих сторон. В течение дня вас могут попросить протестировать новые исправления, но в этот момент вы заняты другими задачами. В конце рабочего дня тестовое окружение может перестать функционировать, а рабочий день ваших партнёров уже закончился, и они не могут помочь вам с решением проблемы.
Также стоит учесть, что мы не всегда знаем, насколько ответственно разработчики относятся к тестированию своего кода. Возможно, они сами проверяют свои изменения или у них есть собственный тестировщик, но эта информация может быть неизвестной, а словам доверять не стоит.
В этой ситуации важно убедиться, что партнёры предоставили вам все необходимые данные для тестирования. Необходимо проверить, что тестовая среда готова к работе, открывается и функционирует без сбоев, чтобы вы могли выполнить свою работу эффективно и вовремя.
Конфиденциальность данных
Потенциальные клиенты интеграционных решений обычно интересуются, какие конкретные данные будут передаваться из одной системы в другую. Например, будет ли использоваться информация о зарплатах сотрудников или насколько точно будет отражена организационная структура, если в ней присутствуют скрытые подразделения.
В документации следует уточнить, как происходит авторизация в сервис и что будет участвовать в синхронизации.
Поддержка
Иногда сторонний сервис может внести изменения в свой функционал или обновить API без предварительного уведомления. В этом случае нам приходится снова связываться с партнёрами для поддержки этих изменений или дополнительных настроек. Это возвращает нас к циклу ожидания, вопросов и несоответствий, который может занять значительное время.
Совместимость
Если у клиентов есть возможность подключить несколько интеграций одновременно, важно учесть возможное пересечение между ними.
Допустим, на первом этапе мы используем HR систему для добавления новых кандидатов на нашу платформу. После синхронизации, создаётся пользователь с логином, равным его email. Вход в систему осуществляется по логину и паролю, и пользователь может легко авторизоваться, используя свой привычный адрес электронной почты. Затем, когда сотрудник начинает стажировку, мы добавляем его данные в 1С, откуда при синхронизации на нашу платформу загружается вся необходимая информация. Проблема возникает, если 1С использует для логина пользователя атрибут ‘имя.фамилия’, вместо email. В этом случае сотрудник не сможет войти в систему под своим email, так как при синхронизации его логин будет изменён.
Пересечение нескольких настроенных интеграций и SSO Важно понимать, какие данные использует сервис для идентификации пользователя, и настраивать их одинаково для всех интеграций, участвующих в синхронизациях. А также стоит помнить про корпоративный вход и заложить время на его проверку.
В некоторых сервисах предоставляется выбор того, что может использоваться в качестве логина. Однако, если такой возможности нет, то наиболее предпочтительным вариантом является использование email в качестве логина. Это поможет избежать дублирования и облегчит запоминание данных для входа.
Чтобы жизнь стала лучше
Подготовка (тестовые данные, работоспособность окружения)
Перед началом тестирования, необходимо освоить новый сервис, с которым планируется интеграция. Если отсутствует соответствующая документация, вы можете взять на себя роль нового пользователя и самостоятельно изучить функционал платформы.
Тестовая среда может быть предоставлена с некоторыми заполненными данными, такими как пользователи и подразделения. Можно добавить сущности, которые не должны синхронизироваться (например, группы), чтобы проверить передачу данных на соответствие требованиям. Важно также изучить спецификацию заполнения форм и полей, проверять обязательность и правильность данных.
Помимо этого, необходимо определить различные сценарии тестирования, которые охватывают все возможные варианты синхронизации и взаимодействия сервисов. Хорошей практикой будет написание тест-кейсов и чек-листов с разнообразным набором тестовых данных, чтобы гарантировать полное покрытие функционала и выявление потенциальных проблем.
Обработка ошибок
При завершении процесса синхронизации необходимо обеспечить информирование пользователя о результате - успешном или неуспешном. Особенно важно уведомлять о возможных ошибках, какие могли быть допущены пользователем или возникли в системе независимо от его действий.
Добавьте статусы окончания синхронизации: Passed, Warning, Failed, возможность выгрузить и прочесть логи процесса с явными ошибками. Предупреждения о дублировании пользователей или отсутствии обязательных полей помогут разобраться в причинах неудачной синхронизации. Также стоит реализовать читаемые логи ошибок в собственном сервисе, чтобы их можно было отфильтровать и быстро решить проблему клиента.
Передача знаний (документация, доступы, чек-листы)
После завершения тестирования необходимо собрать всю документацию (тест-кейсы, чек-листы, ТЗ, дизайн, доступы к сервису) в один проект и поддерживать её актуальной. Это поможет коллегам лучше разобраться в тестировании интеграций, особенно если им нужно будет провести тестирование с новыми дополнениями или правками. Также стоит организовать встречу для обсуждения всех тонкостей и сложных моментов, возникших в процессе тестирования, чтобы учесть их в последующих проектах.
Время для итогов
Каждая интеграция получалась особенной: менялись как партнёры, так и специфика сервиса, а также команда разработчиков и тестировщиков. По завершении интеграции проводился общий анализ и оценка результатов.
Некоторые моменты всплывали в каждом обсуждении, и собрался небольшой список того, что мы будем иметь в виду в будущем, до того как приступим к следующим интеграциям. Некоторые из них могут показаться тривиальными, однако часто именно такие очевидные вещи упускаются из виду, что может привести к значительным потерям ресурсов.
Важно учитывать, что успешная интеграция требует не только технической грамотности, но и понимания бизнес-процессов, коммуникации с партнёрами и умения адаптироваться к изменяющимся условиям рынка.