Frequently Asked Questions

CenterTest is an enterprise-grade, Java-based test automation framework developed by Kimputing.

At its core, CenterTest is a powerful, fully extensible automation platform capable of all testing modalities against any system accessible through Java: web apps, third-party applications, APIs, legacy systems, custom portals, and external integrations.

Built on top of this foundation are supercharged layers specifically designed for Guidewire InsuranceSuite: intelligent generators that build your test assets directly from your Guidewire source code, abstraction layers, version compatibility tools, and pre-built scenarios that cover hundreds of InsuranceSuite workflows across every line of business.

One tool handles all your testing needs. If you can touch it with Java, you can test it with CenterTest.

CenterTest Version Compatibility enables organizations to build comprehensive test coverage on their pre-Cloud implementation, then use those same scenarios to validate Cloud deployments on day one. This is Day One testing: pre-Cloud scenarios define expected behavior, and any differences in Cloud surface as test failures to investigate and resolve.

Most pre-Cloud carriers are performing only manual testing, or have basic automation that would not survive the migration regardless. CenterTest provides a path to meaningful automation that transfers directly to Cloud.

Beyond migration validation, CenterTest enables in-sprint testing during the migration project itself. You do not have to wait until UAT, when there is no way to prevent or identify regression. Development teams can validate changes within the same sprint they are built, catching issues before they compound. The result is compressed migration timelines, earlier issue detection, and higher confidence at go-live.

The CenterTest framework itself does not use AI, machine learning, or agentic processes. CenterTest is a deterministic, locally-deployed Java-based test automation framework. Test execution produces consistent, reproducible results every time.

Kimputing introduced AI-assisted development support in 2025 using Model Context Protocol (MCP) servers combined with AI coding assistants. The MCP servers provide context; your AI coding assistant uses that context to provide guidance. One does not work without the other.

These AI tools assist with scenario creation, debugging, analytics, and documentation lookup, but they operate independently of the core framework. Organizations can adopt AI assistance when ready, or operate CenterTest entirely without AI involvement.

No. CenterTest is deployed locally within customer environments. There is no cloud dependency, subscription service, or external data transmission. This architecture enables rapid deployment in secure, air-gapped, or highly regulated enterprise environments without external dependencies. The core framework does not use AI, machine learning, or agentic processes.

Day One testing means organizations can begin automated testing immediately when a new environment deploys, whether for initial Cloud migration or routine Cloud version updates (ski resort updates). Using scenarios already developed and validated on the previous version, teams validate the new environment from day one without waiting to build test automation from scratch.

This capability applies to both migration and ongoing operations:

• During Cloud migrations, pre-Cloud scenarios validate the new Cloud deployment immediately. CenterTest's Version Compatibility is the only way to bring meaningful pre-Cloud automation into Cloud.

• During Cloud version updates, existing Cloud scenarios validate the new ski resort update on day one.

• During active development, in-sprint testing validates changes within the same sprint they are built, catching regression before it compounds.

The result is dramatically compressed timelines and higher confidence for migrations, version updates, and ongoing development. Testing becomes a continuous activity rather than a phase that happens after development completes.

When Guidewire releases ski resort updates, CenterTest absorbs changes through regeneration. The widget abstraction layers understand differences between Cloud releases, and CenterTest Self-Healing handles most modifications automatically. Scenarios continue functioning without requiring manual updates for routine version changes.

For structural changes that do require attention, compile-time detection identifies affected scenarios immediately after regeneration. Your team knows exactly what needs review before executing a single test, rather than discovering issues through runtime failures.

CenterTest's reusable architecture makes maintenance efficient even when changes are required. A fix to a single reusable propagates to all scenarios that use it. Data structures adapt as well, so updates to shared test data flow through to all dependent scenarios. Maintenance effort scales with the number of unique workflows, not the number of scenarios.

CenterTest supports all Guidewire versions from v7 through the latest Cloud release, including the complete alphabet of ski resort updates.

A single CenterTest implementation can test multiple Guidewire versions simultaneously, enabling organizations to validate upgrades, run parallel environments, or support post-acquisition platform consolidation.

CenterTest supports the complete Guidewire InsuranceSuite: PolicyCenter, BillingCenter, ClaimCenter, and ContactManager. The framework also supports digital portals including Producer Engage and Customer Engage.

Beyond Guidewire, CenterTest can integrate with any external system in your testing workflows, including rating engines, document management systems, payment processors, or legacy policy administration systems.

CenterTest includes a multi-layered architecture of reusable components, abstract base classes, helper utilities, and widget interactions that serve as building blocks for rapid scenario creation.

The framework also includes hundreds of end-to-end test scenarios covering common and designated function workflows, plus pre-configured flows spanning all Guidewire InsuranceSuite out-of-the-box lines of business.

Each reusable encapsulates dozens of underlying operations, so a single call like PC.createPersonalAutoSubmission() orchestrates page navigation, field population, validation handling, and wizard progression automatically.

CenterTest is built on Java, but you do not need to be a Java developer to use it effectively. Test scenarios read like plain English.

All scenarios are data-driven, so Java skills are only needed when extending the framework or creating new scenarios or reusables. No programming expertise is required for day-to-day test data management, test execution, or reviewing results. Test data is managed in common-language, object-oriented data structures, allowing business teams to easily define and expand test coverage.

Tests can be kicked off via pipeline (Jenkins, Azure DevOps, TeamCity, GitHub Actions, etc.), allowing anyone to trigger test suites without touching code. CenterTest integrates with all major test management platforms (TestRail, SpiraTest, ReportPortal, etc.), giving all stakeholders access to test results and CenterTest Output.

Yes. CenterTest provides sophisticated end-to-end UI testing with native understanding of Guidewire widgets, Page Configuration File (PCF) page structures, and asynchronous rendering patterns.

Unlike generic Selenium or Playwright wrappers that interact with raw HTML elements, CenterTest understands Guidewire's widget type system: dropdown searches, shuttle lists, date pickers, modal dialogs, wizard navigation, LVs (list views), DVs (detail views), and dynamic content loading all work out of the box without custom wait logic or brittle XPath expressions.

Yes. CenterTest supports API testing for custom integrations, Guidewire Cloud APIs (including Edge APIs), and third-party services. API tests can execute as standalone scenarios or integrate within end-to-end UI workflows for comprehensive validation.

This enables hybrid testing patterns where a scenario might seed data via API, validate UI behavior, then verify downstream system updates through additional API calls.

Yes. Any functional end-to-end scenario, including UI and API tests, can be repurposed for performance, load, and stress testing by configuring parameters such as ramp-up time, thread count, and iteration limits.

This eliminates the need for separate performance testing software, specialized scripts, or duplicate test maintenance. Your functional regression suite becomes your performance baseline.

Yes. CenterTest supports both document generation validation and content validation. CenterTest can directly open and parse PDFs for content verification, including analysis by line, by section, or by pattern matching.

The framework tracks document generation timing and enables validation of data both passed in through DDT (such as insured names and addresses) and generated during test execution (such as policy numbers and effective dates). This is critical for validating dec pages, policy documents, billing statements, and claims correspondence.

Yes. Starting from version 5.5, CenterTest provides built-in accessibility testing using the Axe core engine.

The framework can analyze any page during test execution and generates detailed Excel reports covering violations, passed rules, and impact-level statistics (Critical, Serious, Moderate, Minor). This capability supports portal testing against WCAG standards and helps organizations identify accessibility issues before they reach production.

CenterTest enables sophisticated, realistic end-to-end testing by supporting multiple concurrent user connections within a single scenario.

Each user (defined by role and permissions) operates in their own browser session while sharing data between sessions. For example, a scenario might have a producer create a submission, then an underwriter review and approve it, then a billing clerk verify the invoice, all within one coordinated test execution. This mirrors real-world workflows where multiple personas interact with the same business transaction.

Multi-user, multi-session processing increases test execution efficiency by:

• Maintaining active sessions: Each session stays logged in throughout the scenario rather than repeatedly logging in and out, eliminating authentication overhead.

• Parallel execution: Independent operations across different users or Centers can execute concurrently, reducing total execution time.

• Shared test data: Generated data like account numbers, policy numbers, and claim numbers pass seamlessly between sessions, enabling true end-to-end validation.

This architecture allows a single scenario to orchestrate realistic workflows spanning multiple users, roles, and Guidewire Centers while maximizing execution speed.

Yes. CenterTest supports integration with enterprise password vault solutions through custom API integrations.

Organizations can connect CenterTest to their existing credential management infrastructure, including solutions like Keeper, CyberArk, AWS Secrets Manager, or Azure Key Vault. This integration enables secure credential retrieval at runtime, eliminating the need to store sensitive credentials in test code or configuration files.

The credential management architecture supports:

• Dynamic credential retrieval: Test scenarios request credentials from the vault at execution time rather than relying on stored values.

• Role-based access: Different test users can authenticate against different vault policies based on their defined roles.

• Credential rotation: When vault credentials rotate, tests automatically use updated values without code changes.

• Audit compliance: All credential access flows through your organization's existing vault audit logging.

This approach aligns with enterprise security requirements while maintaining the flexibility CenterTest provides for multi-user, multi-session test execution.

Yes. CenterTest scenarios can span PolicyCenter, BillingCenter, ClaimCenter, and portals within a single test execution. Each application operates as an independent session, and sessions share data to enable true end-to-end workflow validation across the entire InsuranceSuite.

To support efficient test execution, CenterTest uses multi-user, multi-session capabilities and parallel processing to allow each session to stay active (without logging in and logging out), and share test execution data across sessions.

A single scenario can create a policy in PC, verify the account in BC, file a claim in CC, and validate billing adjustments, all while tracking the policy number, claim number, and other generated data across systems.

Yes. While optimized for Guidewire, CenterTest is a sophisticated automation platform capable of testing across entire IT ecosystems.

The framework can test third-party applications, external APIs, legacy systems, custom portals, rating engines, document repositories, and any system accessible through Java.

Yes. CenterTest separates role definitions from credential management to enable flexible permissions testing. Test scenarios define users by logical role names.

Roles are managed in backend property files, and credentials are managed (typically) via a vault API, both completely separate from test code. This architecture enables two powerful testing patterns:

• Validate end-to-end workflows using users with global permissions, then swap credentials in the property files to test with restricted roles, all without modifying a single line of test code.

• Run the same scenarios with different permission sets to verify access controls systematically.

This makes it easy to verify that producers cannot access underwriter-only functions, confirm that read-only users cannot modify records, or validate that sensitive fields are hidden from unauthorized roles.

Yes. CenterTest handles Single Sign-On (SSO) and Multi-Factor Authentication (MFA) workflows that are common in enterprise Guidewire deployments.

The framework can navigate SSO redirects, handle authentication prompts, and manage session tokens across test execution. For MFA scenarios, CenterTest supports integration with authentication providers and can work with TOTP (time-based one-time passwords) or other verification methods depending on your security configuration.

CenterTest source-code generators read the entire structure of your Guidewire Centers and automatically create test framework assets directly from Guidewire source code.

The generators produce page object models (POMs), type list enums, product model helpers, and utility classes. Without powerful, purpose-built automation asset generators for Guidewire test automation, it is impossible to ensure test assets remain perfectly synchronized with your specific Guidewire configuration.

CenterTest Generators power Version Compatibility, and they convert complex Guidewire elements into easily understood, common-language formats to enable rapid test development and increase transparency into test execution for business teams.

Regeneration is the process of re-running CenterTest Generators against your Guidewire source code to update your test framework assets.

When your Guidewire implementation changes through updates, migrations, feature enhancements, or new product launches, regeneration synchronizes your page object models (POMs), type list enums, product model helpers, and utility classes with the current state of your Guidewire environment. This process completes in minutes and produces test assets that reflect your exact configurations.

Regeneration enables several critical capabilities:

• Branch synchronization: Keep test code branches aligned with both your existing implementation and active development environments.

• Developer-owned regression testing: Developers can regenerate and run tests against their own changes before deployment, catching issues in the same sprint they are introduced.

• Shift-left testing: By integrating regeneration into CI/CD pipelines, teams validate changes continuously rather than discovering issues during UAT.

• Test-driven development: Authoritative, synchronized test assets enable teams to treat tests as the source of truth for expected behavior.

Combined with CenterTest Self-Healing, reusable architecture, and data-driven framework, regeneration transforms test maintenance from a reactive burden into a proactive quality practice.

For Guidewire-specific automation, yes. However, Kimputing does not need to access your Guidewire source code, and CenterTest Generators produce your automation framework through read-only access.

CenterTest Generators are easy to run, operate entirely within your secure environment, and Guidewire source code never leaves your infrastructure. CenterTest does not maintain a constant connection to your Guidewire source repositories. For Cloud customers, source access is available through Guidewire's standard repository access.

For testing non-Guidewire systems, no Guidewire source access is needed. CenterTest can automate external applications, APIs, and integrations using standard web automation and API testing patterns without any Guidewire dependencies.

CenterTest Generators create four categories of test assets:

• Page Object Models (POMs): Strongly-typed widget references for all PCF pages across PolicyCenter, BillingCenter, ClaimCenter, ContactManager, and portals. Each widget is represented by its correct type (WidgetInput, WidgetSelect, WidgetDatePicker, etc.), enabling IDE autocomplete and compile-time validation.

• Type List Enums: Java enum classes replacing hardcoded strings with compile-time validated type list values. Instead of typing "Draft" and hoping it matches, you use PolicyPeriodStatus.Draft and the compiler catches typos.

• Product Model Objects: Typed accessor methods for coverages, conditions, exclusions, and modifiers across all configured lines of business.

• Helper Utilities: Data sharing utilities that facilitate communication across test execution contexts, enabling scenarios to pass policy numbers, account names, and other generated data between reusables and across Centers.

Standard generators scrape rendered HTML and create generic element references based on IDs, CSS classes, or XPath expressions. During development, or when Guidewire makes changes during Cloud updates, those locators break.

CenterTest Generators read PCF files directly from Guidewire source code, understanding the widget type system rather than HTML output.

Consider the difference when setting a first name field:

Standard XPath approach:
driver.findElement(By.xpath("//input[@id='SubmissionWizard:LOBWizardStepGroup:LineWizardStepSet:PADriversScreen:PADriversPanelSet:DriversListDetailPanel:DriverDetails:FirstName']")).sendKeys("John");

CenterTest approach:
page.getFirstName().set("John");

The XPath locator breaks whenever Guidewire restructures the DOM, renames element IDs, or changes the page hierarchy. The CenterTest accessor remains stable because it references the logical widget definition from the PCF, not the rendered HTML output.

Generated POMs use specialized CenterTest widgets that understand Guidewire-specific behaviors: asynchronous loading, wizard step validation, shuttle list interactions, and modal dialog handling all work automatically.

Initial generation completes in minutes. The generator reads your Guidewire source directory and outputs all page objects, type lists, and product models in a single coordinated process.

After generation, teams can begin scenario development immediately. Regeneration after Guidewire upgrades or configuration changes is equally fast, keeping your test assets synchronized with minimal effort.

Yes. CenterTest provides separate generation modes: GENERATEPAGES, GENERATETYPELISTS, GENERATEPRODUCTMODEL, and GENERATEALL.

While running GENERATEALL is most common, individual artifact types can be regenerated independently when needed. There is no required sequence for generation.

CenterTest Version Compatibility enables test scenarios to execute across any supported Guidewire version, from v7 through the latest Cloud release, with minimal modification. Pre-Cloud automation transfers directly to Cloud environments. Carriers can take ski resort updates faster, and with increased confidence, while avoiding resource-intensive refactoring of automated tests.

Version Compatibility is not a discrete feature. Instead, it emerges from several CenterTest features and architectural components working together.

• CenterTest Generators: Keep test code branches in sync with the unique Guidewire source code configurations for any given environment.

• Widget abstraction layers: Handle version-specific Guidewire rendering differences internally, so the user doesn't have to modify test code.

• Intelligent data handling: Allows the same test data to easily power scenarios executing against different versions of Guidewire.

The business impact is significant. Existing test coverage easily survives ski resort updates, and your pre-Cloud automation can start validating your Cloud migration code from day one, not late into the project when you finally get to UAT. Version Compatibility transforms testing from a manual, time-consuming, end-of-project cost, into a durable, long-term strategic asset to future-proof your Guidewire investment.

CenterTest Time Travel enables automated testing of date-sensitive workflows by combining date conditions with Restart Points to suspend and resume scenarios when appropriate dates are reached.

Many insurance workflows depend on specific dates: policy renewals, billing cycles, delinquency processing, claims aging, regulatory compliance deadlines, and document generation. Time Travel allows scenarios to define date conditions, suspend execution until those conditions are met, then resume automatically.

CenterTest supports three primary date condition types:

• Exact match: isOn(date) suspends until the system clock matches a specific date.

• Threshold conditions: isOnOrAfter(date), isAfter(date), and isBefore(date) suspend until the clock reaches or passes a threshold.

• Calculated dates: Relative calculations like getRenewalDate().minusDays(45) suspend until a computed date based on policy events.

Positive calculations move forward from the policy effective date while negative calculations move backward from the expiration date. This flexibility enables comprehensive lifecycle testing. The OOTB test suite includes over 50 time travel conditions across 8 lines of business, demonstrating patterns for renewals, delinquencies, disbursements, suspense payments, and cancellation workflows.

Time Travel is enhanced by supporting features:

• Best Day calculation: When multiple scenarios require different dates, CenterTest identifies the optimal next date to minimize clock changes while maximizing the number of suspended scenarios that can resume.

• Automated clock changes: CenterTest can automatically change and synchronize system clocks across PC, BC, and CC to continue execution of suspended time travel scenarios.

• Self-Managed Execution: CenterTest monitors suspended scenarios and automatically resumes them when date conditions are satisfied.

This architecture enables comprehensive lifecycle testing spanning policy creation, renewals, billing cycles, delinquencies, and claims in coordinated scenarios rather than isolated tests.

Yes. CenterTest can automatically change and synchronize clocks across all Guidewire Centers to ensure proper environmental coordination and enable expansive automation.

Alternatively, CenterTest can suspend scenarios with time travel requirements in restart mode and recommend the optimal date for manual clock changes.

When multiple suspended scenarios have different date requirements, CenterTest identifies the next best day to change the system clock so the maximum number of suspended scenarios can resume.

This Best Day calculation minimizes the number of clock changes required, dramatically reducing overall execution time while expanding the number of time travel scenarios that can execute simultaneously.

CenterTest Narratives transform technical test executions into business-readable documentation.

Originally developed as Reverse-BDD, CenterTest Narratives produce human-readable output directly from test execution, providing business stakeholders with clear understanding of test coverage without implementing complex Cucumber or Gherkin frameworks.

CenterTest Narratives can generate output in natural language format or Given/When/Then Gherkin style based on organizational preference.

The default is natural language showing the flow, with Gherkin available as an additional format. Language configuration files support localization for international teams.

Traditional BDD requires complex, time-consuming Cucumber scenario creation that is only feasible after Guidewire development completes. This process is brittle, difficult to scale, and requires specialized support.

CenterTest Narratives reverse this approach, generating human-readable output from executed scenarios. Business teams provide requirements through DDT spreadsheets and receive narrative output for easy consumption, without the Cucumber complexity.

CenterTest Analytics collects three types of primary data:

• Execution Data: Basic test execution data, pass/fail, timings, and test-generated data like account, policy, and claim numbers.

• Runtime Data: Comprehensive capture of every click, field setting, and timing for each action, assertion, and process.

• PCF Change Data: Identification of PCF changes between Guidewire versions and/or configurations.

CenterTest automatically provides the following test code analytics:

• Coverage Analytics: Uses PCF Change Data to determine if configuration changes are covered by a particular test or test suite, or during a period of time for all test executions within a specific environment.

• Trend Analytics: Monitoring of execution patterns over time to identify slowdowns, environmental issues, and stability patterns.

CenterTest does not include pre-built executive dashboards because every organization has different reporting needs and stakeholder requirements.

Instead, CenterTest integrates with all major test management and reporting platforms (TestRail, ReportPortal, SpiraTest), allowing you to build custom dashboards tailored to your specific needs. CenterTest's reporting API can easily be extended to new or custom reporting tools.

Plus, the CenterTest Analytics database is directly accessible with a documented schema for easy, direct data analysis and custom queries. Organizations can query execution trends, identify flaky tests, track performance over time, and surface patterns that would be invisible in standard pass/fail reporting.

Supported by CenterTest AI-assisted development tools, non-technical teams can easily create custom reports, and technical teams can quickly turn those reports into permanent, repeatable queries.

PCF Coverage Analytics identifies every change between PCF fields and properties across two Guidewire versions, tracking added, modified, and deleted elements.

During test execution, CenterTest monitors widget interactions and maps them to known PCF modifications. Reports show exactly which customized elements have been tested versus which remain uncovered.

This matters because CenterTest knows what you changed during development and knows whether or not you have tested it, giving you confidence that your customizations are validated before release.

CenterTest Output refers to the comprehensive set of artifacts and data produced during test execution.

CenterTest provides test execution results via your test manager of choice, allowing you to customize reports and stakeholder dashboards. CenterTest Analytics records comprehensive test execution data for every click, every set, every assert, and much more. This enables your teams to perform custom analytics to uncover meaningful trends in failures and performance.

CenterTest also provides a tremendous amount of optional test output based on the type and purpose of your test: video recordings, assertion logs, scheduled or failure-triggered screenshots, Playwright trace files, plain-English narrative reports, execution analytics, and test-generated data like policy and account numbers.

Yes. CenterTest provides full single-stream recording of test execution from start to finish across all browser interactions.

Recordings include overlays identifying actions at the test level, such as field settings with the interacted field highlighted. This creates visual documentation that non-technical stakeholders can review to validate test coverage.

CenterTest Output bridges the gap between technical execution and business understanding.

Video recordings allow stakeholders to watch test execution and validate that scenarios match expected workflows. Narrative reports translate technical steps into plain-English documentation that business analysts can review without reading code. Assertion logs provide detailed evidence of what was verified and when. Screenshots capture the application state at critical moments or upon failure. Playwright trace files enable developers to step through execution for debugging.

Combined, these artifacts provide comprehensive documentation for compliance, audit requirements, and stakeholder sign-off, all without requiring technical expertise to interpret.

Screenshots are automatically captured when a test fails, or when scenarios throw assertion exceptions. This feature can be disabled.

Additionally, the takeScreenshot capability allows explicit screenshot capture at any point during execution, regardless of pass/fail status. Screenshots upload automatically to connected test managers and are stored with the test execution results.

CenterTest implements an Object-Oriented Data-Driven Testing (OODDT) architecture that minimizes data bloat while maximizing coverage scalability.

Test data references logical entity names rather than raw values, with shared data sheets enabling single definitions that propagate across multiple scenarios. This means you define a "StandardDriver" or "CaliforniaAddress" once and reference it everywhere, rather than duplicating data across hundreds of test rows.

Traditional approaches require each test row to contain all data values. CenterTest defines entities once and references them by name. Changing a standard address updates one entity rather than hundreds of cells. Override columns allow scenario-specific variations while inheriting defaults, making intent clear while minimizing data surface area.

Additionally, test data does not need to change during Guidewire migrations and upgrades. Tests are smart enough to ignore blank values for non-required fields, enabling a single scenario to drive hundreds of test variations through DDT without updating test code.

When combined with the shared OODDT approach, this maximizes test coverage while limiting the amount of test code and data you have to maintain.

Yes. Business teams provide test requirements through familiar Excel spreadsheet formats.

Object references use logical names that business users understand, and override columns clearly show which values differ from defaults. No programming expertise is required to manage test data.

CenterTest supports automated data seeding to generate accounts, policies, claims, and other business entities at scale. Teams specify parameters and quantities, and CenterTest creates fully-formed data through the UI or API, complete with all required relationships and valid business data.

Use cases include:

• Environment preparation: Populate test environments with realistic data volumes across Guidewire Centers.

• Performance testing: Generate thousands of policies for load simulation.

• Edge case validation: Create specific data combinations for boundary testing.

• Demo and training environments: Seed consistent, repeatable data for demonstrations or user training.

• Integration testing: Create Guidewire data that triggers downstream processing in external systems.

• Exploratory testing support: Seed policies for BillingCenter manual testing, or seed applications and complex workflows to a specific point so your manual testing or product teams can take over from there.

Seeding scenarios are data-driven, so modifying quantities or data variations requires only spreadsheet changes. No code updates are needed.

Seeding is the fastest way to achieve rapid time-to-value with CenterTest. Before you extend automation to cover complex workflows, you can use CenterTest to seed the accounts, policies, and claims needed to accelerate your manual testing teams.

Seeding eliminates the "create test data" burden that consumes manual testing time. Instead of spending 20 minutes creating an account and policy before testing a claim, testers request seeded data and begin exploration immediately from any workflow stage: account created, policy bound, claim filed, or any other checkpoint.

This provides:

• Faster testing: Testers focus on validation, not setup.

• Repeatability: The same data configurations can be regenerated across environments or after refreshes.

• Consistency: All testers work with properly-formed data, eliminating "bad test data" as a failure cause.

• Cross-system readiness: Seeded data can trigger integrations, ensuring external systems have corresponding records for end-to-end manual testing.

CenterTest Pause Processing enables hybrid automation and manual testing within a single execution.

Automation executes to a defined point and pauses, allowing testers to manually interact with the application for exploratory testing or validation. When exploration completes, testers signal CenterTest to resume automation. This integrates exploratory testing into automated flows without separate environments.

Restart Points and Pause Processing serve different purposes:

• Restart Points enable suspension and resumption after failures, environmental waits (like time travel clock changes), or debugging. They are checkpoints for recovery and efficiency.

• Pause Processing enables intentional stops during successful execution for manual interaction, including exploratory testing, visual validation, or stakeholder demonstrations.

Both support hybrid testing approaches. Restart Points suspend scenarios for automated resumption, while Pause Processing integrates human judgment into automated workflows.

CenterTest Data Studio is a simple interface for the data behind CenterTest's data-driven tests. Business and test analysts change that data themselves, in a familiar grid, without development knowledge and without waiting for an engineer. Editing the Excel spreadsheets directly is still supported. Test data links across many workbooks. CenterTest Data Studio follows every link for you, so you see the values a test run will actually load, where each value comes from, and everything else that depends on it. CenterTest Data Studio runs on your own machine, requires no AI, and checks the whole project for broken links, duplicates, and loops as you work.

Everyone who works with CenterTest test data. Business and test analysts change test data themselves, without development knowledge. They pick values from a list of what is valid, and guided changes keep everyday edits safe.

QA leads get that input into their data-driven tests without waiting for an engineer. Automation developers use CenterTest Data Studio to power their tests and extend it for new requirements, and they can add the same project check to the CI pipeline, so bad data stops before it reaches a test run.

CenterTest Data Studio is a lightweight program that runs on your own machine, with no cloud deployment and no server or repository dependencies. It edits the test data behind CenterTest's data-driven tests: the same workbooks your scenarios load when they run.

Test data links across many workbooks. CenterTest Data Studio follows every link for you, so you see the values a test run will actually load, where each value comes from, everything that depends on it, and where it is used.

It is a tool for everyday business analysts, subject matter experts, and QA testers. Teams can run CenterTest Data Studio on its own or launch it from the CenterTest IntelliJ plugin.

CenterTest's data-driven architecture and its OODDT principles prevent data bloat, by reusing test data rather than copying it. Define a record once and reference it by name, then scale coverage by adding new data or combining different sets of shared data. Your workbooks stay lean as coverage grows.

Working with data in the spreadsheets was always easy. CenterTest Data Studio makes it easier. Rename a code in CenterTest Data Studio and every reference to it follows, so shared data stays consistent as it grows.

Yes. CenterTest Data Studio checks the whole project as you work and flags broken links, duplicates, and loops in your test data.

Your CI pipeline can run the same check and stop before bad data reaches a test run. The pipeline check runs without opening the editor and returns a result the pipeline can act on.

No. CenterTest Data Studio sends no user data and no test data out. Its only routine outbound requests are update checks, which fetch public release files. There is no telemetry, analytics, crash reporting, or license check.

CenterTest Data Studio needs nothing installed. It is one self-contained program, with no installer and no Java required. Run it on its own or launch it from the CenterTest IntelliJ plugin.

It runs on your own machine and works behind corporate proxies. It updates only when you choose to, after checking that the download is genuine.

CenterTest Recorder turns a business analyst's walkthrough of a process into a video, written steps, screen-by-screen clicks, the data entered, and the checks that matter, all in one package your whole team can use.

The analyst walks through the process once and talks it through. Business teams no longer write step requirements by hand, and the automation team starts from a documented, checked walkthrough, which shortens the automation lifecycle and speeds up delivery.

CenterTest Recorder works in PolicyCenter, BillingCenter, and ClaimCenter.

CenterTest Recorder serves the whole team. Business analysts record the process as they already do it, and the automation team starts from that recording to build tests faster.

The same recording, with your analyst's commentary when voice recording is turned on, works for training new staff, documenting how the process really runs, and showing exactly what happened when something breaks, as well as for automation.

A CenterTest Recorder recording includes five things:

• Video: A replay of the whole walkthrough.

• Written steps: A plain-text test script, ready to copy.

• Every click, screen by screen: Each click, with a picture of each screen.

• The data entered: Every value typed or chosen.

• The checks that matter: The fields, values, and messages your analyst marks to verify.

Turn on voice recording and your analyst's commentary is recorded with the walkthrough, so the reasons behind each step are kept with the steps.

It can! Business teams record the process as they already do it, and CenterTest Recorder writes it down for them as plain-text steps, ready to copy, with every click, value, and check captured screen by screen.

With voice recording turned on, the analyst's commentary is kept with the steps, so the reasons behind each step travel with the requirement. The same recording then goes to the automation team as the starting point for the test.

CenterTest Recorder is far more than a recording. It is comprehensive documentation of a business flow, test case, or user scenario, including the navigation between Centers, so true end-to-end workflows are captured. Your automation team starts from a documented, checked walkthrough, which shortens the automation lifecycle and speeds up delivery.

The recording speaks CenterTest's language. The checks your analyst marks map onto CenterTest assertions, and the field names in the recording match the ones CenterTest Generators produce from your Guidewire configuration. The automation team then builds the test in CenterTest from the recording.

CenterTest Recorder obfuscates passwords, tokens, and other sensitive values before anything is saved. It has no outside dependencies, and you save recordings wherever you choose.

Share the whole package, or pull out only the piece you need: the step flow, a single screenshot, or the video.

CenterTest Recorder needs no installer, no administrator rights, no browser extension, and no Java. It uses the Chrome or Edge already on your machine and works in PolicyCenter, BillingCenter, and ClaimCenter.

It also starts from Run Recorder in the CenterTest IntelliJ plugin. Beyond the browser, an analyst needs access to the test environment being recorded. CenterTest Recorder has no outside dependencies and is light enough for anyone to use.

Training takes about an hour. CenterTest Recorder is light enough for anyone to use, with nothing to install and no browser extension to add.

Your business analyst records the process the way they already work: walking through it at normal speed and, with voice recording on, talking it through. CenterTest Recorder captures the steps, clicks, data entered, and checks as the analyst goes.

Reusables are modular, self-contained components that encapsulate common workflow steps. Each reusable (such as LoginToPC, CreatePersonAccount, or CreateClaim) can execute independently or chain with other reusables to form complete scenarios.

CenterTest includes a comprehensive library of out-of-the-box reusables covering common Guidewire operations. These are not simple functions; each reusable is built on layers of abstract base classes, helper utilities, and widget interactions, so a single call like PC.createPersonalAutoSubmission() orchestrates dozens of underlying operations automatically.

When changes occur in your Guidewire configuration (during updates, migrations, feature enhancements, etc.), fixing the impacted reusable automatically updates all scenarios using that component. A single update propagates across the entire test suite without modifying individual scenarios.

If you have 500 scenarios that use CreatePersonAccount, and Guidewire changes the account creation wizard, you fix it once in the reusable and all 500 scenarios work again. This architecture ensures maintenance effort scales with the number of unique workflows, not the number of scenarios.

Traditional shared functions are static utilities without context. CenterTest reusables provide:

• Strong typing where each reusable is a distinct class with IDE-tracked usage.

• Context injection providing browser, assertions, and data without global variables.

• Composability allowing reusables to chain operations fluently.

• Impact analysis through IDE Find Usages showing all affected scenarios.

Yes. Teams can extend existing reusables or create new ones to meet the requirements of their unique Guidewire configuration. Custom reusables are built from the same generated assets as CenterTest's OOTB reusables, ensuring consistency and enabling the same maintenance benefits.

Compile-Time Detection catches structural changes to your Guidewire configuration that would cause tests to fail. It identifies removed widgets, renamed elements, changed type list values, and product model modifications.

During regeneration, CenterTest Self-Healing fixes many of these errors automatically. Compile-Time Detection identifies whatever remains, so you can quickly refactor your reusables before executing your tests.

This process minimizes the need to "debug" your tests during development changes, preventing runtime failures by allowing you to systematically identify and perform any necessary refactoring before test execution.

Compile-time detection prevents:

• Scenarios running for minutes before failing on missing elements.

• String typos in locators causing cryptic element not found errors.

• Type list value changes causing silent data mismatches.

• Product model changes causing null pointer exceptions deep in execution.

After running CenterTest Generators against an updated Guidewire codebase, CenterTest Compile-Time Detection immediately identifies errors for every affected scenario in your test project.

CenterTest Self-Healing operates through the regeneration architecture rather than runtime AI or machine learning.

When Guidewire changes occur, generators regenerate framework assets from updated source code. The abstraction architecture hides locator changes and widget type modifications within framework layers, allowing existing scenarios to continue functioning without modification.

CenterTest Self-Healing through regeneration handles:

• Locator changes when Guidewire modifies CSS IDs or element positioning.

• Widget type changes when Guidewire updates implementations between versions.

• DOM structure modifications during ski resort updates.

• Version-specific rendering differences across Guidewire versions.

When elements are removed rather than repositioned, compile-time detection surfaces these changes immediately after regeneration.

The Java compiler identifies every scenario referencing the missing element, enabling systematic resolution before test execution.

CenterTest Restart Points are checkpoints within scenarios that enable resumption from specific stages rather than starting over from the beginning.

When a scenario fails, encounters an environmental issue, or requires a pause for external conditions (such as clock changes or document generation), the scenario suspends at the most recent checkpoint. Execution can then resume from that checkpoint when conditions are met, dramatically reducing debugging and re-execution time.

Restart Points support multiple suspension patterns:

• Failure recovery: Resume from the last checkpoint after fixing an issue rather than re-executing the entire scenario.

• Time travel workflows: Suspend scenarios until the system clock reaches a required date, then resume automatically or manually.

• Document validation: Suspend until asynchronous document generation completes, then resume to validate content.

• Environmental waits: Suspend when environments are temporarily unavailable and resume when access is restored.

This suspension and resumption architecture transforms how teams handle long-running scenarios, environmental instability, and date-dependent workflows.

Restart Points eliminate wasted time and resources by allowing scenarios to suspend and resume rather than restart from the beginning after every interruption.

Benefits include:

• Prevent false failures: Environmental issues like network timeouts, screen delays, or temporary unavailability no longer cause permanent test failures. Scenarios suspend at the last checkpoint and resume when conditions improve.

• Preserve test data: Without Restart Points, failed tests leave behind orphaned accounts, policies, and claims that clutter your test environment. Restart Points allow scenarios to resume and complete using data already created, keeping environments clean.

• Faster debug cycles: Complex scenarios, especially those that require time travel, may be difficult or time-consuming to start from the beginning. Debugging a failure no longer requires re-running the full test or resetting environments or clocks. Simply resume from the last checkpoint and begin debugging in minutes.

• Handle asynchronous processes: Document generation, batch job completion, and external system responses may take variable time. Restart Points allow scenarios to suspend until these processes complete, then resume validation.

• Reduce manual intervention: Scenarios that previously required manual investigation, restart commands, or environment fixes can now self-recover from transient issues automatically.

This suspension and resumption architecture transforms test maintenance from reactive firefighting into efficient, automated operations.

Time travel scenarios require clock changes between execution phases. Restart points before time-dependent steps allow scenarios to suspend until clock changes occur (automated or manual), then resume from the checkpoint.

This enables comprehensive lifecycle testing spanning policy creation, renewals, billing cycles, and claims without re-executing from the beginning after each clock change.

Document generation may require variable time depending on system load. Restart points before document validation allow scenarios to suspend until generation completes, then resume for validation.

This prevents false failures from timing issues while ensuring thorough document testing.

Yes. A single scenario can have multiple restart points at different stages, such as after account creation, after policy binding, and before claims processing.

This flexibility enables precise suspension points based on where issues occur or where external dependencies exist.

CenterTest Self-Managed Execution allows CenterTest to monitor test execution results and automatically rerun failed tests, or restart suspended tests from their most recent Restart Point.

The system can rerun failed scenarios and restart specific scenarios from their unique point of failure, removing the need for DevOps involvement in routine test management.

Environmental issues, timing problems, and transient failures often cause scenarios to fail without indicating actual defects.

Self-Managed Execution distinguishes between environmental issues and true failures by automatically retrying failed scenarios. Resuming suspended scenarios and tracking retry patterns reveals how often scenarios fail, enabling identification of flaky tests through CenterTest Analytics.

Self-Managed Execution monitors suspended time travel scenarios and automatically resumes them when date conditions are satisfied.

When time travel scenarios suspend at Restart Points waiting for specific dates, Self-Managed Execution:

• Tracks suspended scenarios: Monitors which scenarios are waiting for which date conditions.

• Coordinates with Best Day calculation: Identifies the optimal next clock change that allows the maximum number of suspended scenarios to resume.

• Automatic Clock Changes: Self-Managed Execution can automatically change and sync the system clocks across PolicyCenter, BillingCenter, and ClaimCenter to enable rapid, hands-off time travel test automation.

• Triggers automatic resumption: When the system clock reaches required dates (through automated clock changes or manual adjustments), Self-Managed Execution resumes eligible scenarios automatically.

• Handles failures intelligently: If a resumed scenario fails, Self-Managed Execution can retry from the appropriate Restart Point based on configured parameters.

This automation enables large time travel test suites to execute with minimal human intervention. Teams define date conditions in their scenarios, and CenterTest handles the orchestration of suspension, clock coordination, and resumption across the entire suite.

No. Self-Managed Execution operates within CenterTest, or can be triggered via CI/CD pipeline parameterization.

The feature requires no additional infrastructure beyond the normal test execution environment.

CenterTest provides pre-built integrations for ReportPortal, TestRail, and Inflectra SpiraTest. Results synchronize in real-time during execution, with screenshots, video recordings, and Playwright trace files uploading automatically. This gives stakeholders immediate visibility into test progress and results without waiting for post-execution reports.

ReportPortal also provides a well-designed MCP (Model Context Protocol) server, allowing enterprise customers with AI agent deployments to easily perform custom analytics on test execution data.

Yes. While pre-built integrations exist for ReportPortal, TestRail, and SpiraTest, the integration architecture is extensible.

CenterTest is built to integrate easily with external systems. Other test management platforms, including homegrown solutions or enterprise tools like Jira with Xray or qTest, can be supported quickly and cost-effectively.

CenterTest integrates with all major CI/CD platforms including Jenkins, Azure DevOps, GitHub Actions, GitLab CI/CD, and TeamCity.

Because CenterTest is a standard Java repository using Gradle, any pipeline that can execute Gradle commands can run CenterTest. There is no proprietary runner, no special agents, and no vendor lock-in to a specific CI/CD platform.

Yes. Organizations can automate framework regeneration through CI/CD pipelines that run before or after Guidewire deployments. This ensures test assets always reflect the actual Guidewire environment without manual intervention or human error. DDT class regeneration from spreadsheets can also be automated, keeping test data structures synchronized with spreadsheet changes.

Automated regeneration is valuable during all Guidewire development activities: CI/CD updates, feature enhancements, product launches, new integrations, and Cloud migrations. The pipeline can regenerate, compile, and flag any breaking changes before tests even execute.

Yes. CenterTest supports version-specific execution through repository branching and CI/CD parameterization. Since test codebases and generated assets differ between Guidewire versions, organizations typically maintain separate branches for each version and configure their pipelines to select the appropriate branch at runtime.

This capability is valuable in several scenarios: organizations running parallel environments (development, QA, staging, production) on different Guidewire versions during upgrade cycles; carriers who acquire other business units through M&A and must support multiple Guidewire configurations; and carriers who manage multiple Guidewire configurations based on integrations with other systems.

Bring-Your-Own Testing (BYOT) is Guidewire's framework enabling organizations to integrate external testing tools into Guidewire Cloud Platform. Guidewire recognized that its GT Testing framework was not meeting the complex needs of its customers, so it opened the door to BYOT to provide carriers with more flexibility and options.

For carriers migrating to Cloud, CenterTest is uniquely positioned to leverage BYOT. CenterTest's Version Compatibility is the only way to bring meaningful pre-Cloud test automation into the Cloud environment. Without a tool that bridges Guidewire versions, there is no practical path to preserve testing investments during migration.

The Bring-Your-Own Testing framework consists of three pillars:

• Notifications: Webhook callbacks triggered by CI/CD events that can automatically initiate external test pipelines.

• Integrated Pipelines: Mechanisms to propagate external test results back into Guidewire Cloud Platform.

• Quality Gates: Pre-configured criteria using test results to enforce merge and promotion decisions.

Guidewire Cloud Quality Gates are configurable verification checkpoints within the Guidewire Cloud Platform CI/CD pipeline.

Quality Gates integrate testing results to provide visibility into code quality and can block artifacts from progressing through deployment stages when verification criteria are not met. For carriers investing in test automation, Quality Gates represent the mechanism to enforce testing standards and prevent untested or failing code from reaching higher environments.

Organizations can configure webhook notifications for pre-merge events (when pull requests are created or updated) and pre-promotion events (when builds are ready for promotion). These notifications trigger external test pipelines automatically based on CI/CD activity.

This enables shift-left testing: CenterTest can begin validating changes as soon as a developer opens a pull request, catching issues before code merges rather than discovering them after deployment.

CenterTest provides the testing capabilities needed to satisfy Quality Gate requirements:

• Webhook consumption: CenterTest can receive CI/CD event notifications to trigger scenario execution automatically.

• Verification API integration: Execution results propagate to Quality Gates through the CI/CD Manager API, appearing in Guidewire's native tooling.

• Pre-merge and pre-promotion support: CenterTest scenarios can serve as verification criteria at either pipeline stage.

• Designated functions coverage: CenterTest includes comprehensive designated function scenarios that help carriers meet Guidewire's testing requirements.

CenterTest provides the testing tool with CI/CD integration capabilities. Your team or CI/CD architects configure the pipeline to leverage CenterTest execution and results.

Designated functions are business-critical workflows that Guidewire requires customers to test as part of Cloud deployments.

These functions represent core insurance operations (policy issuance, claims creation, billing transactions, and similar workflows) that must be validated to ensure system integrity after customizations or upgrades. Guidewire publishes the list of designated functions, and carriers are responsible for demonstrating test coverage against them.

Yes. CenterTest includes hundreds of out-of-the-box scenarios covering most common workflows for major lines of business, including comprehensive designated function coverage across PolicyCenter, BillingCenter, and ClaimCenter.

Examples of CenterTest reusables that align with Designated Functions requirements include:

• PC.createPersonalAutoSubmission() for policy issuance workflows

• BC.makeDirectBillPayment() for billing transaction validation

• CC.createPersonalAutoClaim() for claims creation and management

• PC.createCancellation() for policy lifecycle operations

• BC.createDelinquency() for billing exception handling

For carriers starting their Cloud journey, designated functions coverage is often one of the first deliverables from a CenterTest implementation, since it addresses an immediate Guidewire requirement while building the foundation for broader test coverage.

Quality Gates control two types of artifacts:

• Commits awaiting merge into the main branch.

• Builds awaiting promotion to higher star systems (environments).

Guidewire Cloud supports two Quality Gate types:

• Default Gates: Predefined gates managed by Guidewire with built-in validation mechanisms requiring no additional customer testing investment. Currently includes deployment checks verifying application status before build promotion.

• Custom Gates: Customer-defined verification criteria integrating results from external testing investments. Custom Gates enable organizations to bring their own testing tools into the InsuranceSuite CI/CD pipeline.

Guidewire Cloud supports Quality Gates at two pipeline stages:

• Pre-Merge: Block commits from being merged in Bitbucket until verification criteria pass. Status appears as merge conditions in the Bitbucket interface.

• Pre-Promotion: Block builds from being promoted to higher star systems until verification criteria pass. Status appears in the Build Promoter app.

Quality Gates display the following statuses:

• Passing: All required verification criteria met, artifact can proceed.

• Failing: Required verification criteria failed, artifact blocked.

• Passing with warnings: Required criteria passed but optional criteria failed, artifact can proceed with noted concerns.

• Pending: Verification in progress, awaiting results.

• Not configured: Quality Gates not established for this stage.

Yes. Kimputing provides a no-cost trial implementation, a Minimum Viable Product (MVP) process, typically completing within two weeks.

A CenterTest architect and automation engineer work directly with your Guidewire environment to create comprehensive, end-to-end, data-driven scenarios designed to your specifications. The MVP demonstrates CenterTest capabilities against your actual implementation (not a demo environment) so you see exactly how the framework handles your customizations, workflows, and data structures. Unlike a throwaway proof of concept, scenarios created during the MVP become production assets if you proceed.

The no-cost MVP is designed as a "try before you buy" implementation, to validate that CenterTest meets your organization's most critical business needs related to test automation.

It can provide:

• Working scenarios: CenterTest data-driven scenarios (typically designated functions), validated against your actual Guidewire environment, configurations, integrations, and workflows.

• Hands-on experience: The opportunity for your team to observe the CenterTest development and implementation process.

• Production-ready assets: Scenarios implemented during the MVP are production ready. There is no throwaway work, giving you a jumpstart to CenterTest implementation.

• Integration validation: Confirmation that CenterTest works with your unique architecture, including SSO/MFA authentication flows, credential management, document handling, and connections to critical external systems that you need to test.

No financial commitment is required.

The time commitment from your team is approximately 4-8 hours over the course of the MVP, depending on the complexity of your environment, architecture, and Guidewire configurations. Kimputing encourages your team to shadow during the MVP for hands-on exposure before formal training, which accelerates adoption if you proceed.

Scenarios created during the MVP become production assets immediately. This is why we call it a Minimum Viable Product rather than a proof of concept: you are not evaluating throwaway work; you are building the foundation of your automation practice.

Every implementation is different, and automation is never truly "complete" since coverage continues to expand as your testing needs evolve. That said, CenterTest's architecture enables rapid time-to-value.

For mono-state, mono-line carriers operating close to Guidewire out-of-the-box (such as a Work Comp mutual carrier), comprehensive automation across PolicyCenter, BillingCenter, and ClaimCenter can deploy in approximately 30 days. For multi-state carriers, core Designated Functions coverage across eight or more lines of business typically requires a similar timeframe.

More states, more lines of business, and more configurations increase the calendar time required, but not necessarily the complexity. CenterTest's data-driven architecture means a single submission scenario per line of business can drive test coverage across all operating states simply by adjusting the test data. You write the scenario once, then scale coverage through data variations rather than duplicating code.

The critical factor is CenterTest's reusable architecture, which creates exponential growth in implementation speed over time. Every reusable component, every shared data structure, and every validated integration accelerates future development. The more scenarios you implement, the faster new requirements incorporate into your test suite. Early implementation builds the foundation; subsequent expansion leverages that foundation for rapid delivery.

For organizations also testing non-Guidewire systems (rating engines, document repositories, external APIs), those integrations develop alongside Guidewire automation using the same framework and patterns.

CenterTest implementation follows four phases, though Pre-Deployment and Deployment often run concurrently:

• Pre-Deployment: The no-cost MVP process validates core architecture and framework functionality against your Guidewire implementation. This phase includes evaluation of your environment (including any integrated external systems), analysis of testing priorities, and automation strategy development aligned with your release cycles.

• Deployment: CenterTest setup, framework generation against your Guidewire source, and core scenario implementation. Kimputing begins implementing scenarios that do not require specific workflow clarification or business team input, delivering designated functions and happy-path testing immediately while setting the foundation for more complex workflows.

• Solution Scaling: Coverage expansion across additional lines of business, Centers, non-Guidewire integrations, and CI/CD pipeline integration.

• Optimization: Establishment of maintenance processes, HealthCheck reviews, and continuous improvement aligned with Guidewire upgrade cycles.

CenterTest Generators read your Guidewire source code (PCF files, type lists, and product model definitions) and automatically create strongly-typed test framework assets: page objects, type list enums, product model helpers, and utility classes. This generation process completes in minutes and produces test assets perfectly synchronized with your specific Guidewire implementation, including all customizations.

Full setup, including prerequisites installation, repository configuration, and verification testing, typically completes within one to two days. Teams can begin scenario development immediately after setup verification.

CenterTest requires standard development tooling that most Guidewire teams already have:

• JDK 11+ for Java-based test execution.

• IntelliJ IDEA (Community or Ultimate) as the development environment.

• Git for version control and test asset management.

• CenterTest plugin for IntelliJ providing framework integration, scenario templates, and productivity features.

No specialized infrastructure, cloud services, or additional licensing is required beyond these standard tools. Because CenterTest is a Java framework, it can leverage any Java library for testing non-Guidewire systems. REST clients, database connectors, document parsers, and other utilities are integrated natively into the CenterTest framework.

For organizations looking to fully outsource their test automation, or those with small IT teams, Kimputing can set up and manage these requirements on your behalf.

For Guidewire-specific automation, yes. The generators require access to Guidewire source code (specifically PCF files, type lists, and product model definitions) to create strongly-typed test assets. Generation runs entirely within your environment, and Guidewire source code never leaves your infrastructure. CenterTest does not maintain a constant connection to your Guidewire source repositories. For Cloud customers, source access is available through Guidewire's standard repository access.

Running the generators is straightforward. A member of your team can easily run generation without providing Kimputing access to your source code, then share only the generated automation framework output for MVP development or ongoing collaboration.

For testing non-Guidewire systems, no Guidewire source access is needed. CenterTest can automate external applications, APIs, and integrations using standard web automation and API testing patterns without any Guidewire dependencies.

CenterTest supports execution through Playwright (the current default) and Selenium.

The engine abstraction layer ensures scenarios remain unchanged regardless of which engine executes them, enabling adoption of new automation technologies as they emerge.

Kimputing provides flexible engagement models to match your needs and internal capacity:

• Project-based engagements: Targeted initiatives like rate testing validation, performance testing, Cloud migration support, designated functions coverage, or integration testing for external systems.

• Automation practice building: Team training, framework customization, and knowledge transfer to build internal capability.

• Migration and upgrade support: Pre-Cloud to Cloud transitions, ski resort version upgrades, and multi-version validation.

• Ongoing partnership: Help desk access, periodic HealthCheck reviews, framework maintenance during Guidewire upgrades, and scenario development support.

Unlike other QA organizations and system integrators, Kimputing's business model is not built on becoming a permanent managed-services provider in your organization. While we can provide fully-outsourced automation services, we prefer partnership models that help you deliver automation value quickly, then transition to independent operation. You call on Kimputing when necessary (for example, during major projects or Guidewire upgrades) rather than maintaining ongoing dependency.

Typically, Kimputing provides a small team of insurance-domain specialists with expertise in both test automation and Guidewire InsuranceSuite. This team works with the appropriate SMEs and testing teams within your organization to enable rapid implementation and immediate ROI to your organization.

Kimputing brings the Guidewire testing experts, while your SMEs provide business context and validation. For scenarios involving non-Guidewire systems, Kimputing works with your integration teams to understand external system behaviors and incorporate them into end-to-end test coverage.

Team structure evolves as automation matures. Many organizations transition from Kimputing-led development to internal teams handling day-to-day operations, with Kimputing providing periodic support, HealthChecks, and upgrade assistance.

Yes. CenterTest is designed for customer independence.

After onboarding, your team can create new scenarios, extend reusables, manage test data, and execute test suites without ongoing Kimputing involvement. The framework's strongly-typed architecture means standard Java skills and IDE tooling (autocomplete, Find Usages, refactoring) handle most development tasks. CenterTest's readable code patterns mean scenarios are maintainable by anyone familiar with basic Java. No specialized framework expertise is required for day-to-day operations.

Support options include traditional documentation and help desk access, as well as AI-assisted support through the CenterTest MCP. Once your implementation reaches appropriate maturity, AI tools can assist with stacktrace analysis, refactoring suggestions, test writing guidance, and debugging.

This independence extends to non-Guidewire automation as well. Teams comfortable with Java can add API tests, external system validations, and custom integrations using standard patterns.

Upon licensure, Kimputing provides comprehensive hands-on training tailored to your desired business outcomes and team structure.

Training topics can include:

• Framework fundamentals: CenterTest architecture, project structure, and execution modes.

• Scenario development: Creating tests, using reusables, extending base classes, and writing assertions.

• Data-driven testing: DDT spreadsheet configuration, entity references, and coverage scaling.

• Framework maintenance: Generator usage, regeneration workflows, and handling Guidewire changes.

• Test manager integration: Configuring ReportPortal, TestRail, SpiraTest, or other platforms.

• Non-Guidewire automation: Patterns for testing external APIs, web applications, and integrated systems using the same framework.

Training uses your actual Guidewire environment (not generic examples) so your team leaves ready to create production scenarios immediately.

Kimputing combines deep Guidewire platform expertise with decades of enterprise test automation experience.

Our team includes ACE-certified Guidewire developers and test automation experts who have worked with Guidewire since its inception. We understand insurance operations: underwriting workflows, billing cycles, claims processing, regulatory requirements, and the carrier-specific variations that make every implementation unique.

This dual expertise matters because effective Guidewire test automation requires more than testing skills. You need people who understand why a submission follows a particular wizard flow, how billing cycles interact with policy changes, and what compliance requirements drive claims processing rules. Kimputing brings that context to every engagement.

We also bring proven patterns for extending automation beyond Guidewire to rating engines, document management systems, payment processors, and other integrated systems. We help your test coverage span your entire ecosystem, not just your Guidewire implementation.

Most CenterTest implementations require only one SDET (Software Development Engineer in Test) or QE (Quality Engineer) to support automation for your entire organization.

CenterTest is designed to minimize the expertise required for ongoing maintenance:

• Readable code patterns: Scenarios read like plain English, so basic Java familiarity is sufficient for day-to-day operations.

• Reusable architecture: Fixes to shared components propagate automatically across all scenarios, reducing maintenance scope.

• IDE tooling: Standard IntelliJ features like autocomplete, Find Usages, and refactoring handle most development tasks without specialized framework knowledge.

• Data-driven scaling: Business teams can expand test coverage through Excel spreadsheets without touching code.

For organizations without dedicated test automation staff, or those wishing to fully outsource their automation practice, Kimputing provides managed services directly or through implementation partners. You do not need an army of testing experts or engineers to manage your CenterTest implementation. One qualified engineer working with your subject matter experts can effectively manage the deployment.

CenterTest HealthCheck is a manual analysis process Kimputing performs using custom internal tools. During HealthCheck reviews, Kimputing examines your test code and data to identify optimization opportunities and ensure your test suite remains efficient and maintainable as it scales.

Think of HealthCheck as a periodic tune-up for your automation practice. As test suites grow organically, patterns emerge that create unnecessary maintenance burden or execution inefficiency. HealthCheck identifies these patterns before they become problems.

During HealthCheck reviews, Kimputing identifies common inefficiencies:

• Reusable candidates: Manual code duplicated across multiple scenarios that should become shared reusables.

• DDT utilization: Separate scenarios that could merge into a single data-driven scenario with multiple test data rows.

• Data review: Redundant test data entries that could consolidate through entity reuse and shared references.

• Pattern deviations: Code that deviates from CenterTest best practices in ways that will create maintenance challenges as the suite scales.

HealthCheck reviews are most valuable:

• After significant test suite expansion (adding new lines of business, new Centers, or major feature coverage).

• As part of periodic optimization, typically quarterly for active implementations.

• Before major Guidewire upgrades, to identify scenarios that may need attention.

Kimputing can include HealthCheck reviews as part of ongoing support agreements, or perform them on-demand as part of project engagements.

Licensed customers receive:

• Help desk access: Direct support for questions beyond documentation, including architecture guidance and troubleshooting assistance.

• Framework maintenance: Updates and compatibility patches when Guidewire releases new versions or ski resort updates.

• HealthCheck reviews: Analysis of your CenterTest implementation to identify opportunities for optimization, provided as needed or as requested.

• Optional Managed Services: Additional scenario development, custom integration work, or dedicated support for complex implementations as needed.

AI-assisted tools have significantly reduced the need for person-based support by providing instant answers to common questions. Teams can get documentation guidance, troubleshooting help, and code suggestions through AI without waiting for human response.

This does not eliminate human support. Kimputing's help desk remains available for complex questions, architectural decisions, and situations where AI guidance is insufficient. The goal is self-service for routine questions while preserving access to expertise when needed.

CenterTest does not directly integrate with AI in any way. Instead, Kimputing provides a stand-alone architecture that supports AI-assisted test automation development, implementation, and maintenance through MCP architecture.

MCP (Model Context Protocol) is an open standard that provides a client/server architecture enabling AI assistants to access context from multiple sources while maintaining security boundaries.

In the CenterTest context, the architecture includes multiple context sources:

• JetBrains MCP: Provides AI access to test code in your IDE workspace, enabling the assistant to understand your specific implementation patterns and test codebase.

• CenterTest MCP: Provides AI access to CenterTest documentation, troubleshooting guides, exception codes, Guidewire stack trace analysis, and framework patterns.

• ReportPortal MCP: For organizations using ReportPortal, this MCP provides AI access to test execution results, enabling automated test analysis, failure summarization, and trend identification directly through AI conversation.

• PostgreSQL MCP: A Model Context Protocol server providing read-only access to PostgreSQL databases, allowing for schema inspection and execution of read-only queries of data collected through CenterTest Analytics.

This architecture means AI assistants can combine context from CenterTest documentation, your specific test code, and execution results to provide powerful, relevant development support and powerful analytics without compromising security.

CenterTest's architecture provides AI-powered development assistants with the structure, context, and guardrails needed to deliver immediate value without complex infrastructure or risky integrations.

Why AI assistants are a perfect match for CenterTest:

• Common-language code patterns: CenterTest Generators produce readable, strongly-typed code. Reusables like PC.createPersonalAutoSubmission() and scenarios that chain plain-English method calls are easy for both humans and AI to understand, reducing the "perception gap" where AI suggestions miss critical context.

• Code Context: Hundreds of out-of-the-box tests and reusables, combined with secure access to your own growing library of tests, provide AI assistants with proven patterns to understand your implementation and best practices. This enables AI support that follows established conventions and proven testing patterns.

• Documented analytics schemas: CenterTest Analytics stores execution data in a documented database schema. Combined with PostgreSQL MCP access, this enables AI to perform sophisticated custom analytics and reporting through natural language queries.

• MCP architecture for context: Purpose-built MCP servers (JetBrains, CenterTest, ReportPortal, PostgreSQL) provide AI assistants with safe, scoped access to test code, documentation, and execution results. As your implementation grows, the AI's context improves automatically.

• Sandboxed execution: AI tools operate within defined boundaries, limiting risk of data exfiltration, prompt injection, or unintended modifications.

• No AI dependency in core framework: Because the core testing framework is deterministic and AI-free, no AI process is built on top of another. This independence means your AI-assisted tooling can evolve with the rapidly changing AI landscape without affecting your foundational test automation.

This architecture addresses a common enterprise challenge: organizations that simply layer AI onto existing processes often see no efficiency gains and shift resources from development to code review. CenterTest's structured, well-documented framework gives AI the authoritative context needed to provide genuinely useful assistance.

AI assistants can help with support, maintenance, development, and analytics:

• Documentation Intelligence: Instant answers to framework questions, property configuration, and usage patterns without searching through documentation.

• Widget Discovery: Search through generated page objects to find the correct widget references for UI interactions.

• Stacktrace Analysis: CenterTest-specific error diagnosis that explains what went wrong and suggests solutions based on known error patterns.

• Scenario Assistance: Guidance for creating new scenarios following established patterns from your existing test library.

• Debugging Support: AI can analyze failing tests, compare against working scenarios, and identify likely causes.

• Analytics Queries: Natural language questions against CenterTest Analytics and ReportPortal data to identify trends, flaky tests, and performance patterns.

• Refactoring Guidance: Suggestions for improving test code structure, identifying candidates for reusable components, and optimizing data-driven coverage.

• Mass Maintenance Support: When Guidewire changes require updates across multiple scenarios, AI can help identify patterns and suggest systematic fixes.

Large language models excel at many tasks. Deterministic testing is not one of them.

LLMs are inherently probabilistic: they do not reason (yet). They simply predict and generate likely outputs based on their training data.

This introduces variability that is fundamentally incompatible with test automation, where the same inputs must produce the same results every time. AI-native or AI-first testing tools embed this unpredictability into the core testing process, undermining the reliability that test automation exists to provide.

Beyond reliability, AI-integrated testing tools present practical challenges for enterprises:

• Increased cloud costs: AI-native solutions require ongoing cloud computing resources that scale with test volume.

• Uncertain sustainability: The AI landscape changes rapidly. Tools built entirely on AI foundations may require significant rework as models, APIs, and providers evolve.

• Security exposure: Integrated AI solutions can expose your environment, source code, and test data directly to LLMs, increasing risk of data exfiltration, prompt injection attacks, and PII exposure.

• Shifted workload without efficiency gains: Many enterprises deploying AI-first solutions report no net productivity improvement. They simply shift resources from writing code to reviewing AI-generated code.

CenterTest takes a different approach:

• Deterministic execution: The core framework produces consistent, reproducible, hallucination-free test results every time.

• Security architecture: Sandboxing, MCP boundaries, and isolated AI contexts prevent the risks associated with tightly integrated AI solutions.

• Optional adoption: Teams adopt AI assistance at their own pace. The core testing framework operates independently of any AI tooling.

• Future flexibility: Because the core framework has no AI dependencies, your AI-assisted tooling can evolve with the rapidly changing AI landscape. Updates to AI capabilities enhance your automation without destabilizing the foundation.

AI cannot achieve deterministic testing on its own. An AI generating test code might produce slightly different implementations each time, and an AI evaluating test results might interpret the same output differently across runs.

This is why CenterTest maintains a deterministic core framework while leveraging AI for tasks where it excels: documentation lookup, support, code suggestions and review, analytics, debugging assistance, and pattern recognition. The framework produces consistent, reproducible test results; AI assists with the development and analysis surrounding those results. This separation ensures you get the benefits of AI assistance without sacrificing the reliability your test automation requires.

Deterministic testing means that given the same inputs, test execution produces the same results every time. There is no randomness, no variability, and no unpredictable test behavior. The same test scenario run against the same application state will always pass or fail consistently.

This contrasts with non-deterministic approaches where outcomes can vary between executions due to timing, randomization, or external dependencies. Non-deterministic tests create "flaky" results that undermine confidence in test suites and complicate debugging.

Deterministic testing matters because:

• Reproducibility: When a test fails, you can reliably reproduce the failure to diagnose the root cause.

• Trust: Teams can trust test results as accurate indicators of application behavior rather than artifacts of test instability.

• Compliance: Audit and regulatory requirements often demand demonstrable, repeatable verification processes.

• Debugging efficiency: Consistent behavior means failures point to actual defects rather than environmental noise.

Yes. One of the most common inefficiencies in test automation is creating new scenarios when existing scenarios could cover the requirement through data variations. AI can analyze incoming test requirements against your existing scenario library and identify opportunities to expand coverage through DDT rather than new code.

For example, if a requirement asks for "test policy cancellation for California," AI might identify that your existing cancellation scenario already supports state variations through test data, and you simply need to add a California data row rather than writing a new scenario.

AI enables custom analytics by regular team members with no data analyst experience. Through natural language interaction, teams can query execution data, generate reports, analyze trends, and identify patterns without SQL expertise or data science skills.

CenterTest Analytics stores comprehensive execution data in a documented database schema that your AI assistant can access via the PostgreSQL MCP. In addition, the ReportPortal MCP provides AI access to test results, launches, and defect information.

Examples of questions AI can answer from your execution data:

• "Which scenarios have the highest failure rates this month?"

• "What is the average execution time for Personal Auto submissions, and has it increased recently?"

• "Show me all failures related to the payment processing step across all scenarios."

• "Which tests are flaky and should be investigated for stability issues?"

• "Compare this week's failure patterns to last week."

AI can also help Kimputing and your team develop permanent, persistent reports and dashboards for consistent stakeholder communication, without the need for constant AI involvement.

AI tools should access only:

• CenterTest documentation through CenterTest MCP.

• Test code, test data, and CenterTest configuration files in the active branch workspace via the JetBrains MCP.

• Test execution data via PostgreSQL MCP.

• Test execution data through ReportPortal MCP.

When used and deployed appropriately, AI tools should never be able to access:

• Guidewire source code or production application code.

• Production credentials, API keys, or database connection strings.

• Production data or personally identifiable information.

• Application runtime environments or live API endpoints.

• Code repositories beyond the active workspace branch.

Security for AI-assisted development relies on multiple layers that organizations can configure based on their requirements:

• Branch isolation: Test branches by design should not contain production code or Guidewire source.

• Directory scoping: JetBrains MCP and similar tools provide configuration to restrict AI access to specific directories, excluding credential files and sensitive configurations.

• Tool restrictions: JetBrains MCP includes a suite of tools that help restrict what AI agents can do, such as limiting file access, blocking certain commands, or requiring approval for specific operations.

• Code review: Standard review processes catch misplaced files before they reach AI-accessible branches.

• Data practices: CenterTest best practices require synthetic test data rather than production PII, ensuring sensitive information never enters test repositories.

Kimputing is committed to helping carriers stay on the cutting edge of AI security architecture as these practices mature.

No. Everything in CenterTest works without AI. The core framework does not use AI, machine learning, or agentic processes, so test execution produces consistent, reproducible results every time.

The MCP servers and skills Kimputing provides are optional additions for teams that already use an AI coding assistant. They assist with scenario creation, debugging, analytics, and documentation lookup, and they operate independently of the core framework. Organizations can adopt AI assistance when ready, or operate CenterTest entirely without AI involvement.

Any AI coding assistant your developers can run from a terminal. Kimputing's MCP servers and skills supply context to the assistant; the assistant itself is your choice. Almost every major AI provider offers a command-line tool, so your team uses the model your organization already approves.

CenterTest does not integrate with AI directly. The core framework runs the same way whichever assistant your team uses, or none at all.