In an automation testing process, keeping your code understandable and clear is a crucial task. A review process is often a good way to avoid mistakes and errors, and though underrated, could go a long way in making your tests successful. In this article, we discuss some reviewing tips that will help you optimize your tests.
1. Use non-technical language to write tests
A unique quality of well-written tests is that they are easy to modify and maintain. Simplicity in writing tests is also beneficial when errors accrue as they make it convenient to find reasons behind the failures during execution.
Thus, a well-written test can be identified when a non-programmer can understand it the way a programmer who has written the codes has. It’s the same as applying Feynman technique (the art of explaining the five-year-old any complicated task in a way it is comprehensible to the child) to writing tests. Hence, unless the tester cannot explain the rationale behind writing a specific line of the test or is unable to explain what the test does, the test is usually considered to be a good one. One way of achieving clarity while writing tests is to use function names that speak for themselves.
2. Restrict unnecessary optimization
Optimization of the test is an unnecessary time-consuming process that reduces the efficiency of the tests. Optimization is only essential if you are sure it provides benefits worth spending the time required to optimize codes. According to experts, optimization should usually begin with the weakest section and should be ideally used in two cases-
– The test is running long and the application under test is idle during execution
– If the optimization pertains to an obvious error in the code that would not take much time to correct.
It is also beneficial to look for the performance of the script from all perspectives- i.e. the application under tests, testing environment and scripts. Determine quality criteria beforehand (usually at the beginning of the project) that the test should meet (with respect to frequency, speed etc.).
3. Review codes of others’
At times, reviewing tests codes written by others is one of the best ways to help keep your project on schedule. Due to the complexity of tests, often the author of the test may miss out any crucial error that may potentially lead to complications in future. It is possible that during such second-person reviews, these potential errors can be corrected or incomprehensible codes be fixed.
Amongst others, the tests of junior testers must be specifically checked as there is more probability to find errors in them. Ordinarily, at the review stage, it is not necessary to know whether the test works, since such verification is the task of the author in the initial stages. What you need to do is view the code and pay attention to incomprehensible or complex blocks. In order to do this, you could make a checklist of rules you should follow while reviewing the test.
It is also necessary to point out that verifying someone else’s code has another benefit, it may help you identify a simpler algorithm that can be used by the original author to conduct the test more efficiently. Use pair programming technique wherein one tester writes the code (author) and the other sites nearby to provide advice.
4. Perform Refactoring
The practice of refactoring implies simplification of the existing sets of code, in which, the functionality of the application/test remains constant. Refactoring is necessary/required in following circumstances-
– When the code supporting the test is very complex/difficult to comprehend
– Improving the existing code to bring about modifications to factor a new code/process discovered beneficial post authoring the test.
– For the purpose of writing new tests where common functions and classes of existing codes are already present.
It is important to understand that refactoring should not change the functionality of the test, hence, one should ensure that the modified code performs the verifications that were being performed before the refactoring process is carried out. One way to do this is by simulating the errors in pre and post refactoring tests.
5. Remove unnecessary tests providing minimal benefits
Ordinarily, every application requiring test must be covered with automated tests that fully test the functionality, but too many tests may also be harmful as far as productivity of the tester is concerned. This is because old tests require a lot of support and it is not possible to reduce the number of new tests that target the functionality of the applications. Hence, right from the initial stages, you should keep the track of-
– The number of ‘real’ problems found by the given test (to identify their utility)
– The number of times the test is required to be fixed
– How many times the test was required to be started etc.
An analysis of above would reveal that not all tests are equally important/useful. While some tests may help you find bugs, others merely take your valuable time by requiring maintenance. Ultimately, it is always better to have 10 good tests than 50 tests resulting in so many bugs that you do not have the time to fix them.
KiwiQA is an automation testing company that can help you assist in automating testing services. Find more information about our services here.
