Last time I looked at 5 different types of software testing, and today I’m looking at other types of testing you might need to add to your plan.
Of course, you might not need all of these, but if your project includes technical elements or software build, then it’s worth asking the question. “Are we going to do XXX testing?” And if the answer is yes, then go on to ask how long that will take, who needs to do it, how you will know that it is completed (in other words, what the exit criteria are for testing) and when it should happen. Then you can add it to the project schedule.

1. Regression testing
What it is: Re-running tests to ensure existing functionality hasn’t broken after changes.
Who does it: QA team or automation scripts.
When: Any time there’s a code or config update.
Why it matters: Prevents new features from breaking old ones.
Make sure the team has this on the radar to test any old functionality still works after other bits have been updated. You don’t want to accidentally turn off some functionality that was previously working just fine!
2. Performance testing
What it is: Tests how the system performs under load (speed, responsiveness, stability).
Who does it: Performance testers or DevOps engineers.
When: Before go-live or after major updates.
Why it matters: Ensures the system won’t crash under real-world use.
There are different types of performance testing. I’ve used these (well, not personally, but my projects have included these):
- Load testing (how it handles expected volume)
- Stress testing (how it copes under extreme conditions)
- Spike testing (reaction to sudden traffic surges)
The type of performance testing you want to do depends on the product you are building and also the tools you want to test. I remember one day being told we all had to log in and test something at the same time… these days you can simulate multiple users hitting a system with tools designed for that purpose. Your project budget might need to invest in testing tools if you don’t have the products you need already.
3. Security testing
What it is: Tests for vulnerabilities like data breaches, access control issues, or malicious input.
Who does it: Security testers, pen testers.
When: Before go-live or in regulated environments. Actually, in all environments these days! You can’t be too careful!
Why it matters: Prevents security flaws and meets compliance needs.
Sometimes security testing can feel like you’re just ticking a box or lining the pockets of a penetration testing company, but you really can't be too careful. With the amount of cybersecurity incidents out there, it is essential that you follow all the guidelines and do the right type of security testing to build confidence in the system and ensure that your company remains safe and secure.
4. Compatibility testing
What it is: Verifies the system works across different environments (browsers, devices, operating systems).
Who does it: QA/test team.
When: Before launch or when targeting diverse user bases.
Why it matters: Ensures consistent user experience.
Ever launched a website feature and then find it doesn’t work on Firefox? Yes, been there. It’s really important to test on a variety of systems if the product is going to be used by users using those systems. In other words, if members of the public could be accessing the software from mobile devices, does it work with all of them? Or as many as you can reasonably test? Don’t build for your own phone and assume it looks good on others – that’s what this testing is all about.
So, overall, that’s 9 different types of testing – how big is your testing phase? Some of those tests can be run in parallel, some you might not need, others will take longer than you have planned, which is why we add contingency to test phases. Work with your team to schedule in the best possible approach to making your software as functional as possible and then you’ll be well on your way to delivering something useful and bug-free.



