When you first start working with software, the idea of testing it seems pretty straight-forward. You build something- let’s say a feature. You then stop, run your software and make sure the feature behaves the way that you want it to. For example, did the “alphabetize this list” button alphabetize the list?
There is a good bit of semantic nuance when it comes to types of testing, but you can think of this as “functional testing.” You want to validate that the software has all the functionality that you’ve promised. It should do what’s advertised and be fit for purpose.
This is, of course, extremely important. I’d even go so far as to say that you can’t be a professional software organization without functional testing.
But that doesn’t mean it’s the only kind of testing you need to do. In fact, you should be doing a lot of other different kinds of testing if you want to have confidence that you’re shipping an excellent product. Let’s examine other sorts of testing that your group should be doing.
Get TestRail FREE for 30 days!
1. Unit Testing
First, let’s examine something that the software developers ought to be doing. They should be writing unit tests.
Unit tests are little pieces of code that the software developers write. These bits of code automate testing the production code in small, isolated chunks- in units, in other words.
Unit testing is your first line of defense against issues and regression defects, in terms of the software development process. The developers can prevent a lot of downstream issues by unit testing their code.
2. Integration Testing
Integration testing is another form of testing that typically happens more on the development side. However, it happens at somewhat coarser granularity.
Where unit tests aim to isolate each component of the code and test it individually, integration tests focus on how the components work together. This can range from testing the connection of a couple of different modules to entire end-to-end testing schemes of your software.
Integration tests are also most frequently automated, but you could have manual schemes for this as well. Whatever the exact details, the idea here is to test whether different pieces fit together correctly.
3. Load Testing
Next up, let’s move out of the pure realm of the software developers and into more collective territory. These next few types of testing center around how the code performs, and a lot of different sorts of folks might participate: software developers, DevOps team members, QA, and perhaps others besides.
First among these is the idea of load testing. Load testing means applying a burden to your software that represents what production will be like. For example, if you’re building an e-commerce application, you’ll probably have hundreds or thousands of users accessing it simultaneously. So, having a single person in QA testing it at a time isn’t representative.
With load testing, you contrive of ways to simulate production conditions so that you can expose errors in a test environment.
4. Stress Testing
Stress testing is sort of a specific variant on load testing. With load testing, you’re not exactly looking to break the system- you’re just looking to see if the system can hold up to normal load. But with stress testing, you are looking to break the system.
Stress testing involves increasing the load on your software far past what you should normally expect. The idea is that you want to know at what point it will break and where the weak link in the chain lies. This lets you monitor your software in production so that you’ll know if it’s approaching dangerous load levels and you can take action ahead of time.
If you’re not stress testing your software before production, you’ll only learn its breaking point via the arrival of that breaking point.
Join 34,000 subscribers and receive carefully researched and popular article on software testing and QA. Top resources on becoming a better tester, learning new tools and building a team.
5. Endurance Testing
Endurance testing is yet another form of performance testing. But, where stress testing aims to make the load extreme, endurance testing aims to make the duration extreme. Basically, you put your software in an environment, apply a simulated load to it, and then just let it work for a long period of time, seeing if and at what point something goes wrong.
This type of testing is designed to expose the nasty kind of bug that only crops up after days or weeks of running. Memory leaks are among the most common culprits for this type of problem- an issue that nobody would ever notice in a normal usage or test scenario.
As with stress testing, the idea is to get out ahead of these issues before bumping into them in production.
6. Usability Testing
Let’s now switch gears to a much different concern and a much different style of testing: usability testing. Usability testing involves having actual users interact with your software and then basically seeing how it goes.
Of course, it’s a lot more precise than just sitting them down and watching what happens. With usability testing, you’re putting them into controlled situations and then recording how successful they are at navigating through the interface to achieve an outcome.
To understand how this differs from functional testing, let’s revisit the introductory example of alphabetizing a list. Functional testing evaluates whether a click on the “alphabetize list” button results in an alphabetized list. Usability testing would ask questions like “when they decide to alphabetize the list, does it take a frustratingly long amount of time for them to find and use the button?”
Historically this wasn’t as important a concern, but users these days have little tolerance for unintuitive user experiences. So, make sure you’re doing usability testing.
7. Regression Testing
I’ll close with perhaps the most fundamental form of testing besides functional testing. But it’s also one that’s way too frequently overlooked. I’m talking about regression testing.
Functional testing asks whether the “alphabetize list” button alphabetizes the list. You might give that test a “pass” in your test case management software and move on. But do you ever revisit this result in subsequent test runs, even when that behavior remains the same from version to version? That’s regression testing and, if you’re not doing it, you need to.
Software is extremely complex. As a result, even the most carefully constructed codebases present the danger that you can inadvertently break an old feature while adding a new one. Thus, you need to be testing all the new stuff with each round of testing… but also all the old stuff.
Unit testing can help with this. Indeed, the unit test suite is, by definition, a huge set of regression tests. But you need regression tests above and beyond that. Your entire testing effort is cumulative, and you need to realize that if you want to make progress instead of just playing defect Whac-A-Mole.
This is a guest post by Erik Dietrich, founder of DaedTech LLC, programmer, architect, IT management consultant, author, and technologist.
Test Automation – Anywhere, Anytime
