ServiceNow UI Builder and Workspaces Testing and Acceptance Checklist

Test Layers and Scope Definition

UI Builder applications require testing across multiple layers: component layer (do individual components work), layout layer (does the layout display correctly), integration layer (do components connect properly to data sources and workflows), and user acceptance layer (do end users find the application useful).

Component testing is performed by developers: verify that form fields validate input correctly, buttons trigger the right actions, dropdowns populate with expected data. Layout testing confirms responsive design (the UI works on phone, tablet, desktop). Integration testing verifies that the UI connects to ServiceNow data and external systems. User acceptance testing involves actual end users validating that the UI meets their needs.

Entry and Exit Criteria

Entry criteria: all planned screens are built, data integrations are configured, access controls are defined, and a test environment matches production. Building testable applications requires completed configurations before testing starts.

Exit criteria for go-live: all components pass component testing, layout is verified on multiple devices, integrations work and have been tested, performance is acceptable (screens load within their agreed targets), accessibility requirements are met (keyboard navigation, screen reader compatibility), and end users have signed off that the UI meets requirements. Critical and high-severity defects must be resolved; cosmetic issues can be addressed post-launch.

Component Testing Checklist

For each form field or input component: does input validation work (required fields, data type validation)? Can users clear or reset the field? Do default values display correctly? For buttons: do they trigger the intended action, are they accessible via keyboard, do they provide user feedback (loading state, confirmation)? For dropdowns and lists: do they populate with correct data, does filtering work, can users search and select values?

Create an HTML table listing each component, its expected behavior, and test results. Document any defects found and their severity.

Responsive Design and Cross-Browser Testing

Test the UI on multiple devices: mobile (phone width, 320px), tablet (landscape and portrait), desktop (1920px wide). Verify layout adapts correctly and remains usable. Text should be readable without zooming; buttons should be large enough to tap on a phone.

Test on multiple browsers: Chrome, Firefox, Safari, Edge. Some functionality may work on one browser and fail on another. Responsive design libraries help, but manual testing catches subtle issues.

Performance and Load Testing

Measure page load time: from when the user navigates to the page until it is fully interactive. Compare against the agreed target. Test with realistic data volumes (if the UI loads a large table, test with a realistic row count, not a handful). Test with users in different geographic regions (latency varies).

Load testing: if the UI is expected to serve many concurrent users, test with multiple simultaneous users accessing the page. Does performance degrade, or does it stay responsive?

Accessibility and Keyboard Navigation

Test keyboard navigation: can users move through the UI using Tab, Shift+Tab, Enter, and arrow keys? Can all interactive elements be accessed via keyboard? Test screen reader compatibility: does a screen reader correctly announce form labels, button text, and validation messages?

Test color contrast: do text and background colors provide sufficient contrast for readability? Is information conveyed only through color (red for error, green for success)? If so, add icon or text alternatives so color-blind users understand.

Data Integration Testing

Verify that UI components correctly connect to data sources. A form should load data from the correct table, filter by the correct criteria, and display in the correct field. Test creating, reading, updating, and deleting data through the UI. Verify that changes in the UI appear in the underlying data, and vice versa.

Test error scenarios: if the database is unavailable, does the UI fail gracefully or show an error message? If data validation fails, is the error message clear?

User Acceptance Testing

Involve actual end users in testing. Provide them with test scenarios and ask them to complete tasks using the new UI. Observe their interactions and note where they get confused or frustrated. Does the UI meet their needs? Are any features missing?

Document findings and address critical issues before go-live. User feedback often reveals design issues that developers missed.

UI Builder testing should include accessibility testing to ensure usability for all users. Responsive design testing across device sizes and orientations is essential. Performance testing validates that custom applications built with UI Builder meet user expectations for responsiveness and load times.

Regression scope after a change to a shared component

Many defects that appear after launch come from changes the builder did not expect to touch the page. A shared component updated for one workspace can show up on several others. A platform upgrade changes a default that a page quietly relied on. The testing question is therefore less whether the new page works and more what else uses the thing that changed. Keep a register that lists each shared component and the pages that depend on it, and use that register to size every regression pass.

Choosing the regression set by type of change

A regression pass, step by step

1. Freeze the version of the page under test and record its identifier with the run.
2. Load a test data set shaped like production, including long text fields and records with missing values.
3. Run each test user through the journey, noting the first point where the page departs from the expected result.
4. Repeat the pass at phone width and at desktop width, because layouts often break at one size only.
5. Log each defect against the component as well as the page, so the cause is visible on the next pass.
6. After a fix, re-run only the affected dependencies, then run the full set once before sign-off.

Test data that exposes real defects

Happy-path data hides many of the problems users actually find. Build a small set that includes the awkward cases: a record with a very long title, an assignee who has since left the organization, a category with no children, and a linked record that has been deleted. Keep the set anonymized, and store it in a form that can be reloaded into each test instance, so every run starts from the same state and a difference between runs means something.

Triage rules for defects found in testing

Not every defect should hold a release. A cosmetic misalignment on a secondary page can be logged and scheduled. A wrong value shown to a user, a blank panel on a critical journey, or a control that accepts input it should reject should stop the release. Agree those categories before testing starts and write them into the sign-off record, so the decision is not argued again after the fact.

Questions about testing UI Builder pages

Can automated tests replace the manual regression pass?

They can cover stable, repeatable journeys, which is where most of the tester time goes. They do not reliably catch a layout that breaks at one width or a label that confuses users, so keep a short manual pass for those and automate the rest where the instance supports it. The automated test framework is the platform’s built-in tool for creating and running repeatable tests.

How many test users do we need?

Count one account per role with a distinct view, and add one account for a role that should see nothing on the page. More users rarely add coverage once the roles are distinct, and they add maintenance cost at every release.

Who should run user acceptance testing when the builder knows the process best?

The builder should not be the only tester. Ask a user from the affected team to run the scripted journeys without guidance, and record where they hesitate. Hesitation is a finding even when the page technically works.

How do we know the test set is still good enough?

Compare the defects found in production with the defects the test set caught. A production defect that the set could have caught means a missing case, and the case should be added to the set with a note explaining why it was missed.

Next step

The testing strategy and release evidence article covers what to keep afterwards.