Development Testing – A Techpearl Viewpoint
Srikanth Renganathan (VP - Techpearl)
In an agile development environment, it is imperative that the software developer is equipped with essential test skills as we often do not have the defences of independent dedicated test teams. Software developers need to understand the importance of doing development tests including unit and integration tests early in the development lifecycle. It is essential that they are aware of the various test techniques, methods, and tools available to perform software tests in a practical & realistic way.
Unit tests are one of the most unregulated and ignored areas of software development in most software organizations. There is always a focus to learn the nuances of a programming or scripting language and many organizations have software certifications mandated as part of their staff learning cycle but test focus and certifications are rare and non-existent.
The cost of a bug or a defect increases exponentially as we detect them in later stages of the development life cycle. Many defects may be hard or impossible to detect in later stages and undetected UT defects may cost 5X more when detected in late-stage system/user level tests or 10X+ if detected in a production site. Some UT latent issues may continue to show up as non-reproducible errors etc. In extreme cases, latent defects lead to dissatisfaction among customers and loss of business.
Though it is practically impossible to find all defects, we need to set-up systems, processes and regulations to ensure that adequate tests happen within cost and budget constraints.
Sharing below some of the Techpearl practices in developer testing. Every developer is trained on basic test techniques like BVT (Boundary Value Tests), ECP (Equivalence Class Partitioning) and how to use them in a combination. We have set-up coverage tools with the right rules to ensure code, branch and path coverage. Coverage rules are customized depending on the industry/domain. For Security/high availability systems we have higher/stringent rules. With many regulatory requirements around security (like Europe’s GDPR requirements) security tests for checking the code vulnerabilities is also becoming essential.
Once an organization sets-up systems for the above areas of developer level tests, we can add more regulations around code duplication, File/Function size limits etc. Functions that rarely exceed a cyclomatic complexity of around 10 makes the code more maintainable and flexible to adapt.
Bug-bashes (Doing focused tests by all team members on identified modules) are another way to build a culture of test and quality consciousness among team members. These once in month events gamify the whole bug finding process and developers imbibe the spirit of testing more effectively. Developers who find the critical/rare bugs can be recognized with awards.
As we mature, an organization can introduce test certifications for the developer community.
Listing below details of some of the Unit test methods and Techniques widely used in Techpearl
a) Coverage Tests
| Type of Coverage Test | Definition | Formulae |
|---|---|---|
| 1. Statement Coverage/Block coverage | The number of statements that have been successfully executed. | Statement Coverage = (Number of statements executed)/(Total Number of statements)*100. |
| 2. Decision Coverage/Branch Coverage | The number of decision control structures that have been successfully executed. | Decision Coverage = (Number of decision/branch outcomes exercised)/(Total number of decision outcomes in the source code)*100. |
| 3. Function coverage | The number of functions that are called and executed at least once. | Function Coverage = (Number of functions called)/(Total number of function)*100. |
| 4. Condition Coverage/Expression Coverage | The number of Boolean condition/expression statements executed in the conditional statement. | Condition Coverage =(Number of executed operands)/(Total Number of Operands)*100. |
b) Boundary Value Analysis & Tests
It checks for the input values near the boundary that have a higher chance of error. Every partition has its maximum and minimum values and these maximum and minimum values are the boundary values of a partition.
Example 01 :
Consider a system that accepts ages from 15 to 50.
Boundary Value Analysis (Age accepted 15 to 50)
- Invalid – (min – 1)
- Valid – (min, min + 1, nominal, max – 1, max)
- Invalid -(max + 1)
Consider a system that accepts ages from 15 to 50.
- 14 (Invalid)
- 15, 16, 35, 49, 50 (Valid)
- 51 (In valid)
c) Equivalence Class Partitioning
It checks for the input values near the boundary that have a higher chance of error. Every partition has its maximum and minimum values and these maximum and minimum values are the boundary values of a partition.
Example 02 :
Consider a field that accepts a minimum of 6 characters and a maximum of 10 characters.
Then the partition of the test cases ranges 0 – 5, 6 – 10, 11 – 14
Test Scenario 1
Enter value 0 to 5 character; Not accepted
Test Scenario 2
Enter 6 to 10 character; Accepted
Test Scenario 3
Enter 11 to 14 character; Not Accepted
Why Combine Equivalence Partitioning and Boundary Analysis Testing: Following are some of the reasons why to combine the two approaches:
- In this total number of test cases is optimized.
- The effectiveness of the testing remains un-compromised
In Techpearl, we believe that building essential and practical software test skills go a long way in improving developer’s overall maturity, quality consciousness and eventually builds quality in the products we deliver to our end customers!
