The text that follows is owned by the site above referred.
Here is only a small part of the article, for more please follow the link
The following is a guest post to Zephyr from Venkatesh Krishnamurthy. You can read more of his writing at his blog http://agileworld.blogspot.com/.
How to avoid these three bad quality assurance strategies
One of the primary purposes of any Quality Assurance (QA) team is to help the organization in building a defect free and quality product. However, even now most of the organizations end up building poor QA groups.
This article provides examples of 3 QA strategies that are not only poor but costs a lot to the company.
Case Study 1: Increasing the quality team won’t improve the quality
In a certain case study, the factory had a small group of “quality inspectors.” The demand for the product led to the increase in production capacity and inturn the number of defects as well. The organization thought that the insufficient number of quality inspectors is the primary cause for the quality issues, and doubled the quality group.
Do you think it solved the quality issues? Even though the number of defects being caught increased significantly, the quality issues continued to plague the product.
As Deming says, “Quality comes not from inspection, but from increasing the production process.” He continues to say “Inspection does not guarantee quality nor improve quality. Inspection is too late.” The only way to improve the quality is by “building the quality-in” during the production process.
Even though the example is from a manufacturing setting, the context is seen in the IT industry as well.
Case study 2: Multi-tier inspection process
In another case study, the organization created multi-tire inspection process to solve quality problems. Tier 1 testers would sit close to the development team, and they would run a set of test cases before handing it over to tire two testers for the next round of testing. Do you think this process improved quality? No way.
In the multi-tire testers’ case study, tier 2 testers trusted tier 1 to have done their job and skipped detailed testing before handing it over to the next tier. Defects escaping tier 1 continued propagating and not making any considerable improvement with quality. This is another example of a bad quality initiative.
Case study 3: Sign the dotted line
The quality issues with a product company became so rampant that the program manager started asking the QA manager to sign a dotted line. That is, before every release, the QA manager was supposed to sign, literally a document saying his team has tested the product well, and there are no quality issues.
Anyone can guess the situation with this team. It was like a boiling pot. The QA manager whipped his testers to ensure there are no defects. The testers in turn beat the hell out of developers by breathing around their neck all the time with a list of defects. The relation between the development team and QA team was a bad sour, each one defending their position with tensions rising high. The entire team missed the deadline again in this whole process.
Creating fear, stress or punishing people for quality issues will never improve the quality. Quality can never be improved by adding more people or creating additional quality checks.
Here are some of the tips to keep a check on defects and improve the quality of the product:
- Quality is everyone’s responsibility: Ensure that team understands that QA is not the only team responsible for quality but everyone. The quality is created at the source.
- Create learning organization: A safe to fail environment should be created for learning purposes, and people shouldn’t fear doing mistakes.
- Systems thinking culture: Team members should be involved in understanding the bigger picture and purpose of doing the work. Don’t force the team to focus only on their area and let them venture around to learn from others.
For example, in most of the Agile teams, Business Analysts(BA) are entrusted only with requirement gathering, developers focus only coding, and testers own the quality. This is wrong way of doing software development.
Everyone in the team should be involved and capable enough to gather requirements, coding or testing. The narrow-minded focus and specializing is one of the key culprits leading to quality problems.
Everyone in the team should be involved in understanding the bigger picture and should strive towards creating a common mental model