The SQA2 Blog: Advice Center, General
QA 2.0 is redefining what it means to be a modern Software Quality Assurance professional. In the modern era of software development, QA has to provide a holistic approach to quality assurance. Testing and identifying defects after they have been created is TOO LATE. QA 2.0 shifts the focus towards prevention of defects in all areas of the SDLC. In an effective QA 2.0 environment, QA 2.0 professionals or “Quality Advocates” mentor the software development team to become a Zero Bug organization.
The QA 2.0 Pillars
Quality Advocates do this by placing an appropriate focus on 8 QA 2.0 pillars, which guide the focus of every Quality Advocate. These pillars are:
- Requirements Quality
- Design Quality
- Code Quality
- Quality Control
- Process Quality
- Infrastructure Quality
- Resource Quality
- Knowledge Quality
Requirements Quality
Ensuring the requirements are of high quality. This involves advocating for best practices for requirements documentation, storage, universal team access, etc. This also involves practices that ensure the team understands the requirements. A Quality Advocate should be identifying test cases early and reviewing those test cases with developers and product owners. This provides the opportunity to clarify any issues and remove any miscommunications in the requirements before code is written.
Design Quality
Ensuring the design of the software follows best practices and produces a product that can be tested easily and efficiently. A Quality Advocate would be pushing to incorporate industry standard practices and principles in the design of the software such as using established coding patterns and frameworks. This also involves providing input on the design of the software in terms of testability which prepares the way for effective and efficient testing.
Code Quality
Advocating for adoption of industry standard coding practices such as writing unit tests and maintaining an agreed upon level of coverage, pair programing, peer review, unit testing, tracking code in an SCM, etc. Maintaining automation coverage across the critical path and regression test plans also falls under Code Quality. The focus of Code Quality is to ensure the code itself is of high quality.
Quality Control (QC)
Quality Control is what is most commonly known as testing, traditionally the sole focus of most QA organizations.
Ensuring what was asked for by the product team was delivered by the engineering team accurately. If Requirements Quality, Design Quality, and Code Quality have been implemented properly, QC is just a formality because bugs have been actively prevented. QC is just running through the checklist so-to-speak of the requested functionality.
This is the last stage in the SDLC where bugs should ever be found. Any bugs found after this stage is an absolute indication that there is process improvement to be made in one of the 8 pillars.
Process Quality
Every team can improve on what they are doing. It is up to Quality Advocates to push for this improvement to happen. Most importantly, the Quality Advocate should partner with their team to propose right-fit process improvements, moving the team towards a Zero Bug organization through implementation of the 8 QA 2.0 pillars.
Infrastructure Quality
The stability of all environments is important. Ensuring you have a strong and stable production environment is important to maintain revenue and ensure the company continues to get new customers and keeps existing ones. An unstable production environment directly impacts the bottom line. A Quality Advocate should push to implement best practices in infrastructure such as load balancing, scalable environments, adequate hardware, and comprehensive monitoring.
Infrastructure Quality is also important in non-production environments in order to maintain efficient execution of daily responsibilities. Stable dev, QA, and staging environments enable the team to execute on any building, testing, and automation throughout the day without interruption.
Ensure that none of the environments cross-talk with each other. This is an important Infrastructure Quality aspect that is often overlooked. Keeping environments cleanly delineated is critical to the reliability of any testing done in non-production environments. If the non-prod environments are not similarly structured like production, you cannot rely on the testing done in those environments. A Quality Advocate must push for the implementation of quality environments to ensure testing can proceed without delay as well as to ensure testing is reliable.
Resource Quality
Are the right people taking on the right roles within the team? Are those individuals properly trained, continually learning, and continually growing? Are they trained in the software and applications the team is working with? Are the teams properly balanced with the right mix of developers, product, and QA? These are the questions a Quality Advocate should be asking of their team to ensure the team is running as effectively and efficiently as possible. If any of those are a “no”, then the Quality Advocate should be highlighting this to the team and asking for change.
Knowledge Quality
It is incredibly important to know what should be happening and how the application is expected to function. Even more so, it is foundational to all other work that we know the “Business Why”. The Business Why is the reason why things the way they are in a company. Why do we have this set of software? Why do we run these reports? Why do we provide this service to our customers? All of these questions and more inform the work we do in all other pillars. So it is important to know and to continually add to and update documentation to maintain a high level of knowledge quality.
It’s all about focus
Everything mentioned so far seems like a lot to keep track of. This all really only scratches the surface of the full scope of responsibility of a Quality Advocate. But how do you focus on all of these things within any given work day?
In most companies, QA puts most of their focus on QC, leaving very little time to focus on other areas. Unfortunately, QC has little impact on the overall quality of the software since QC is just detection of bugs after they’ve already been written. This is a lopsided return on investment.
When implementing the other 7 pillars of QA 2.0 properly, QC is just a formality allowing the team to reduce their focus on QC. Combined with good coverage in automation, most of the QC work can be done for you. This allows the team to reduce their focus on QC. Our recommendation is that only 10% of QA’s time should be on QC. This aligns with the return on investment you get from QC and puts a higher focus on areas where quality is impacted the most.
The recommended distribution of focus by a QA team member on the 8 QA 2.0 pillars are:
- Requirements Quality – 20%
- Design Quality – 15%
- Code Quality – 15%
- Quality Control – 10%
- Process Quality – 15%
- Infrastructure Quality – 5%
- Resource Quality – 10%
- Knowledge Quality – 10 %
Traditional Focus, Low Impact on Quality
Recommended Focus, High Impact on Quality
The areas that have the highest impact on overall quality are Requirements Quality, Design Quality, and Code Quality. These areas are intended to prevent defects, finding any defects left in the 10% of QC. The rest of the effort is spent on improving future cycles with 40% going towards Process Quality, Infrastructure Quality, Resource Quality, and Knowledge Quality.
How do we get there?
The first step in achieving a Zero Bug organization is to first understand where you are. Measure where your focus is being placed. Engage with a Quality Advocate professional who can assess your organization’s process effectiveness and efficiency. They can tell you whether you’re doing the right things (Effectiveness) and if you are doing those things right (Efficiency).
Curious where your organization lands? The experts at SQA² can perform a high-level assessment with a quick phone call to give you an idea of where you might need help. Additionally, we provide a deeper assessment of your organization which will give you a detailed report of where you are, what areas you can improve, and a road map to get there.
We can provide valuable insight like where your organization lands in terms of Effective and Efficient process and provide reports that tell you the areas of correction.
Example E² Assessment Charts
E² Quadrant Chart – Depending on where your organization lands will indicate the change needed in your process.
- Quadrant I indicates that the team is doing the right things (ie. the correct processes are in place), but they need to get better at how they do those processes.
- Quadrant II indicates that overall, the team is doing well in both Effectiveness and Efficiency in their process.
- Quadrant III indicates that the team needs to improve in doing the right things (ie. putting the correct processes in place) and doing things right (ie. performing processes well)
- Quadrant IV indicates that the team is doing some processes they have in place well but need to add processes and start doing the correct processes to positively impact quality.
E² Quadrant Chart Example – An example of an organization’s E² rating on the E² Quadrant Chart. They landed in Quadrant III, which means they need help putting the right processes in place and help with doing those processes correctly.
QA 2.0 pillar breakdown – Example of a detailed breakdown of the QA 2.0 pillar focus for an organization. This example organization scored low in pillars such as Requirements Quality, Design Quality, Code Quality, and Process Quality. Because of these low ratings, their overall E² scores were low.
Let our experts help you understand your organization. Let us know how we can help you by reaching out with the contact form below.
