Inverting the Test Pyramid, by Joel Masset

Great Article from Joel Masset, Global Head of Product Assurance and Chief Quality Officer in the Financial Services Industry

invertedpyramid
Inverjoelmassetting the Test Pyramid
by Joel  Masset
https://www.linkedin.com/pulse/inverting-test-pyramid-joel-masset

Although most organizations focus on what it means for development teams to be agile, what that changes for them, and how to make it happen, testing is still very important in an agile delivery model. It is even more critical than in a traditional model.

I want here to highlight the big change that agility represents from a testing point of view. This is highly inspired from Mike Cohn’s well known test pyramid. However, I thought it was worth sharing this once more, as it is so close to what many major software delivery organizations need to go through nowadays.

In a traditional software delivery approach (waterfall, V cycle, iterative V cycle, washing machine…), all activities are serialized. Business requirements, design, development, test, debugging, […], release. The focus is put on finding bugs.

InvertedPyramid1

This leads to very little test effort to happen at the beginning of the cycle, and massive focus at the end, after developers have integrated their components into a product.

Roles are very clear and distinct. Developers’ role is to code and debug, testers’ is to find bugs, and check they are fixed.

Automated tests developed after the integration has happened will be essentially based on the UI. Their development cost is very high and since they are very fragile, maintenance costs are very high too. Any update to the code is likely to break the tests, which will require automation code to be updated prior to being ran. Since most of the testing focus is happening so close to the expected delivery date, there is a lot of pressure on the team to give its test campaign results. In most cases, it results into massive manual testing. In the best case, automated test development will happen in parallel, so that these can run post the release, but very regularly, the team will just give up on automating.

As a result, automation is extremely painful, costly, and inefficient, with a very low Return On Investment. The manual testing in this model is very costly, and happening under stress.

Don’t get me wrong, I am not saying this model cannot work, I have myself been using it for years. But oh my god, is it stressful…
Agile testing takes the opposite approach, by inverting the test pyramid.

AgileAutomatedPyramid

The focus is now put on preventing bugs from existing. This means that most of the test effort will happen at the beginning, at the code and UI level. In this context, automation will be extremely efficient. Unit tests will be written alongside development, or even before the actual code is written or updated (this is the Test Driven Development model).

Acceptance tests will be created at the API layer level during development and integrated in the continuous build and integration tools and processes.

At the time the developer checks the code in, it has already been successfully tested. Post-build and integration tests will automatically be ran and results checked.

Since all those tests happen during the sprint, a failed test will immediately lead to a code change fixing the issue. Not only the cost of fixing a problem is much smaller at this stage, but the risk associated to re-opening code that was already pushed, days or weeks ago is gone. The team then rarely has to switch context from the current version of the code to an older one. This is a much more reliable process.

Some testing will still be required after the integration steps. Some will still be automated at the UI level. This represents very boring and repetitive tests like links checks, or basic user workflow steps. The essential part of testing at that stage is exploratory testing. Based on end user workflows, these are tests that only a human person can do. But the effort will be limited here.

In this new approach, you end up with developers and testers both testing and coding together. A much higher synergy, and very little stress, because the delivery process is made much more reliable.

Results are impressive on the Quality of the software, the predictability of the releases, and as well on the motivation of the teams.

This change requires a big cultural change obviously, hence very high senior leadership, this will certainly be the focus of a future article…

Bill Fulbright
770-880-0959
Bill@2100solutions.com

Advertisements

QA 2100’s Pega PRPC and Web Service Testing Approach

QA 2100’s Pega PRPC and Web Service Testing

The behavior of many service based applications are governed by business process and workflows which are defined by business rules. These business rules must be validated during application testing. For many firms, testing business rules is a costly and complicated process which involves business users and testers. QA 2100 has uniquely designed state-of-the-art automated test methods using tools integrated by Pega Systems into PegaRULES Process Commander® (PRPC) V.X and Test Management Framework. Within the framework of PRPC is a process of design which utilizes not only business process, but a tool called Direct Capture of Objectives or DCO. This process turns use cases based on requirements into design, thus providing fundamental testing paths for automated testing. This allows you to develop an application using a design based upon business rules, use cases, best practice development and quality principles.

Automated business rules and workflow validations can lower your testing time by 95%

Test Automation Using PegaPRPC Tools
QA 2100 takes business rules validation testing one step further by automating the creation of test scripts using parameterized data and automating the execution of test cases. For example, QA 2100’s accelerator can execute 65 rule validations in 1.1 minutes using automation, versus 32.5 hours for manual execution. We use the Automated Unit Testing functionality within Pega PRPC to help you build a series of test cases to satisfy test requirements defined by the business requirements and use cases. These test cases are the foundation for automated test scripts. Automated test scripts can be built to pass from workflow to workflow, thus describing a partial or complete path through the application for scenario or end-to-end testing.

With the use of Test Management Framework (TMF), use case steps and parameters as described within the automated test scripts can be satisfied using the Scenarios and Suites features. The Scenarios and Suites test the behavior of the application and verify compliance with the original requirements. Besides providing significant savings in cost, time and efforts, automation lets you run many more tests during your testing process as a suite to provide hands off results.

Boundary Testing
QA 2100 provides boundary or negative testing of the business rules and process to confirm the effectiveness of rule sets by requesting conditions that don’t exist. This helps ensure the business rules engine returns the correct value or an appropriate error. These boundary tests are set up as part of the actual application within each workflow.
QA 2100 has experience with automated tools to accelerate testing and improve accuracy
Employing automation tools to test and validate business rules adds breadth and depth to your testing efforts. By using pre-defined testing parameters, hands-off automation methodologies, and innovative solutions, you can accelerate and simplify a complex process.

XMLServiceTestToolExecutionTiming

32.5 hours to perform 65 rules tests manually
1.15 minutes to perform 65 rules tests using automation

Continue reading QA 2100’s Pega PRPC and Web Service Testing Approach

Maximizing Value from Good Testing Practices in an Agile Environment

Capgemini Round
Capgemini

Here is an article from Capgemini on the value of good Testing Practice in an Agile Environment:
Maximizing the value of Good Testing Practices in an Agile Environment