Bug prevention before code leaves dev environment
3 steps bug prevention strategy before code deployment to test environment
During the development process, it is more cost-effective and efficient to fix bugs in earlier stages rather than later ones. The cost of fixing an issue increases exponentially as the software moves forward in the SDLC
What's more efficient and cost-effective to fix a bug before its deployment to a later stage from the local environment.
Below mentioned strategies can help in defect prevention in local environment
1. Knowing the Right thing to Build — Clear requirements:
All the team members should actively participate in sprint planning so that there is no space for ambiguity and then they can confidently own a task end to end .Team should hold regular discussions and meetings for there course of action.
2. Testers to review Unit tests:
Developers should write comprehensive unit tests including both positive and negative scenarios. Usually, dev’s code is reviewed by other developer but it will be a good practice if tester reviews unit tests.
3. Test data preparation techniques:
Developers should be made aware of test data preparation techniques used by the tester. They should incorporate the following techniques in preparing their unit test.
- No data: Verify the system returns a proper response when the field is left empty or value is passed as “NULL”
- Default data: Run the test cases on default data
- Valid test data: Also known as positive testing. It is necessary to verify the system is working as expected with expected valid data.
- Invalid test data: Proper response or error messages in the case for invalid data e.g if the field is expecting alphabets the invalid test case will include numbers and special characters.
- Boundary test data: Prepare test cases for upper and lower boundary conditions. e.g if the field is expecting a number of characters from 2 to 25. The test data should contain 1, 2,3 ,24,25,26 characters.
- Equivalence Partition Data Set: Test data qualifying the equivalence partitions.
- Input/Output: I call it input and output technique for FE applications e.g when user clicks on button, then red color is displayed, the button is tappable when user taps on it, text highlighted on certain action by the user and so on
The above is just a guideline. I totally agree that everything cannot be unit tested and even though with unit test , some scenarios need to be tested in integration or end to end. E.g “a button is clickable “, even if its unit test pass it had a chance to show unexpected behavior on browser tests. Therefore, its important to keep different scenarios while skimming through test cases for unit testing. Nonetheless, the importance of unit testing is not debatable.
For any kind of suggestions, feedback or queries, please feel free to contact me at my email address nidasaleem333@gmail.com
