Where are the Test Techniques?
Many organizations switched from waterfall to agile dev/ops a few years ago. In the past there was a lot of focus on requirements engineering and writing good documentation. The focus is now on deploying small pieces of software to production. Engineers with a test background have started coding or are involved in an OPS role and developers who also design and test. The introduction of T-shaped engineer. So in addition to your own role, you are also able to take on other roles such as testing.
In many organizations who went through this transformation we see that development and releasing new software is much faster now. Sometimes there are still some incidents which should have been discovered during testing. Luckily most of the time there are only small changes made in the software and deployed to production. Most of the time a change can be rollbacked quickly because of the small changes and the automated pipeline. But it can also end up with a lot of issues causing a lot of damage. Probably enough food for thought and input for the Lessons Learned sessions. Most of the time this will result in extra test cases to avoid the same issues in the future.
In the past most developers had their focus on proper unit tests and testing the happy flows. And most of the time those looked fine. OK, every now and then there were a few minor findings. But most issues mainly came from the non-happy flows. Today it is not very different. The big difference is that the DEV engineers have taken over the tasks from the testers, but unfortunately most of the time this does not apply to the mindset. Where the DEV engineer mainly focuses on the happy flows, the tester mainly focuses on the non-happy flows. And in this part we can still make a lot of progress to avoid any future lessons learned.
When we think about testing most of the engineers focus mainly on the various test tooling. And at the moment there is much better tooling on the market than a few years ago. Test tooling that is easy to use in a CI / CD pipeline. And tooling that is also necessary to achieve a high velocity. But the improved tooling only is not the holy grail to go to production with good quality software. The tooling helps you executing test cases quickly and consistently. But how do you set up good test cases that ensure optimal coverage in a structured way?
Test techniques! What are those? Yes, you would almost have forgotten them, but applying test techniques brings structure to the tests and help you to achieve good test coverage. Of course there are more things that matter to test software in a good and structured way, but for now I focus on the test techniques.
If you Google on test techniques, you will get a huge list of different techniques as a result. Techniques with the same name and a different meaning and techniques with a different name and the same meaning. I will stick to the techniques that ISTQB uses. ISTQB is a standard in testing. Perhaps some of them are familiar with TMap. Using testing techniques does not mean that your doing your tests according to ISTQB or TMap.
There is a whole list of different techniques on the basis of which you can formulate logical test cases. Each technique has its own purpose and focus. In most cases you will apply multiple test techniques. Testing a front-end requires a completely different approach than testing a batch or API. Besides that you are also dependent on the test basis that is available. Or in most cases there’s no decent test basis.
A good knowledge of different test techniques does not only help you in creating better test cases. It also helps you to ask better questions during refinements, better review of ready work and code. And of course to focus on the requirements. We sometimes forget that there are still requirements, but this is of course the basis for developing and testing software.
The page below is part of an application form for a mobile subscription. You must be at least 18 years old to take out a subscription. In addition, you must fill in the fields below. With this information you can already create a number of test cases based on, for example a syntactic test, boundary value analysis and equivalence partitioning. Each technique has its own focus.
With the syntactic test you look at (im)possible input values, with equivalence partitioning you make a split between applicants younger than 18 years and older than 18 years and for each class you define a test case. Of course you can also include gender if you think this is necessary. With boundary value analysis you are mainly interested in the boundary values. Test cases that you can create are a requester who turns 18 tomorrow, a requester who turned 18 today and for the sake of completeness you could prepare a test case for a requester who is 18 years and 1 day old.
This is just a simple example. If the other data has to be entered, such as address, ID, subscription type and telephone combined in a flow, other test techniques can also be applied.
Depending on the risks, test strategy and experience, you determine which tests and test techniques should be used. So you should definitely not apply a lot of different techniques indiscriminately. You always do it in a context of risk, strategy and experience. And if you apply this correctly, you will eventually achieve better coverage of the tests and a structure that will be input for the automated execution of the cases.
DEV engineer but not familiar yet with test techniques? Add them to your learning path. A good knowledge of test techniques will help you in setting up the right test cases that you can automate at the end. And the testers who are still in a team with DEV engineers. Take your colleagues with you in your journey of test techniques. Maybe they will take you into their coding journey!
Want to know more about test techniques? Take a look at here:
