Reduce Software Test Cycles

By saying software test cycles, I mean the test cycles that are performed by software testing team (Product Assurance Testing) after developer integration testing (DIT). It is likely that testing a software product is done in multiple test cycles. Each cycle defines the test scope. In the software test plan, the number of test cycles is planned and scope is defined.  The fact why multiple test cycles are defined is probably to enable product testing as early as possible and not wait until the complete product development is completed. Say 50 product features have been implemented and are ready for testing while another 20 or 30 features are yet to be implemented. In this case the product testing can begin to test the 50 completed product features while rest of the features are being developed. This one of the best practices to begin product testing early in the Software Development Life Cycle (SDLC). This really helps if the product scope is huge and helps every stake holders to early know the quality of the product.

How do many Test Cycles get introduced?

By having said that multiple test cycles has some advantages, it is likely that most of the times, we end up having more test cycles than planned. This typically happens because of poor quality of the code and code change impacts are not well tested. Testing process goes like this, the testing team completes a planned test cycle and logs the bugs/issues found during in a defect tracking tool. Developers will then have a look at it, estimate how long it will take to fix the bugs reported for example in test cycle1. In order for testing the bugs fixed, there is going to be another release to the testing team. In this case the testing team will verify the bug fixes. However, the bug fixes can have the impacts on other features of the product, if the impacts are not thoroughly tested by the developer themselves, then again there will be other bugs caused because of the bug fix code changes. These bugs will again have to be fixed by the developers and testing team has to verify again until there are no more issues with the software. Sometimes this causes delay in the product delivery. In my experience this happened several times. We can avoid this by following certain best practices that I am going to share in this article from developers perspective.

Test the Impacted Areas thoroughly

Impacts of code changes are the one which will delay the product delivery in my opinion. The impacts have to be thoroughly tested by the developers themselves before handing over the build to the testing team. There are ways to best do this. The person who made the code changes is the best person to identify the impacts of the bug fix. The big question is how a developer can find the impacts. There are ways to do it. Developer changes the code in a method, he/she can find the references of the method to see what are all the places the method is being called and test those all the calling methods too.
  
Take help of Design Tools to find impacts

Look into the design tags of the method. As a best practice, each and every method and class will have a design tag. Trace the design tag and look back into the design of the product. Find out what other components (modules) of the project is depending on the tag. The design tools can help figure out the depending design tags and from the impacted design tags, the impacted code can be traced out and tested.

Have different people to test the impact

Avoid biases. In case of manual testing, its good practice to have different people to test the change and not the one who made the code. The person who fixed bug may be biased by his confidence sometime over confidence. The fact behind this is each person thinks differently and its needed for a thorough impact testing of the bug fix

Estimate the time to required for testing accurately 

Estimation is one of the important aspects of software development. Wrong estimations lead to development of poor software quality. Consider there is sufficient time for developer testing. The great things happen when something is done in hurry. You did not test the product thoroughly because you had no time because estimation was wrong. As a best practice, the estimation has to be done by the person like Software Architect who understands the entire design and hence he/she knows the what the product features might get affected by a particular code change. 

Automate the Test Cases 

This is going to save lot of time and quickly gain the confidence over the product by looking at the automated test report. As a best practice the smoke test cases have to be automated. I have seen it so happens that most of the time, the test cases are not updated whenever there is code change. The automated test cases should always be in sync with the code changes. It is ignored mainly because it was not planned to revisit the test cases. The estimation should consider updating the test cases also.

Understand the Domain well

In certain organizations, the domain knowledge plays very important role. It does not suffice if you know the technology and you can write quality code. I have seen several instances where the product failed because developers did not had domain knowledge. It ultimately matters how our customers are going to use the product and hence product needs to be tested from customers point of view and this can happen only if the person who tests the software product has the domain knowledge in depth. You must have read the story why domain knowledge is so important!

Set the goal of Zero Post release defects

Yes, there has to be commitment towards this and goal has to be defined. This will bring the right spirit for the developers and will encourage the developers to be very cautious while dealing the change requests and while testing impacts of the bug fixes. Write down this goal on the visual board for everyone to know you are committing to zero post release defects.

I have shared here what we managed to reduce the bugs/issues being reopened. This is essential especially if you are dealing with change requests for a maintenance projects. Also have look at my another article on how handle to change requests effectively. Hope this will help others too.