When you think of a software development tool you probably think of a platform or environment to develop software to support business functionality and/or end users/customers. In most cases you would be correct. But you can use the software development platform for more than just developing software. The developed software also needs to be tested to check whether the implemented functionality matches the intended functionality or not. Usually you would use a software tool, which sole purpose is to test the developed software or manually test the developed software. But you can also use the development tool as a test tool to support/implement (part of) your tests.

When you test your developed software you will perform different types of test. Different types of tests would be (among others):

  • Unit testing
  • System testing
  • (System) Integration testing
  • Chain testing

It makes more sense for some of the types of test to use the development tool as a test tool than for other types of test. To determine for which types of test it makes sense we will take a look at some of the advantages of the development tool as test tool:

  • The tests are implemented and executed using the development tool. Therefore, the tests are automated and they can be executed repeatedly.
  • The automated test has access to the same data resources and therefore test data can be prepared to the needs of the test and the to be tested software.
  • Most development platforms with integration possibilities (e.g. via (web)services) also have possibilities to create stubs. This will also contribute to the repeatability of the test scripts.
  • Most development platforms have the possibility to schedule action at predefined points of time or at a certain interval

There is also a disadvantages/impossibility of the development tool as a test tool:

  • In general, the development platform will not have the possibility to simulate an end user filling out a screen and clicking on buttons. 

Taking these advantages and disadvantage into account, it is most useful to use the development tool as a test tool for those tests that need to be repeatable, need data preparation and don’t have a UI to be tested. Therefore, I would recommend to use the development tool as a test tool for:

  • Unit testing of non UI-components
  • Parts of system testing (e.g. service interfaces offered by the system)
  • Parts of integration testing (e.g. ping services)

 

Examples

You can use any development tool as a test tool, but personally I’ve used Pega as both a development tool and a test tool. Here are some examples of how Pega is used as a test tool on some of the projects I’ve worked for:

Test activities 

I’ve used these test activities especially for unit testing. In a test activity you are able to setup data to test the functionality. After setting up the data you can call any part of the code you want to test. You can call something as small as a simple check (when-rule) or something as big as a complete (STP-)process (as long as there is no user interaction). 

Since you can also start activities using a URL to Pega, it is possible to call these test activities from an external source. So you can incorporate these test activities in your external third party tool.

When creating these test activities, you need to put some thoughts in how to split up the tests. Just as with all other rules you define within Pega you need to think about:

  • Reusability of test code

You can split up the test in different type of rules. Your test activity can use for example data transforms to setup the data before calling the actual rule you want to test. These data transforms can be used to setup different type of tests.

  • Location of test code (class and ruleset)

Pega is a platform which is based upon object orientation. So the code belongs to classes with an inheritance structure. So make sure the test code you develop is created in the correct classes to keep it clear, understandable and maintainable.

In Pega you are able to split up your code into different rulesets. These rulesets form logical packages of code that belong together. These packages are stacked upon each other and provide a different form of inheritance. You can think of these rulesets as a slice of your application that spreads over different classes. With this concept you can make sure that all code for testing is in a separate ruleset, which resides on top of the stack of rulesets. This way you can control in which environment you deploy the code for testing. Most likely you want your code for testing to be available in development environment and maybe also in the test environment. But you don’t want this code in the acceptance and production environment.

 

Integration Test Portal

It is very likely that you will need to call services from within your process or that your process will be made available as a service. To test the code to call these services or to test the service you provide you can create an integration test portal. The test portal I’ve build in Pega is able to distinguish dynamically the services called within your code (by listing the connectors). When selecting one of the connectors you can paste a request XML-message in the portal and send it to the service. The Response XML is also shown on screen. This will enable you to test all the code for xml parsing and streaming and also the connector itself.

The portal can also be used to check whether the connections are reachable and responding separately while testing your process. Otherwise it is possible that multiple services are having issues which is only discovered by going through your whole process each time to discover a next service having issues.

At one of the customers the “Integration Test Portal” was even put into production after applying the right security settings to the portal. So the portal was only accessible by the Operation-users of the DevOps-team. With this portal they were able to correct inconsistencies in the backoffice systems by calling the services using correct XML-messages. 

 

Service monitoring

Next to manually testing interfaces using a portal sending custom XML-messages you can also test them automatically by pinging them. When you ping a service you check if the connection can be made and a message can be processed. You do not test whether the functionality is working correctly. So you actually perform a technical infrastructure test.

You can ping a service by calling a specific ping-operation (if available) or by calling a read-operation (not to change actual (live) data) or by calling an update-operation for dummy data (also not to change actual (live) data).

This functionality can be scheduled in Pega using an agent (automatic background user). This way you are able to pro-actively monitor the connections from and to your system and detect any issue with a service before an end user encounters the issue. 

 

Consideration

When using the development tool for more than just developing business functionality, it will need time from the developers which they cannot spend on business functionality. You will need to plan and reserve time for this on the short term. But I’ve experienced that in the long run you will actually save time of developers (easier testing and finding issues sooner), testers (less test effort since issues are found sooner by developers) and also technical maintenance (supported by the test tooling in production it is easier to detect, analyse and solve issues) and therefore also save costs.

Although the examples are based on my experience I’ve had with Pega I hope this blog will inspire you to think outside the box and use your development tools as efficient and effective as possible. 

 

About René

René van Seuren Senior BPM Test BPMCompanyI am a Senior BPM Consultant and I like to work on complex integration issues combining processes on one side and service integration on the other side. I aim for short and long term solutions to satisfy both functional (business) and technical (IT/Ops and platform) needs. These solutions need to be understandable for all relevant parties (business, architects, developers and maintenance).