E2E test creator/player

⚠ The current problem statement

Automated end-to-end test creation with minimal to no coding. Consultants in most of our implementation projects tend not to encourage leveraging End-To-End testing because of the lack of tool for ease of creation of tests or maintenance. In some cases, clients tend to give this topic a lower priority because of budget constraints. In some cases where it is possible to lead those activities, the implementation of test cases requires a large effort in coding where a developer is involved or a QA with programming skills is required which isn't always possible to meet. This leads them in those cases to limit the number of test cases to be too few. The usual recommendation from our consultants on the implementation project is "we recommend you to test" or "it is your responsibility to test" but we have a challenge in elaborating how to do it efficiently at low cost (self-managed and on GWCP). Our official testing tool for UI is GT-UI, it takes however some work to get it up and running and the downside of it is that the user needs to learn the tool, set it up, and then still do all the required scripting to get the tests running and it doesn't include automation in test creation. Certain commercial tools could help with test automation, such as Testcafe premium or selenium but some programming could be hardly avoided. The challenge with using those tools (although Testcafe is our standard now for cloud customers) is test case migration. How do we solve the challenge of migrating customers from Selenium to TestCafe? What happens in the future if we want to migrate to a newer tool? Would we then have to reprogram the tests again? The test case creation should be business oriented and abstracted from the technical implementation, and the technical part should be as small as possible. Our recommended tools should provide that and be flexible and able to adapt to the evolving markets' needs. Standardization of tools and using standard representation of tests: Our recommended representation of tests is the Gherkin files, which contain a human readable language representation of the test case. Our organization's current recommendation is to use a short description of the test case in those files, and hide the details in the technical implementation. This, although following a recommendation of avoiding lengthy Gherkin files, hinders the possibility on expanding in a larger set of automation because it requires more effort. The QA should be able to define the case by telling, on this page I want to press button 1 and then button 2, and then enter a certain text in a field, and they shouldn't need to worry about the syntax of the Gherkin file nor the technical layer behind it. Test case Generation with Gherkin human readable language is currently not possible, we have to write the tests manually and then implement the details every time even when we are using our standard GT-UI tool. End-To-End test cases do not have a tool to orchestrate complex test scenarios in multiple systems. Creating a policy through QuoteAndBuy (or a newly created MicroFrontend with JDP), then verifying the policy exists in PC, and then creating an FNOL to it seems very difficult to automate. The difficulty turns harder when comparing Self-Managed customers and GWCP customers. Running the generated tests with cucumber and Testcafe. This tool does not replace our official UI-Testing tool (GT-UI) but we can integrate it into it. The tool should also be able to orchestrate digital and insurance suite application e2e tests

👔 The future customers

Self-Managed customers and cloud customers. Observed and implemented an advanced version of the tool for VHV

💡 The idea & benefits

Currently we have a version of the tool used by our client VHV that I led to its creation. The technical details: We start the test creation from the test manager page, from which we start the desired flow. We are able to listen to Jutro events in the browser and build the actions that the user performs on the page in a similar way to google analytics. This does not require any change in the application itself. The tool saves the steps and maps them to page to create a scenario. The user can go back to the test manager page and they are presented with a list of pages and actions on each page. They can perform modification to the test case in a user friendly page (breaking down the test cases to pages, and steps on each page with actions and parameters which can be modified (text fields such as FirstName or PostalCode, etc). The tool generates a standardized Gherkin file to describe the testcase. The user is able to modify the test case in the browser and click: "Run test case" which in turn, runs the test case directly from the browser. When the QA is happy with the testcase, they can include the Gherkin file in the source code, and then the tests will be run in the CI-Pipeline. This is also helpful for developers who want to implement/test a functionality on the last page of a flow here wizard that has 15 pages, instead of clicking at each page for every change. Since the recorder works with JavaScript and does not require React, it is possible to listen to the events created via other technologies, such as AngularJS or others. This, however, we did not test at VHV because we didn't have a use case for it. This, however, we would need when we start implementing the orchestration part with other systems such as PolicyCenter. Our client VHV has a standard for using Selenium with Java where they have their own libraries and tools. I was exposed to this at the time we (internally in Guidewire) selected TestCafe as our standard tool for E2E testing for GWCP customers and I have decided for the VHV team that the only way forward is the test configuration files that we can export in the future into our standard tool whenever the cloud migration takes place. Otherwise it would cost us and the client a huge amount of effort and cost. This pattern we managed to migrate at VHV with minimal effort. We now use Testcafe as a test runner (for self-managed customer) while the QAs focus on their test case creation. At VHV, in our digital implementation we had to implement almost 300 test cases at a very short time, and we are not able to include a certain portion of code for each test case in order to ensure it runs successfully. Test case Generation with Gherkin human readable language, running the generated tests with cucumber and Testcafe. This tool does not replace our official UI-Testing tool (GT-UI) but we can integrate it into it as it makes creating the test cases much easier. The tool should also be able to orchestrate digital and insurance suite application e2e tests, which we haven't implemented yet. End-To-End test cases do not have a tool to orchestrate complex test scenarios in multiple systems. Creating a policy through QuoteAndBuy (or a newly created MicroFrontend with JDP), then verifying the policy exists in PC, and then creating an FNOL to it seems very difficult to automate. The difficulty turns harder when comparing Self-Managed customers and GWCP customers. Running the generated tests with cucumber and Testcafe. This tool does not replace our official UI-Testing tool (GT-UI) but we can integrate it into it. The tool should also be able to orchestrate digital and insurance suite application e2e tests

Easy way to create End-To-End test cases, QA focus on test cases, high level of automation, less workload on the teams (Devs and QAs), focus on delivery and high quality of work rather than repeating the work everytime, upgradability between the versions as we abstract the test cases from the technology, migration of test cases for self-managed customer to GWCP, stretching the standards as much needed to fit the purpose (Gherking, Cucumber, TestCafe), possibility to integrate in our standard tool (GT-UI)

ⓘ Additional information

Please get in touch with me for discussions/demo or any further documents you require

Sept 30: @joshhooks1 to follow up with Ziad to agree on the next best action / or ‘home’ for this idea

July 2:

Ziad did another short demo for Chris, Josh and Ian Morris.

Next steps: Ian is helping run an internal initiative to build JDP apps for Commercial lines (maybe SBTs)? And he thinks he can have them install and pilot this out. Ziad to clean up his solution and share.

Josh to stay in the loop, but I think we can consider this moved to Deliver for now, and if things go well, figure out how to get the word out about it.