Re-thinking is a skill that allows you to look at things differently. You can say ‘the glass is half empty so someone is a pessimist’. You can also say that the owner of the glass is not very thirsty. By changing the perspective you come to new insights. This is no different in the case of software testing. We often come across stubborn conventions that require rethinking.
This blog provides examples of persistent software testing conventions. We change the perspective by rethinking.
Proposition 1 | Software testing aims to determine whether software is working properly.
When this statement is the approach of a test process, something is fundamentally wrong. This should already be considered immediately. The purpose of testing software is to reduce the chance of errors and risks. Software testing is about finding errors and limiting risks. A software tester who does not detect errors or risks in a test process will not feel well.
Proposition 2 | The test manager wants to get involved in everything.
Earlier we noted the following quote: “As a test manager you are not always popular”. Anyone who rethinks understands that the test manager is his best friend. After all, the test manager is the one who helps you minimize the number of errors and risks in your project. The sooner an error is found, the easier (cheaper) it is to fix it. Boehm’s law is significant about this.
Proposition 3 | You don’t have to test cloud applications.
We are purchasing more and more software from the cloud. It saves time, costs and is easy to implement. Nevertheless, this proposition requires reconsideration. Software developers are good at developing software, but do they know all your critical business processes? Do you dare to run your critical business processes via SaaS tools without a functional application test? In any case, we do not recommend this.
Proposition 4 | Test automation is sufficient for the test process.
This is a persistent and common thought. This requires rethinking. Because test automation does not exist. However, test automation tools do exist. These tools check whether what is stable and already tested still works. This does not provide new insights with regard to new or changed situations. This will always have to be tested manually. Test automation may be ideal for system testing and security testing, but hardly applicable for functional testing. Test automation can therefore be used perfectly as part of a test process, but it is not a test process in itself.
Proposition 5 | The final phase in a project is software testing.
We have already referred to Boehm’s law in proposition 2. The statement must therefore be: the test manager is involved from the first to the last day of the project (and longer). It may be difficult for a project manager to accept, but those who want to minimize errors and risks work closely with the test manager. From the start and in every phase of the project, he will ask what are we going to do, how are we going to do it, who is going to do it, when are we going to do it, what are the risks, where are the chances of errors, how are we going to do it? testing this, etc …
Proposition 6 | We do not test because we are a small organization.
The starting point for a test process is not the size of your organization. The starting point should be what risks does my organization run with the current IT landscape? You can have a company with only 25 FTEs, but the moment privacy-sensitive information from 3,000 customers becomes public, you do have a problem. In this case too, rethinking is in order.
Share your experience with us
The Testersuite Team is always interested in special practical cases. Do you have a good case of a test trajectory situation where rethinking needed to be applied? Share this with us and we’ll add it to this list.