I’d like to start a discussion about QA strategies for opportunity management workflows in Adobe Experience Cloud. Our team is debating whether to invest in automation tools or continue with our current manual testing approach, and I’m curious about others’ experiences.
We have approximately 35 opportunity workflows covering everything from lead conversion to deal closure, with numerous conditional branches, approval processes, and integration points. Manual testing takes our QA team about 80 hours per release cycle to validate all scenarios.
The automation reliability question is central to our decision. We’ve experimented with Selenium-based scripts for UI testing and API-level testing for workflow triggers, but we’re finding that workflow complexity makes automation brittle. Even minor UI changes break our scripts, and we spend almost as much time maintaining automation as we save in execution time.
On the other hand, manual QA coverage is comprehensive but slow, and we occasionally miss edge cases in complex conditional logic. We’re also concerned about regression testing as our workflow count grows. What’s been your experience balancing automation and manual testing for workflow validation in AEC?
Brittle automation against complex UI workflows is a well-documented failure mode — the fix is restructuring where automation operates, not abandoning it.
Diagnostic Steps
Audit your 35 workflows and classify each by change velocity (UI-heavy vs. logic-heavy) and regression risk. High-change, UI-heavy flows are poor automation candidates at the presentation layer.
Profile where your 80-hour manual cycle actually spends time — use a simple time-log for one release. Typically 60–70% concentrates on a subset of high-risk conditional branches, not uniform coverage.
Identify all integration touchpoints (CRM sync, Adobe Analytics event triggers, Marketo handoffs, approval APIs). These are your highest-ROI automation targets.
Review your Selenium scripts for selector strategy — if they rely on positional XPath or auto-generated class attributes from AEC’s UI components, that’s the brittleness source. Switch to data-testid attributes or stable ARIA roles (verify attribute availability in your version).
Evaluate whether your API-level tests target the REST endpoints directly rather than going through the UI to trigger workflow state transitions. Direct API testing is order-of-magnitude more stable.
Tuning Parameters / Structural Changes
Automation layer split: Target 80%+ of automation effort at API/service layer; restrict UI automation to smoke tests covering 5–8 critical happy paths only.
Selector resilience: Instrument your AEC custom components with explicit data-qa-* attributes if your team controls front-end configuration. Reduces selector breakage by an order of magnitude in practice.
Conditional branch coverage: Use boundary value and decision table techniques for manual testing of complex conditional logic — this addresses your edge-case miss rate more efficiently than scripted UI tests.
Test data management: Parameterize opportunity state fixtures (lead stage, deal value thresholds, ownership rules) at the API layer so regression suites cover branch combinations without manual setup overhead.
Approval workflow validation: Test Adobe Workfront or native AEC approval APIs directly via Postman/Newman collections in CI — these are stable and don’t break on UI releases (verify endpoint structure in your version).
Monitoring / Verification
Track automation ROI per release: log script execution time + maintenance time vs. equivalent manual time. If maintenance exceeds 40% of execution savings over three consecutive cycles, that test should revert to manual or be rebuilt at a lower layer. Set a hard threshold and review quarterly.
This draft is based on general Adobe Experience Cloud knowledge. It has not been verified against your specific version and environment. Practitioners: verify the steps and share your experience below.
We went through this exact evaluation last year. Our conclusion was that workflow automation works best at the API level, not UI level. Testing workflows through the UI is indeed brittle because Adobe updates their interface frequently. Instead, we use Postman collections to test workflow triggers, state transitions, and approval routing via REST API calls. This approach has 90% less maintenance overhead than Selenium scripts and actually provides better test coverage because we can validate backend state changes directly rather than inferring them from UI elements.
I’d argue for a hybrid approach. Automate the happy path scenarios and high-frequency workflows, but keep manual testing for edge cases and exception handling. In our practice, we’ve found that about 70% of workflow executions follow predictable patterns that are perfect for automation. The remaining 30% involve complex business logic, manual overrides, or integration failures that require human judgment to validate properly. Also consider that manual testing helps QA teams understand business processes better, which improves their ability to identify issues that pure automation might miss.
The API-level testing approach is interesting. How do you handle testing the actual user experience though? Workflows might execute correctly in the backend but still have UI issues that confuse users - incorrect field labels, missing validation messages, broken conditional visibility rules. Don’t you need some UI validation?
You absolutely need UI validation, but you can minimize it. We use visual regression testing tools like Percy or Applitools that take screenshots of key workflow screens and compare them to baselines. This catches UI breaks without requiring fragile element-level Selenium scripts. Combined with API testing for workflow logic, you get comprehensive coverage. For your 35 workflows, I’d estimate you could automate 25 of them at the API level, use visual regression for UI validation, and reserve manual testing for the 10 most complex workflows with heavy conditional branching. That would probably cut your 80-hour testing cycle down to 20-25 hours of execution plus maybe 10 hours of maintenance per release.
Don’t underestimate the cost of test data management in workflow automation. Opportunity workflows often depend on specific record states, user permissions, and related data. Creating and maintaining test data sets that cover all your scenarios can be more work than the automation itself.
Test data management is solved by using sandbox refresh automation and data seeding scripts. We maintain a set of SQL scripts that populate our test environment with realistic opportunity data covering all workflow scenarios. Runs in about 15 minutes and gives us a consistent baseline for every test cycle.
After following this discussion, I want to synthesize the key considerations for your QA automation decision:
Automation Reliability Assessment:
The reliability of workflow automation depends heavily on your testing approach. UI-based automation (Selenium, Cypress) for workflows has inherent fragility due to:
Frequent Adobe UI updates breaking selectors
Dynamic element loading requiring complex wait strategies
Difficulty validating backend state through UI observation
API-based workflow automation is significantly more reliable:
Adobe’s API contracts are more stable than UI implementations
Direct state validation eliminates inference errors
Faster execution (API calls vs. browser rendering)
Easier to parallelize for comprehensive coverage
For your 35 workflows, expect 85-90% automation reliability with API-based approach vs. 60-70% with UI-based approach. The maintenance burden difference is substantial - we spend about 5 hours per quarter maintaining API test suites vs. 20+ hours for equivalent UI automation.
Manual QA Coverage Strategy:
Manual testing should focus on areas where automation provides limited value:
New workflow implementations (initial validation before automating)
Complex conditional branches with >5 decision points
Workflows involving external integrations with variable response times
User experience validation (field placement, error message clarity, workflow guidance)
Exploratory testing for edge cases not covered in requirements
For established workflows with stable logic, manual regression testing provides diminishing returns. Your QA team’s domain knowledge is better applied to validating new features and exploring boundary conditions rather than repeatedly clicking through known-good workflows.
Workflow Complexity Considerations:
Break down your 35 workflows by complexity:
Simple (linear, <3 decision points): Fully automate at API level - 15-20 workflows
Implement visual regression testing for UI validation
Integrate automated tests into CI/CD pipeline
Expected outcome: 50% reduction in testing time
Phase 3 (Months 5-6): Optimize and refine
Create reusable test components for common workflow patterns
Establish maintenance schedule and ownership
Train QA team on automation maintenance
Reserve manual testing for complex workflows and new features
Expected outcome: 60-70% reduction in testing time
Based on your current 80-hour testing cycle, this approach should bring you down to 25-30 hours of combined automated execution and manual testing, with an additional 5-10 hours per release for automation maintenance. The initial investment is significant (probably 200-300 hours to build the framework and automate the first 25 workflows), but ROI is typically achieved within 3-4 release cycles.
The key insight from our experience: Don’t try to automate everything, and don’t test workflows the way users interact with them. Test workflows the way they actually execute - as a series of API-driven state transitions. Reserve UI testing for genuine user experience validation, not as a proxy for functional testing.