Обзор CRM и Salesforce
CRM-системы управляют полным жизненным циклом клиента — от первого контакта до продажи, поддержки и продления. Salesforce доминирует на рынке CRM с платформой, сочетающей стандартную функциональность и мощный движок кастомизации.
Архитектура Salesforce
- Salesforce Clouds: Sales Cloud, Service Cloud, Marketing Cloud, Commerce Cloud
- Модель данных: Стандартные объекты (Lead, Account, Contact, Opportunity, Case) плюс кастомные объекты
- Apex: Проприетарный язык Salesforce (похож на Java) для кастомной логики
- Lightning: Современный UI-фреймворк, заменивший Visualforce
- Flows: No-code/low-code автоматизация
- AppExchange: Маркетплейс сторонних приложений и компонентов
Ключевые концепции CRM
graph LR
A[Захват лида] --> B[Скоринг]
B --> C[Правила назначения]
C --> D[Квалификация]
D --> E[Конвертация в Account + Contact + Opportunity]
E --> F[Управление pipeline]
F --> G[Выиграна/Проиграна]
Фокусные области тестирования CRM
Тестирование управления лидами
- Захват лидов: Веб-формы, интеграция с email, API-импорт, ручной ввод
- Скоринг лидов: Автоматическая оценка по вовлечённости и демографии
- Правила назначения: Лиды направляются нужному менеджеру по территории
- Дедупликация: Система обнаруживает и объединяет дубли
- Конвертация: Лид становится Account + Contact + Opportunity
Тестирование pipeline сделок
- Прогрессия этапов: Проспект → Квалификация → Предложение → Переговоры → Закрыта
- Расчёты вероятности и ожидаемой выручки на каждом этапе
- Обязательные поля по этапам
- Отслеживание даты закрытия и точность прогноза
Отчётность и дашборды
- Фильтры отчётов возвращают корректные подмножества данных
- Графики дашбордов точно отражают данные
- Кросс-объектные отчёты корректно соединяют данные
Тестирование специфики Salesforce
Правила валидации
| Правило | Условие | Ожидаемая ошибка |
|---|---|---|
| Обязательный телефон | Телефон пуст при Status = “Contacted” | “Телефон обязателен для контактированных лидов” |
| Формат email | Email не соответствует паттерну | “Введите корректный email” |
| Дата закрытия в будущем | Дата закрытия в прошлом для открытых сделок | “Дата закрытия должна быть в будущем” |
| Кросс-полевая | Скидка > 30% и статус != “Одобрено” | “Скидки более 30% требуют одобрения” |
Тестирование Apex-триггеров
- Before triggers: валидация или изменение данных до сохранения
- After triggers: действия после сохранения (создание связанных записей)
- Bulk-операции: триггеры должны обрабатывать 200+ записей (governor limits)
- Предотвращение рекурсии
Продвинутое тестирование Salesforce
Salesforce DX и CI/CD
- Тестирование деплоя метаданных из системы контроля версий
- Проверка создания scratch org и установки пакетов
- Автоматизация запуска Apex-тестов в CI-пайплайне
- Проверка покрытия кода — минимум 75% для деплоя
Тестирование CPQ
- Правила конфигурации продуктов
- Расчёты цен (объёмные скидки, мультивалютность)
- Генерация коммерческих предложений (PDF, потоки согласования)
- Подписочное ценообразование (месячное/годовое, пропорциональное начисление)
Тестирование интеграций
- REST/SOAP API интеграции с внешними системами
- Outbound-сообщения и platform events
- Синхронизация данных с ERP и маркетинговыми системами
- SSO/SAML интеграция для аутентификации
Практическое задание
Разработайте тест-кейсы для потока lead-to-cash:
- Захват лида: Отправка веб-формы создаёт лид с корректным маппингом
- Автоназначение: Лид назначен нужному менеджеру по правилам территории
- Скоринг: Действия engagement повышают балл; порог вызывает оповещение
- Конвертация: Лид конвертируется в Account + Contact + Opportunity без потери данных
- Этапы сделки: Прохождение каждого этапа, проверка обязательных полей
Руководство по решению
Тесты захвата:
- Отправить форму с обязательными полями → лид создан с корректными значениями
- Отправить с существующим email → сработала дедупликация
- Отправить с невалидным email → показана ошибка валидации
Тесты конвертации:
- Конвертация без существующего account → новые Account, Contact, Opportunity
- Конвертация с существующим account → Contact добавлен к существующему Account
- Проверить корректность маппинга кастомных полей
Советы из практики
- Тестируйте с реалистичными объёмами данных — governor limits ведут себя иначе на масштабе
- Проверяйте порядок срабатывания правил валидации и отсутствие конфликтов
- Тестируйте процесс обновления sandbox — устаревшие sandbox вызывают несогласованности
- Всегда тестируйте под разными профилями пользователей — безопасность на уровне полей различается
- Автоматизируйте регрессионное тестирование с помощью Provar, Copado или Salesforce CLI
Ключевые выводы
- Тестирование CRM фокусируется на точности процессов и целостности данных в жизненном цикле клиента
- Governor limits Salesforce делают тестирование на масштабе обязательным
- Ролевое тестирование доступа критично — разные пользователи должны видеть разные данные
- Автоматизации Salesforce (триггеры, flows, правила валидации) нужно тестировать на взаимодействия