Thinking outside the box when testing software

‍

We often come across stubborn conventions regarding testing that require some rethinking. In this blog, we will change the perspective of these conventions by rethinking.

‍

Theorem 1 | Software testing aims to determine whether software works properly.

If this statement is the starting point of a testing process, something is fundamentally wrong. Something needs to be changed immediately. The purpose of software testing is to reduce the chance of errors and risks. Software testing is about finding errors and reducing risks. A software tester who does not find any errors or risks in test cycle will feel uncomfortable.

‍

Thesis 2 | The test manager wants to interfere in everything.

In a previous blog, we once noted the following quote: "As a test manager, you are not always popular". When you think about it, you understand that the test manager is your best friend. After all, the test manager is the one who helps you minimise the number of errors and risks in your project. The sooner an error is found the easier (cheaper) it is to fix. Boehm 's law is telling about this.

‍

Theorem 3 | Cloud applications do not need to be tested.

We are increasingly buying software from the cloud. It saves time, costs and is easy to implement. Let's say we are fans of SaaS tools ourselves. However, this statement requires some rethinking. Software developers are good at developing software, but do they also know all your critical business processes? Do you dare to let your critical business processes run via SaaS tools without a functional application test? We certainly do not advise this.

‍

Theorem 4 | Test automation is sufficient for the testing process

This is a persistent and common thought. Thinking differently is very much needed. Because test automation does not exist. However, there are test automation tools. These tools check whether what is stable and already tested still works. This does not provide any new insights with regard to new or changed situations. That will always have to be tested manually. Test automation may be ideal for system tests and security tests, but is hardly applicable to functional tests. Test automation is therefore perfectly usable as part of a testing process, but it is not a testing process in itself.

‍

Theorem 5 | The last phase in a project is software testing

We have already referred to Boehm's law in Theorem 2. The statement should therefore be: the test manager is involved from the first to the last day of the project (and longer). For a project manager this may be difficult to accept, but those who want to minimise 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 test this, etc...

‍

Theorem 6 | We do not test because we are a small organisation

The starting point for a testing process is not the size of your organisation. The starting point should be what risks does my organisation run with the current IT landscape? You can have a company with only 25 FTEs, but the moment privacy-sensitive information about 3,000 customers is leaked, you have a problem. In this case, too, it is important to think outside the box.

‍

Share your experience with us

As Testersuite Team, we are always interested in special case studies. Do you have a great case of a test cycle-situation that required the application of reverse thinking? Share it with us and we'll add it to this list.