I wrote to you about test management yesterday. My goal was to provide you with an idea of why test management (TM) might be something your projects could benefit from. What I did not tell you: You won’t get there just by using a software. There is a lot more to TM than meets the eye. But I won’t use your precious inbox for that.
What to test
The decision on what to test depends on your context and situation. There is not one universal answer to this question. Well, actually there is one thing all professional tester know about. It goes like this: “Every development activity has a corresponding test activity.”
If your team develops or designs something it should be tested.
Other than that you should probably test your code.
Seriously, now. Besides code here is a list of things you could or should test:
- configuration (data)
- business processes
- deployment processes and other operational processes
- seed data
- interfaces and APIs
- hardware and software systems
Perhaps I’ll think of a better description on what to test in the future. I’ll let you know.
How to test
I believe I wrote before there are different test levels (component/unit test, integration test, system test, acceptance test) and test types (functional, non-functional, white-box tests, black-box tests, change-related tests).
The answer to how to test: Choose the appropriate test level and test type. Do a manual or an automated test. Repeat for all remaining requirements. 😉
The topic on how to test is a whole chapter in books (and will be an important part of my course hint hint). The most important thing I would like to mention here is the distinction between function and non-functional tests.
With these, you test that the software is doing what the requirements require it to do. You test what the system should do. An example might be that the registration form creates a new user account in your database. Functional tests can and should be done on all test levels.
Functional testing requires the tester to know the software and the requirements and often the business case the software is trying to solve.
These tests are focused on software product quality characteristics as defined by ISO standard ISO/IEC 25010. To keep you from dozing off, this is about things like performance, security, maintainability, usability. These tests should also be done on all test levels. Contrary to common belief, you should do your non-functional testing as early as possible. Many of these characteristics depend on architectural decisions that are made early in the lifecycle and are hard to reverse. You can safe moneys here! To summarize, these tests measure how well the system behaves.
I did not yet address the 🐘 in the room: Professional testers strongly believe that developers should not write tests.
And all the developers go yay! 🎉
We’ll get to that tomorrow.