unit testing

Software developer or bug developer

If a person who develops software is software developer, why not the same person developing bugs in the software be called bugs developer. How many developers ethically perform the unit testing after completing development of a unit? It could be - None, a few of them, some of them, most of them or all of them. Some of them might be under the impression that they perform unit testing after completing a unit but the way they do it might not be really helpful in finding bugs. It might be just to satisfy them what they do and call it as unit testing.

If developers really perform unit testing, find out the bugs and fix them, in actual, then when testing is being performed by the testers why they have to perform unit testing again? Why can’t the testers skip it and save lot of money and time of the organization.

10 golden rules for Requirements Based Testing

10. Document with complete and clear requirements is as important as oxygen in the air: Requirements based testing is purely based on the requirements specified by the customer or software sponsor during the business requirements study phase. Documentation of all requirements (user level and management level) at micro level is very (Very) crucial. Missing out any requirements or unclear requirements can call for a big problem at the implementation and project close-out stages. Getting the sign-off to freeze all requirements is equally important.

9. Requirement freezing does not mean “No Change”: You can’t close your doors for a change in requirements after initial business study phase. The business and business rules keep changing thereby meaning that the CHANGE in REQUIREMENTS can happen at any stage after requirement freezing till the project close-out. The impact of change on time and cost is a different subject altogether.

8. Start building test cases” along with the development: The moment after requirement freezing as discussed in the first point above, the project manager’s first job is to do the resource management, requirements break down in tasks and task allocation for development. At the same time, the testing team has to start understanding the requirements and build their extensive test cases based on the requirements.

7. Business Knowledge is as important as the testing knowledge: The rule of 50:50 is applicable for both – the developers as well as testers. It has to be 50% technical knowledge and rest business knowledge for developers. Similarly the testers should have the same ratio between the business knowledge and the testing knowledge to write down the sensible test cases.

6. Confirm complete coverage of requirements in your test cases: Ensure that the requirements are completely and exactly covered as per the business need built in the software (or being built parallel). Incomplete coverage of requirements in building test cases will again result into a disaster for the project and product.

5. Change your test cases alongwith the Change in Requirements: For the purpose of requirements based testing, you have to keep modifying the test cases after understanding the exact changes required (documented and signed-off). Don’t forget to vet for the change coverage in your test cases re-built or modified as per the need.

4. Build a repository of your test cases: Building a repository will always help in saving of time writing the test cases afresh in case of similar (or same) requirements scenarios. So keep building your repository with clear documentation of the coverage a set of test cases is meant for.

3. Start testing as soon as one unit is ready: Don’t wait for the product development to complete. Start your testing as soon as the smallest unit is done, so atleast the unit testing is over alongside the development (and most part of integration testing too as the units are increasing during development).

2. Re-test to confirm: Re-testing of your test cases with the business requirements is as important as the re-verification of test cases built.

1. Measure the benefits of Requirement based testing over the post development testing: Don’t forget to build a small metrics to measure the benefits drawn out of your requirements based testing in comparison to the complete testing being started post development. This analysis will definitely reflect great results in terms of time, efforts and money.

TDD requires an extra punch of coding

TDD is test driven development in which the developers coding efforts become manifold. It is not only the development coding that developer has to write. Along with the requirements coding, the developer has to write code for the testing of each of the logic he has built in the product. It is more or less a unit testing where each small unit is tested individually by the developer as soon as he completes writing the code for it. All this is not easy to perform. It requires a different mindset to perform TDD. The developer has to be in a different frame of mind to accept first the extra work required from him. There is no extra technical skill set required in the developer, it is the mental preparedness that matters more. They have to overcome the resistance from within to do some extra efforts in coding. Although this could be a little painful but only in the beginning, afterwards, when the results start speaking loudly in lieu of the extra efforts done, it gives a different level of satisfaction to the developers.

The extra effort done by the developer in return saves a lot of time that is required for testing later since in TDD, the bugs reduce tremendously in such a manner that once matured, the later stage testing can be totally avoided.

TDD can be compared to Japanese companies environment as on-line QC in sub-assembly production instead of having QC of the product in the finished stage.