Last couple of weeks I have been writing about some of my pet peeves with regards to software development. Here is one more…
This is a follow-up to the article I wrote on having too many roles in a software development team. I think having too many roles dilutes the accountability within the team. Back in my programming days (20 years ago!), I have been part of quite a few development projects where there were no designated testers in the team. Granted the technology stack was not so complex as today, but the “programmers” in the team used to code, test, build and push it into UAT/Production. We did not always have the luxury of having testers in the team to act as a safety net for the programmers. If anything failed in UAT/Production, there was no ambiguity on who was accountable for the defect.
Testing Rigour is Slipping?
Last few years, managing large software product implementation/support projects, I have noticed that the rigour of unit testing seems to have fallen out of favour with the programmers. Once the coding of a module is completed, it is thrown over the wall for the testing team to identify the defects. I have seen programmers releasing code to QC environment and in less than 10 minutes the testing team starts reporting defects in the code. In most cases the defects were simple issues which a few minutes of unit testing could have caught. Unfortunately, most programmers probably think that testing is not part of their job and that their job is done once the functionality has been coded. As long as the code compiles without any errors, it is expected to work as coded. The days of the programmers subjecting his/her code to negative testing, boundary condition testing, performance testing etc before releasing it, seem to be a thing of the past. It might look like I am making a sweeping statement, but believe me, I have been seeing this phenomenon for a few years now. The thinking these days is “I am done with the coding. It is up to the testing team to find if there are any defects”.
As someone pointed out, “If you don’t like unit testing your code, most likely your customers won’t like to test it either”.
Programming includes Unit Testing
Writing unit test cases before actual coding makes one think harder about the problem. It also exposes the edge cases and makes one write better code. While there are automated scripts and other aids for unit testing, it all finally boils down to the programmer announcing that the coding is complete. Regardless of the development methodology – Agile, Waterfall etc – any code that is not accompanied by executed unit test case results should be treated as incomplete and defective. Testing is an inherent part of coding and should not be regarded as optional. Defects revealed by a unit test are easier to locate and relatively easy to repair and as one of the commandments of SDLC goes, any defect detected later in the life cycle is more expensive to fix.
Kent Beck, the creator of Extreme Programming, has rightly said, “Testing is not the point. The point is about responsibility”