Introduction
If you are working in a project that delivers software to the customer, you might have already worked on issues reported by the customer. Sometimes, a developer or a support person spends sleepless nights investigating issues reported by the customer. Can you think of zero customer reported defects of a software? Is that even possible? Why do you need to deliver defect free software? Obviously, no one wants a product with defect. Even after doing all kinds of tests like unit test, integration test, system test, user acceptance test and so on, you might see the defects reported from the production. So, let us discuss about the need of a software without defects or bugs and also see the ways we can reduce, to be precise, eliminate these defects before we deliver a software to the customer.
How Does the Defects Affect Us?
A defect identified in production has several negative impacts that an organization always tries to eliminate. It can impact the reputation of the company in terms of customer satisfaction, the organization's quality process, project management and overall company's delivery quality. It can even affect future business. Especially, the high-severity issues have a larger impact because of the costly resolution process. If the defect had been identified in the pre-production environment, we could have avoided such negative impacts on the organization.
What can We do to Eliminate the Defects?
A developer should always try to deliver the best quality products to the customer. With some project management processes in place, we can reduce customer complaints and ultimately improve client satisfaction. I am not going to explain here about test strategy or software development life cycle or standards and guidelines. I will highlight a few areas during software development, testing and production deployment that will help reduce production defects and improve the delivery quality.
1. Understand the Requirement
Here are a few questions - Is there a documented requirement from the customer? Did you understand all the requirements? Did you have a discussion with the person or the team who provided the requirements? Are all queries or doubts answered, documented and approved by the customer before you jump into the design/development? There may not be a formal document, but at least those should be documented somewhere and everyone including the customer should be on the same page as far as the requirements are concerned. This will avoid many unnecessary questions, confusion, and ambiguities and reduce defects in the future. The entire project is dependent on this, any unanswered questions, doubts, or confusions will result in rework and more defects in addition to cost escalation and delay in project delivery.
2. Get your Design Reviewed
Once the design is done, let the team review it. It could be system design or database design. Senior developers should be involved in this work. Does the design properly address the requirement? Any design flaw will lead to a huge change in the future depending on what phase it is identified and that is not desirable at all. As the coding will be based on the design, make sure the design is correct, reviewed and addresses all customer needs to reduce defects later.
3. Test Each Line of Your Code
This is for the developer while developing the program specific to a requirement. Each program segment with proper test data should be tested. IF...ELSE condition, FOR-LOOP and WHILE-LOOP, SWITCH...CASEs should be tested with correct test data to satisfy the condition and meet the requirement. To test a FOR-LOOP, make sure you use test data so that LOOP runs more than once. Do not test a LOOP with just a single iteration. Also, make sure LOOP has the condition for exit. This part of the testing is crucial, as each and every line of the code has to be tested. So, make sure you keep significant time while estimating the overall effort. This is called unit testing and has a significant contribution to reducing defects.
4. Create Proper Test Data
Often, the developers skip some test cases because of a lack of data in the development or testing environment. This is not desirable at all. Understanding the requirement and creating test data based on that, needs experience and time. You might have to use some tools to create test data. If you are using Laravel, you can use Laravel Factory and Seeder to create test data with less effort. Check this topic How to use Laravel Factory and Seeder with examples. If you see, there are five cases in a SWITCH-CASE block, you should have data to test each case. It is suggested to document the Unit test cases with expected and actual results to avoid confusion in the future.
5. Get Your Code Reviewed by an Experienced Developer
Let a senior developer or team lead take a look at your code. An experienced developer can identify potential issues in the program for a particular case. He or she can also ask to change/rewrite a section of the code for better performance. Can ask to remove redundant code or unwanted code. The reviewer can check if the code will really meet the requirement even without testing. This is very important, a second person, even if he/she may be a peer team member, can give suggestions to improve your code. Do not think this is to pinpoint someone's coding knowledge, but this is a team work and everyone benefits from it. Code review has a significant contribution in reducing production defects.
If your program uses a database with a complex SQL statement, a senior developer can ask for a performance tuning of the SQL statement. If the software is supposed to work on a high volume of data in production, possibly the DBA can analyze the SQL statement and give suggestions to improve it.
6. Does your Program Interact with Another Module or an External System?
If your program interacts with other modules or if there is any interface with an external system, you must do integration testing to make sure all functionalities are working fine and there is no negative impact on the other module/system. If it interacts with an external system, make sure proper security is in place to access the external system and for the data transmission. Make sure these are set up correctly in production to avoid a call in the middle of the night.
7. Is Regression Test Required?
If you are working on some changes in an existing program or adding a piece of code to resolve an issue, you need to make sure your changes do not impact the functioning of other programs or modules. In other words, you should not introduce another bug while resolving the current issue. You must do an impact analysis and regression test for such changes.
8. Let the QA Team Test the Application
Let the Software Quality Assurance team test your code to check if all functional requirements are addressed and if they pass successful testing. In this case, the team tests each and every client's requirement and document them as success or failure. Failed test cases should be discussed with the developer and the code must be fixed/changed wherever necessary. The QA team retests those cases and creates a final report about QA testing. Based on this, the QA team creates a report for the management to show the trends of the number of defects over time for the team. The number of defects should reduce over time and a repeat of the same defects should not occur.
There could be cases where a separate QA team is not there for the project. In that case, a senior developer should be involved in managing this QA testing.
9. Is Performance Test Required?
If the program must run in a high data volume in production, you should have a performance test or load test for your program. Your development or testing environment might not have enough data like production. So, check it and accordingly do a performance test manually or using a testing tool. There could be many factors to consider depending on the type of project. A few cases are mentioned below for your consideration:
- Have all your SQL statements been reviewed by the DBA?
- Are the proper database indexes and constraints created based on the SQL statements, so that they can execute faster?
- What is the average data volume your query will run against and what will be the approximate growth of the data in production?
- Do you need to load all data in a web page? Add a filter or search criteria and display only the required data.
- Do you need to do a load testing by using a tool and have discussed about how many users can use the system at a time and what is the growth rate of the users?
10. Customer Testing
This is called User Acceptance Test or UAT. If all the above testing steps are followed correctly, you may expect fewer or zero defects in your software from the client which is a big achievement for the team. There could be some requirements mismatch at this stage, that needs to be discussed at the project management level and the client. This mismatch can also be avoided if you have documented requirements that are discussed and approved by the client at the beginning of the project. If there is any customer-reported defect at this stage, it needs to be discussed with the project management team and accordingly be resolved with high priority. Also, a root cause analysis is to be done for the defect along with defect resolution.
Once UAT is done, the project team must get formal approval from the client for a successful UAT and move to production.
If you follow all these tips, there is less chance for defects and also less chance for confusion in the future as you have all documents in place for testing. There is a high chance that the project will be stable within a short period of time with no defects in production. When the project goes into maintenance and support mode, even if a separate team gets involved, the number of support tickets will be reduced and the project can be supported with a smaller number of team members.
Challenge?
It may sound very simple and straight forward, but in reality, the project team needs enough time and resources to follow all these steps. Sometimes, the project team may find it hard to follow them, because of training needs and additional time needed for tracking and monitoring.
Conclusion
It is always desirable to identify the defects in the development or testing environments rather than discovering them in production. That will save cost, improve customer satisfaction, and also, it will ensure that a proper development and testing process is in place that the company can showcase for successive projects.