Introduction
In this article, we will see together different basic concepts about Software Testing.
There are different goals around it. The first one is obviously to search for defects than can be fixed to improve software quality. Then to validate that the software meets its purpose and finally facilitate refactoring and upgrades by validating that everything is still working after.
As seen previously together on this post, Continuous delivery ensures that your software can be released into production any time. With continuous delivery you use a build pipeline to automatically test your software and deploy it to your testing and production environments.
As you test automatically, you can run them frequently and they should be independent from each other as much as possible. You can also run them in parallel and save you a lot of time as you are not consuming human time !
Running tests frequently means that problems are found early and you usually know what small piece of code caused the problem.
Type of tests
Good testing involves many different types of tests. Let’s see together some of the most famous types of tests.
Faster tests
- Unit tests — test a small piece of code (a function or method or command) Run blazingly fast, and are often written by the person who wrote the code.
- Integration tests — validate integration between multiple sub-systems. Including external sub-systems like a database.
- Smoke tests — validates basic functions of the system – Also known as sanity checking.
Slower tests
- Functional tests — validate the normal software behaviors against the expectations and requirements.
- Non-regression tests — validates that the system still produces the same result.
- Acceptance tests — tests the full product from the perspective of the end-user use cases and feelings. Probably includes manual testing.
Manual Testing
Manual testing is appropriate when test result is subjective, such as user experience testing.
It may also be used when the cost of automation is excessive for some reason.
Finally it should be performed rarely, and only on software that has passed all automated tests.
TESTING PYRAMID
If you want to get serious about automated tests for your software there is one key concept you should know about: the test pyramid. Mike Cohn came up with this concept in his book Succeeding with Agile. It’s a great visual metaphor telling you to think about different layers of testing.
It also tells you how much testing to do on each layer.
Tests at the bottom of the pyramid run quickly and inexpensively and should be run very frequently.
Tests at the top of the pyramid take more time to run and are expensive; they should be run less frequently and only on software that has passed the tests lower on the pyramid.
Good practices
- You should have more low-level tests than high-level tests.
- When low-level tests fail, it seldom makes sense to run higher-level tests before fixing the problems detected by the low-level tests.
- When a higher level test fails, consider that it detected a defect in the lower-level tests as well as a defect in the code.
That’s all for today !
