Built-In Quality Process is from Lean Manufacturing. While whether Lean Manufacturing concepts can be applied to Software, which is a dynamic, is questionable, in this blog, let us look at the objectives of Built-In Quality and whether they have been successfully implemented and achieved in Software Development.
The primary objective of Built-In Quality Practices is to reduce waste. Taking a leaf from the lean manufacturing, where after-development product inspection generates not only material waste, but also waste of time, money, and effort of the people involved, the Software Development folks, especially the Agile Built-In Quality proponents are looking to eradicate waste by preventing defects as early as possible so that there is no rework with the fixes. The Built-In Quality concept is not new, and finding issues and defects as early as possible has been an initiative in Software Development even before the word Agile related to Software Development was born.
Let us look at major built-in quality initiatives that I think are important in Software Development and in which Software Testers should take part. There could be others, but in my opinion, these have the potential for significant impact in preventing issues and defects upfront leading to waste reduction and building reliable and quality software.
Conversations about Requirements
As much as it is the responsibility of the business analysts to elicit requirements from the customers and end-users, it is absolutely important for software developers and software testers to take part in elicitation process. During these meetings, software developers and testers can ask questions to get clarity on the requirements so that issues don’t arise because of unclear requirements. Focus should more be on the conversations rather than streamlining the requirements acquisition. I have heard of bad practices where the development team would get the requirements in an excel sheet from the customers and convert them to Gherkin files for BDD or ATDD. Time well-spent on requirements conversations result in much better quality product.
Architecture and Design Reviews
Having a baseline architecture and design is key in building a product with a plan. Agreed that there will/might be changes to requirements, but to proceed without a blueprint for a product would be a mistake. Architecture and designs should be reviewed by the entire team including Software Testers to make sure that all aspects of Design Considerations are taken care of.
Test-Driven Development
Test Driven Development tests if the implementation would achieve the expected behavior of an unit of software. It is the closest to the developed code, and hence can be effective in preventing programming mistakes, implementing boundary-value checks, implementing equivalence class partitioning, and effectively implementing unit tests, if implemented correctly. I have written an article on how Software Testers can effectively contribute to TDD.
Ensemble Programming
Software is complex. To take care of design considerations, we need knowledgeable and expert people from various backgrounds. We need their inputs as early as possible so that issues and defects can be prevented as early as possible. Ensemble Programming enables meeting of knowledgeable people from various backgrounds while the code is being developed.
Reality Check On Built-In Quality
Now let’s do a reality check on how these important aspects of building in quality are implemented in organisations.
As far as I have heard, TDD and Ensemble Programming are not done in most of the organisations. There are some reasons quoted. The major ones are that developers want ‘freedom’ to do their style of programming and don’t want to be imposed upon by preset rules on how to do things, and TDD and ensemble programming are time-consuming and takes a lot of bandwidth of the relevant stakeholders. Well, I personally wonder where these stakeholders would be spending their time elsewhere rather than participating in these sessions and building a quality product. But, it is what it is.
I have heard and seen many instances where relevant stakeholders are not invited (purposefully, downplaying the role of the stakeholder) in meetings. While developers and testers are not invited to requirements elicitation meetings, testers are not invited to architecture and design reviews done by developers. Please note that ‘passing-on’ information from one team to another second-hand leads to miscommunication and leads to defects.
So, there we go, the reality check of built-in quality. Every one of us clearly understand the Built-In Quality meaning. Note that most of the issues mentioned above can be rectified by having a culture which understands the importance of finding issues and defects early on. Note that I am not undermining the testing that happens post-development in any way, and I have written a lot about its importance already. I am just saying that finding issues and defects early on saves everyone’s time, effort, and money.
It is important that Built-In Quality slogan does not stay as just that and becomes a practical, living thing in our software development efforts.
For consulting on implementing BiQ – Built-In Quality in your organisation, feel free to contact me.