In Software testing main goal is to provide a product with minimum bugs and maximum quality. For this reason testing has evolved over the years through experience and knowledge. There are lots of methodologies, strategies and testing types which is getting used in different projects based on their suitability and project goals. But on of them, there are important rules and principles which testing teams should apply regardless of the technique or strategy.
In this article we will check out 10 main Testing principles and guidelines together which includes:
- Expected behaviour in each test case should be clear
- Developer should not test his / her own application
- A development company should not test its own products
- Results of each test should get inspected completely
- Test data should include valid, invalid and unexpected values
- Testing should cover both what the software is suppose to do and what the software is not suppose to do
- Test cases should preserved even after development done
- Testing should be done in an assumption that software has bugs
- The probability of finding errors in one section is proportional to the already found bugs in that section
- Testing is enormously challenging and creative task
Expected behaviour in each test case should be clear
Although it might seem way obvious, it’s one of the most overlooked rules in testing. In summary, whenever a test case is getting created, the expected output or result should be defined exactly and clearly. If expected result is not predefined or is explained in a vague way, any output can be considered as a correct output which therefore can be problematic and in contrast with the product’s specification.
It is more a physiological bias as “The eyes seeing what it wants to see”. It is highly recommended to precisely explain the desired output and also input values in a test case. So we can divide test cases into two distinct parts
- Input: A description of the input data and instructions
- Output: A detailed and precise description of the expected output based on the set of Input data
By incorrect explanation of expected result a bug can easily seen as desired result. Id there are no expectation, there is no quality measurement too.
Developer should not test his / her own application
It’s never a good idea to have the author of a book to edit his own book, or proofread it. Yes, the writer knows what each text suppose to convey but they may be unable to detect when the text doesn’t work. It’s harder for the writer to find his / her own errors. It’s the same situation with software.
Software developers may unable to find their own mistakes in using algorithms, practices and coding approaches, therefore it is always recommended testing a software should not be done by its coder.
Also a creator, let it be an author or developer, creates the application with a constructive eye and it’s not an easy task to immediately change the view as destructive to aim for finding bugs and errors in your own code.
Most developers can’t effectively test and analyze their own programmed software because they can’t bring themselves to shift mental gears to attempt to expose errors. Developers may subconsciously avoid finding errors for a lot of different fears as getting seen as not competent enough, getting fired for the low quality work, getting more work to done etc.
In addition to the mentioned issues there is another major problem, misunderstanding the specification and user stories of the software. If the developer has understood wrongly the aim of the software and its features, then this misunderstanding will be moved to the testing part too, which is very important to avoid such case.
Developers are valuable members of testing team, but mostly as a support for testing team and not to test software completely by themselves. It is recommended to test the code by the team of testers including the developer.
Also it should be consider that debugging is way more effective to done by the coder and new developer. Fixing errors is way more productive with the developer who has written the code as he knows the ins and outs of the code better than anyone else.
A development company should not test its own products
This rule is similar to the previous one. Companies and organizations are not much different than individuals with similar psychological problems. A project manager or a company as a whole can have very biased views on their own produced software on its quality and performance.
Usually a software is suppose to produced and delivered in a determined time period and cost and it affects how the manager and the team see the final product in a professional pessimistic way to find bugs.
It doesn’t mean a company can never test its own produced apps, software and products but it is difficult for the organization or the manager to test their own software and it is recommended software get tested by third party team with least mental biases. This will be more economical to make the testing done by an independent testing team.
Results of each test should get inspected completely
This is another obvious testing principle but again it is getting missed lots of time. Whenever a test case is performed its results should get analyzed completely to find other related bugs in this section. Usually errors that are found in later test cases has been missed in previous ones. As a result it is adding more testing cost which should be prevented.
Test data should include valid, invalid and unexpected values
Commonly features only getting tested by valid and rational values, as there is a tendency to work with the app only with acceptable data, but lots of time there are bugs in the software when an invalid data or even unexpected data delivered to the app as input. In these cases app crashes, provide incorrect or inappropriate results.
One way to prevent the app from getting invalid or unexpected input values it to use the UI advantage. If the UI is designed in a way to only choose or enter valid values, then it will be less probable to have the app in unexpected state with invalid values, but in any case, it’s common practice and a testing rule to prepare both valid and invalid values in test cases
Testing should cover both what the software is suppose to do and what the software is not suppose to do
Testing should be done for what the app suppose to do as well as what it is not suppose to do. Testing the software for only what it is suppose to do is only half of the testing game. Another half, is to examine if the software working properly for the thing that it should not do.
For example we might have an app to list 100 employees. It can list 100 employees successfully but it may rewrite the previous employee names after it reaches the number 50.
So it’s so crucial to test both sides of the software. Testers should always have in mind to see the app in unexpected and invalid states along with valid and expected state.
Test cases should preserved even after development done
This testing principle is more clear in regression testings. This problem happens when a list of test cases getting created and performed and software is delivered. Test cases are getting removed as the team thinks the project is finished.
New features get requested and created and now the test cases are missing. As creating test cases demands lots of effort and time cost, usually the testing after modifications as regression testing is not getting done thoroughly.
It is very important to done regression testing after modifications to the app which usually results in new bugs if the software has not developed in best practices. Usually testing teams underestimate the importance of regression testing and sometimes the reason is the missing test cases.
Testing should be done in an assumption that software has bugs
This is one of the common mistakes of project managers and it is a sign of incorrect definition of testing. usually project managers assume testing is the process of showing the software is working properly.
But the definition of testing is the process of executing the software with the intent of finding errors.
It is impossible to create a bug-free application or software. Even after extensive testing and fixing errors it is safe to assume bugs are still available.
The probability of finding errors in one section is proportional to the already found bugs in that section
This is a phenomenon that happens in testing. Usually some of the sections, components, modules or simply parts has more bugs than others. There is no clear explanation for this phenomenon but it almost always happens in software.
It can be because of cluster nature of the bugs. For example if we have 2 components and both has been tested briefly. 1st component has 5 bugs and 2nd has 2 bugs. If we perform a more rigid testing it is highly probable the 1st component will have way more bugs than 2nd component.
In these situations it is better to focus additional testing efforts to the error prone component.
Testing is enormously challenging and creative task
Unlike common belief testing requires extreme creativity. It is said testing a large software demands more creativity than designing the same software.
As mentioned before we can’t guarantee the absence of all errors. Methodologies will help in this case but still using these methodologies and combining them along with good test case creation requires decent creativity.