In 1924, W. A. Shewhart of Bell Telephone Laboratories developed a statistical chart to control product variables. This chart is the beginning of statistical quality control as we know it.
After the second world war, engineers W. Edwards Deming and Joseph M. Juran, who worked as consultants in the Japanese manufacturing industry, created the concept of Total Quality, in which quality extends beyond the manufacturing process to all organizational processes and instills the values of quality in every worker called – Total Quality Management (TQM)
Since 2000, TQM has evolved to meet the needs of a changing marketplace. Universalisation and emerging technologies have exploded in both the scope of quality and the tools used to meet Quality standards. New methodologies like Six Sigma have achieved higher productivity and services free from defects. Quality can now be applied to any organization, including benefits, government, healthcare, education, and even new technologies like Bitcoin and Blockchain.
Testing over the years
When people mainly followed the waterfall methodology, the business analysts wrote the requirements, the developers coded the criteria, and the Testers tested the criteria. Each of these people was responsible for different silos and did what they were expected. Quality was thought to be analogous with testing and therefore was considered the Tester’s responsibility solely.
But nowadays, when the world has moved on to agile methodology, the barriers have been broken down – quality is not just a testers’ responsibility anymore. The whole team owns quality. The best agile teams have a mindset that everyone is responsible for quality. There are multiple ways that the team maintains quality. It is supported from the very beginning and not just measured with testing. Because testing only detects defects, quality assurance prevents defects. Teams that own quality are willing to contribute to it any way they can.
Making Quality everyone’s responsibility
People usually believe that project managers and other leaders are less educated about testing. So misconceptions are usual. However, if you ask today, they would tell you quality is everyone’s responsibility. But no one will tell you how it is everyone’s responsibility.
What role does everyone play in making a quality product? A product owner translates user needs to user stories and works with developers. Developers who develop these user requirements and features and make them more user-friendly. Testers understand what needs to be solved and what needs to be tested to satisfy the customer. A tester with facts can influence the decisions about a product but ideally should not be making decisions about the product. It’s not that testers cannot give their opinion, but coming up with solutions and features for the product should be left to product managers.
Although we have changed our opinions towards the roles with quality and now believe quality is everyone’s responsibility, we should recognise the necessity for engineers with a quality emphasis. Having engineers focused on product performance, user experience and customer scenarios, internal development, and security ensure that these areas prioritize the product and that any issues in those areas will have a voice.
We don’t look to these teams to handle scale, UX, security, etc.; we expect these teams to deepen their understanding in these areas.
Quality is not a one-off process, and it is a continuous process. It is not the result of efforts from a single person, but it is the team’s effort. We have to make it a habit of delivering a quality product; that is how a new brand is born into the market and known for its standards. Quality is not an act! It is a habit!
Communication is the key
Good understanding between the teams is one way to ensure quality. Creating cordial relations between QA and Development will minimize the difference between the two groups. Testers can work with scrum masters for advice and input. They can work with Product managers to give and receive feedback on acceptance Criteria or test cases and defects. The result will be ensured quality in testing teams.
Opportunistic pairing is another technique for ensuring quality. The pairing could be Developer with Developer, Tester with Tester, Developer with Tester or even the Developer, Tester and Product manager. Pairing reduces post-implementation code reviews and reworks in many cases. Each person in a team will get visibility into the other person’s tasks and processes.
With good understanding and freedom within the teams comes the ability to question and even disagree. So it might mean some features need to be redesigned around testability, testers need to shift on what they think the most critical tests are, or the team takes a calculated risk around what will be validated. The crucial point is understanding the risk and discussing what tests are essential for today and the sprint. Engaging everyone in the conversation helps shift more toward the idea that quality is everyone’s responsibility.
Conclusion
When the project team correctly describes quality specifications and the organization has set up a procedure to ensure quality control and assurance measures are taken care of, the project is more likely to be delivered of better quality and hence more likely to succeed.
For Instance: During the Planning Stage of a Project Life Cycle, documents are the majority component of the deliverables. Ensuring the teams submit quality documents will influence the project’s success.
Similarly, during the Execution Stage, the team should ensure appropriate quality control and influence its success.
Quality is just like security. Every person can contribute to having a safer product by identifying threats or ensuring the necessary actions are taken when they see any danger. So, every person can contribute to having a higher quality deliverable by understanding the project’s quality expectations and delivering up to its standard.
Published on Java Code Geeks with permission by Navya, partner at our JCG program. See the original article here: Quality Management – Whose Responsibility is it Anyway? Opinions expressed by Java Code Geeks contributors are their own. |
Thank you!