Lean Software Development Principle

This is the second post in a series of posts on a journey into the world of Lean Software Development. The post will focus on some approaches to helping you build quality into your delivery.



THE PEOPLE AND CULTURE




I feel it is important to first have the entire team on the same wavelength when it comes to quality. It is no good to have testers who are only interested in testing a completed product. Or developers who don't see the value in writing unit tests. Or BA's who are only interested in writing specs and engaging with the business.



If a developer is not prepared to ask for a code review from a peer, then they should not be on the team. Code reviews and pair programming are particularly useful in identifying issues in the code and also embrace a culture of learning and sharing.



A culture of quality must be embedded into everything that anyone on the team does. As Scott Ambler says1, your process should not allow defects to occur. However when defects do occur, the increments should be small. This allows you to validate, fix and iterate. This is where the agile development methodologies add a lot of value by working on small pieces of work.



DEVELOPMENT APPROACH



Developers must be writing unit tests, I feel it is inexcusable for developers not to be. And shame on all the managers who push teams to deliver at the expense of unit tests. Not writing unit tests results in quality problems being found late in the development cycle, by under-appreciated testers . That is if the defects are picked up at all. Nothing like letting your clients test for you! I know for a fact, that if I am making changes, having a suite of unit tests to run against my code increases my confidence in making the change.



Developers must also be checking in often, and the code they are checking in must be production quality. Small, complete, quality pieces of work, that are unit tested, should be getting checked in multiple times per day.



Another approach to improve quality is pair programming. I have always had a good experience when pair programming. We have generally provided better code and I have learnt something from the other developer with the defect count being lower. Having a developer ask for a code review from another developer is also beneficial, especially when the piece of code is complex. Four eyes is generally better than two eyes when picking up possible issues.



Quality Assurance should rather be seen as Quality Assistance2. The QA teams time and effort is much better spent assisting BA's and developers to identify possible quality issues up front and being pro-active. The Test Analysts should be helping the developers identify and write the correct tests with the correct test coverage and they should be helping the BA's to find potential quality issues in their specifications.



Testers should be first class citizens in the development lifecycle, not the second or third class citizens many organisations treat them like. If you can get the Test Analysts assisting up front with identifying unit tests, firstly they are completely aware of the change and secondly they are assisting with enforcing a Test Driven Development approach.



THE USE OF TECHNOLOGY



Now that you have got developers writing unit tests and testers adding value at the beginning of the development lifecycle, you need to automate. Setup a CI server such as Jenkins to run all the unit tests and deploy the code automatically into a test environment every morning. This way you know that you are deploying quality code(the unit tests have validated this for you), and yesterdays changes are available to be tested today.



Along with this, have a code coverage plugin such as Sonar running against the database. The developers should then get into the habit of viewing Sonar every morning to pick up any new violations they have added the day before. This is a habit we have instilled in our team and the first thing I do in the mornings, with a cup of coffee, is to fix any violations from the day before.



And why do testers still perform regression packs manually. Regression packs should be automated and run daily. The test analyst should only be updating automated regression packs to that they can be adding value, not doing what a machine should be doing.



IN CLOSING



Quality must be everyones mantra and should be instilled into everything that anyone on the project team does. Fixing defects adds no value to clients, and can actually degrade value when defects are picked up in production by a client.



REFERENCES



* Agility@Scale: Strategies for Scaling Agile Software Development available at

* Agile Testing: It's about time - Atlassian Summit 2011 available at
Full Post