I earned my philosophy degree in the years leading up to 2000, at a time when everyone feared the millennium bug. As a result, it was surprisingly easy to get a job in IT, so I learned SQL, COBOL and, soon after, Smalltalk and Java. That’s when the real fun started. After years spent discussing things like the nature of being, the number of angels that can dance on the head of a pin, and whether there is a sound when a tree falls in a forest and no one is around to hear it, designing a software application to create a report with a well-defined outcome was refreshing, and something for which my training in philosophy had prepared me well. The ability to think clearly, logically, and creatively is a highly portable skillset.
In this post, I’ll share some thoughts on automated testing through the lens of my early training in philosophy. Automated testing should be a foundational concern for every developer, and in this there are four guiding questions that every developer should ask: (1) What are my assumptions? (2) How do I prove my assumptions? (3) Am I shaping reality? And (4) is it beautiful? By asking and answering each of these questions during the development process, you can be confident in the impact that you will make to your organization.
Why automated testing matters
I’ve now been involved in software delivery projects for more than 20 years. During this time, I have been amazed by how little focus is often placed on automating the delivery process itself. While there has recently been much interest in DevOps, it is surprising how infrequently developers think about how to improve testing processes. Many projects still rely heavily on numerous dedicated resources to go through the test paths and to perform manual regressions tests.
My background in philosophy has underscored my belief in the importance of testing for developers. When a developer creates a user story, they are implicitly claiming that it will consistently deliver a well-defined set of outcomes under a set of conditions that are equally well-understood. But a claim is nothing without proof.
Testing is all about doing research. It investigates how software actually behaves. It ensures that the claims that developers make about their user stories are true. Without testing, a user story is like a tree falling in a forest that no one hears.
Four essential questions
1. What are your assumptions?
We make decisions based on assumptions. If our assumptions are correct, our actions will have predictable results. If not, then the actual results we see can become quite unpredictable. Just think about the last time you accidentally offended someone because you wrongly assumed some shared understanding of the world.
Code is no different. Code is a language, after all. Code communicates. So, it’s crucial to understand a user story in the context of its broader application and the business goals it's expected to accomplish. As professionals working on a user story, we need to understand what needs to happen to bring the business value described. What this means is that testing has to begin before the coding starts. We need to test our assumptions against the assumptions of our stakeholders to make sure that they are actually shared.
This is where Direct Capture of Objectives (DCO) in Pega comes in very handy. By capturing objectives directly within the application, through active collaboration with stakeholders, we minimize the risk of error that would otherwise arise were we to try to translate a requirements document from the business into an actual build.
2. What’s your proof?
When starting work on a user story, don’t just think about implementing a set of requirements. Instead, think about how the solution described by those requirements will fulfill the requirements of the business. Remember, the claim that you are making in your design is not that it checks all the boxes of a requirements document, but that it solves a particular business challenge.
This is where test automation comes into play, as a way of proving business value. It is the responsibility of every developer, and it is something that needs to be considered from the very beginning, hand in hand with the implementation design. Every definition-of-done should require that a user story has the automated test cases defined to prove the functionality.
Think about the testing pyramid. Test types at the bottom of the pyramid are the least expensive to run, easiest to maintain, take the least amount of time, and should represent the greatest number of tests in the test suite. The higher up the pyramid you go, the higher the overall cost and the lower the benefits.
Pega offers a set test automation tools (PegaUnit for unit testing, Pega API for API based testing and scenario tests for UI based testing) to support this, and you can obviously use other products in the market as well.
Define your test cases up front and be smart in your testing approach (ex., unit tests that validate on a case in the pxObjClass probably doesn’t hold a lot of value). As a developer if you don’t know how to prove your user story, ask help from a tester!
Creating automated test cases takes time. But without them you build applications blindly and introduce risk as you move them into production. If you are working on a growing application, your test cases will also provide ongoing value since they will allow you to quickly check to ensure that nothing has broken with each new version. Testing early and often ensures the discovery of small issues before they snowball into larger, more costly defects that are harder to fix and retest later on.
3. Are you shaping reality?
When your user story is completed and its functionality is proven via automated test cases, you do need to understand its effect on the larger application of which it is a part.
Sometimes a piece of functionality is delivered that unintentionally changes or breaks the behavior somewhere else in the application. The best way to keep an eye on this is by running all automated test cases to understand if somewhere the behavior is different.
Changing reality also applies to non-functionals like performance and security. For example, if your user story creates functionality that is applicable for one persona, it’s not enough to only grant that persona access to this functionality. You also need to assure and make changes to access control so that other personas don’t have access and use test cases to prove it.
4. Is it beautiful?
In philosophy, beauty is more than skin deep. Plato, for example, famously thought that the Beautiful and the Good were the same thing. In IT, we think about beauty from the perspective of user experience (UX), and like Plato we think about UX as something that needs to be both useful and easy to use, effective and delightful. And an application is only as elegant as its code.
Think about developers as users of the code you create, and work to ensure that their experience of your code is as good as possible. Make sure that rule names clearly describe what rules actually do. Document rules to describe what they do and how to use them. Ensure clear class design so that the rules in the class logically belong there. And, most importantly, good quality in your application starts with a high compliance score. If there is a guardrail warning that you can’t avoid, make sure to document your justification for why this exception is needed.
None of this is rocket science. We all know that testing needs to happen. And yet many project teams still do not invest in test automation, automating the deployment process, and fixing guardrail warnings. In order to make use of the latest features in Pega, having the latest performance and security updates, it’s important to keep current on the latest Pega version. To be able to create sustainable applications, high quality is critical. So, do it. Through testing you will not only reduce risk and decrease effort in the long run, but you will also build trust from your stakeholders. You will have done much more than simply completing a task. You will have created something beautiful -- something that is both useful and easy to use -- that creates real business value.
Don't Forget
- JOIN THE CONVERSATION on Collaboration Center
- FOLLOW @PegaDeveloper on Twitter
- SUBSCRIBE to the Pega Developer Podcast on Spotify or via RSS