Problem Statement

 

For any non-trivial development project, testing will consume a large part of the overall project time (anywhere between 10% and 60%), test automation can make a significant saving to reduce this, especially where a lot of regression testing may be required. But there are always difficult choices to make between the volume, coverage and effort of testing, to make sure sufficient testing is performed without wasting resource.

 

However with most test automation approaches, this usually quickly becomes a large development project in itself. Lots of effort is usually required in generating boilerplate code and a custom framework before you even start on creating the test data... remember the only business value is in the tests themselves, not getting to that point of being able to start.

 

Test data is usually a problem itself as well - who understands the data well enough to actually create targeted examples that have sufficient coverage?, this can be even more challenging when the test team is remote / not an integral part of the development team. Tests also get out of kilter with the main development stream, thus requiring significant maintenance of the "tests", which is more effort that is not directly adding business value.

 

Rulevolution Approach

 

Rulevolution's has two solutions in the above areas, specifically:

 

Test automation itself

 

Rulevolution provides a framework for the quick creation of test cases without the need for building an extensive test framework. Targeted to web based applications (and through partners other platforms as well) Analyst level personnel (who understand what the system is designed to achieve), can create multiple test scenario's directly themselves.

 

This approach greatly speeds up the creation and specification of core tests, allowing focus to remain on what the system needs to achieve, rather than getting dragged into the mire of "test scaffolding".

 

However we do advocate spending time on test coverage and highly recommend boundary & failure scenario testing as well.

 

Once created the tests can either be incorporated in a Continuous Integration (CI) tool, or run directly (as a suite or individually) from the test dashboard within the Rulevolution Studio.

 

 

(We even use our own tools for our testing...)

 

For processes created within Rulevolution

 

Where the system is built within the Rulevolution ecosystem, data scenario's are used within the building of behaviour, these become part of the model itself, acting as internal constraints which cannot be inadvertently broken (a user is allowed to override where necessary). Therefore these internal tests, greatly reduce the degree of external testing required. However we still recommend boundary testing and failure scenario testing using the approach above.

 

Advantages

• Building tests becomes a visual experience, no expensive test engineers are required (as no extensive framework), and Rulevolution can be quickly learn't be a Analyst or similar, who actually understands the business scenario's required. We still recommend that boundary and failure testing is often required on top.
• If you have a typical web-style application, then Rulevolution can remove the requirement for a custom framework, and quickly allow the creation (and future maintenance) of the tests themselves, greatly reducing testing effort. Via our partners we can also connect (and thus test) many other non-web based and legacy platforms.

 

Interested?