Software testing techniques are fundamental to properly critiquing the product. Testaify will plug the gap created by pursuing shift-left work.
TABLE OF CONTENTS
- Software Testing Technique Definition
- Testing is an Activity, Not a Phase
- Software Testing Techniques are Essential
Software Testing Technique Definition
In my blog post about the evolution of software testing, I discussed the different testing schools. The first one is the analytical school, which, in its main contribution, defines many software testing techniques.
The essential thing is that to test any software product, we still use these techniques. They are an indispensable part of any software tester’s toolbox. A technique is any systematic way of obtaining information about something. In this case, it is about a software product and its behavior. In other words, a software testing technique is a systematic way of obtaining information about a software product. Because they are systematic, they are methods.
I define software testing techniques to make everyone understand what I am discussing. As I stated before, one of the most annoying aspects of software testing is the need for consistent definitions.
An example of software testing techniques include:
- Use case testing
- Equivalence class testing
- Boundary Value testing
- Decision table testing
- State Transition testing
- Pairwise testing (Orthogonal arrays for the mathematically inclined)
- Domain analysis testing
As I said, you need to follow a systematic method to use a software testing technique. You can follow a non-systematic approach and might find defects (bugs), but your performance as a tester will be inconsistent, at best, if you test without using any software testing methods.
Designing Tests
When it comes to designing tests, have we changed much? The way we express some of the tests has changed. Let me use “use case testing” as an example. The use case testing technique is essential as you design your test cases. In fact, I taught many to always start with use case testing. How we document a use case has changed a lot, as has how we write test cases using use case testing.
A use case is a list of actions or event steps typically defining the interactions between a role (actor) and a system to achieve a goal. It is a well-known and established approach to defining systems requirements.
A use case diagram looks like this:
Source: https://medium.com/business-architected/use-case-diagrams-and-how-to-use-them-b230019a98e5
A textual use case looks like this:
This technique requires you to design at least one test case for the main success scenario (main flow) and one test case for each extension (alternative flows).
These days, I teach people to create their use case tests using BDD (Behavior Driven Development). As such, they look like this:
Source: BDD in Action
Instead of creating a use case test diagram or document, you create the test cases you will need to cover your use case. That is one of the great ideas behind Agile testing. The idea of driving development using testing is the basis of TDD, ATDD, and BDD. The concept of Shift Left is not that new. We have been discussing building quality-in for a long time. In Boris Beizer's Software Testing Techniques 1982 book, you can find the following quote: “More than the act of testing, the act of designing tests is one of the best bug preventers known.”
Testing is an Activity, not a Phase
Using tests to drive development is the most crucial contribution of Agile Testing (fifth school) to the testing world. It is at the core of Marick’s testing quadrants. Are software testing techniques present in the testing quadrants? Yes, they are present, but their location is scattered.
Let’s review the matrix once again (I know I use this matrix a lot), but this time, we will discuss the software testing techniques.
At the top of the matrix, you have Business Facing, which refers to tests that deal with the business domain. Any business expert will understand these tests. At the matrix’s bottom, you have Technology Facing. Per the name, the focus here is on the technology or the verification of the technical implementation. Support Programming is at the left side of the matrix. This side includes the efforts that support the development of the specific product. On the right side, you have Critique Product. These are the tests trying to break things (the critique). Altogether, this matrix forms four distinct quadrants.
Quadrant 1, Support Programming/Technology Facing
The first quadrant at the bottom left is for Test-Driven Development (TDD). You write a unit test to help you think about the code you need (TDD) or check the code you wrote (old-fashioned unit testing). From software testing techniques, what the industry calls white box testing happens here. I have a problem with the idea of white box, black box, and grey box testing, but that is a subject for future blog posts. Some examples of white box testing techniques are control flow and data flow. I recommend using so-called black box testing techniques, such as boundary values in this quadrant. Other “black box” techniques are applicable in this context too.
Quadrant 2, Support Programming/Business Facing
The second quadrant describes the tests that help you understand the capabilities you need to develop. The critical difference between Q2 and Q1 is that these tests arise from the business perspective. You will find BDD in this quadrant. In other words, you will use case testing in quadrant two. However, it’s more nuanced than that. You can decompose your BDD scenarios into unit tests that you use in quadrant one. Can you use other testing techniques in quadrant two? Absolutely, you can. You might use the same software testing techniques in quadrants one, two, and three.
Quadrant 3, Business Facing/Critique Product
Most testing in the third quadrant concerns the application's functionality and usability. This quadrant has all our regression functional tests. We verified that adding the new functionality did not break anything. During the waterfall days, QA teams used all the functional testing techniques here. They can still be used in this quadrant, but the emphasis is on critiquing the product.
But now that we understand testing is an activity, not a phase. We use the software testing techniques toolbox when needed, not when someone tells us it is our turn.
Quadrant 4, Critique Product/Technology Facing
The fourth quadrant is about performance (a big umbrella on its own), security, and accessibility. It focuses on whether the technical implementation meets the standards for a successful product.
Before Agile, QA departments used the waterfall approach for a long time – addressing quadrants three and four only.
Software Testing Techniques are Essential
What Agile thought leaders rarely discuss and never address are the issues in quadrants three and four. The shift left brought by Agile is a significant improvement on how we did it before. But, the product critique is still an essential part of testing. Assuming the only thing you do in quadrant three is exploratory testing is poor advice, which is why many Agile teams continue to develop poor-quality products.
We created Testaify because Agile has disregarded the essentials represented by quadrants three and four. We aim to plug the gap created by lousy advice on how you test software. To test software, you always need your toolbox. When using Testaify, you will notice that software testing techniques play an essential role.
Join our waiting list. Testaify is coming soon!
About the Author
Testaify founder and COO Rafael E. Santos is a Stevie Award winner whose decades-long career includes strategic technology and product leadership roles. Rafael's goal for Testaify is to deliver comprehensive testing through Testaify's AI-first platform, which will change testing forever. Before Testaify, Rafael held executive positions at organizations like Ultimate Software and Trimble eBuilder.
Take the Next Step
Join the waitlist to be among the first to know when you can bring Testaify into your testing process.
