Quality at the source

Welcome to installment number twelve of applying lean manufacturing concepts to software engineering. 

One of my favorite concepts in this space is great for quality culture, unless the quality cult slips in.  If I could put this phrase on a marquis, I would:

“Don’t wait until the end of the project to begin testing”

Per https://www.leanmanufacture.net/leanterms/qualityatthesource/, Quality at the source prescribes to measure quality at every step as opposed to doing this at the end of the assembly line.  Everyone contributing to this project is responsible for checking one’s work before involving the next person.

My first article in this series discussed debugging the requirements.  That is a big source of reducing defects.  But where else in the software development process can we increase quality at the source?

In companies with a more mature software development process, the creation of a test plan before coding begins is another source of quality because it’s essentially a checklist that the developer(s) need to follow.  This reduces bugs of missing required functionality.

Next, I do not think enough developers appreciate the importance of creating unit tests before checking code into the source control system.  A standard debugging technique when multiple systems are involved is to isolate the local system from the other systems to rule out effects from other systems.  To have quality at the source, one must make sure the local system works as designed before testing with other systems.

Code reviews are very helpful in quality concerns because your colleagues can be subject matter experts on the code you are working on.  They know pitfalls, shortcuts, workarounds, and sometimes best practices.  I like to think that code reviews led to the development of crowdsourcing.  There are aspects of code review that lead to a quality cult, but I want to accentuate the positive and eliminate the negative (apologies to Bing Crosby and the Andrews Sisters).

I am a fan of regression testing, preferring both manual and automated testing.  There are trade-offs involved, as extra effort is necessary to maintain automated testing, but if tests are performed frequently, each iteration of testing is quick and consistent.  Manual testing tends to make individual testers very knowledgeable, and if one of those testers is on vacation, the other testers cannot provide the same level of insight to the defects found.

One of my least favorite aspects of manual testing is that bug reports can be subjective.  Referees are sometimes required, and they must make judgement decisions, some of which are unpopular.  In the end, one must focus on the perspective of the paying customers.

 Quality also needs to be designed into the software, and that will be discussed in the next article.