Is QA (aka QC) seen as an impediment in your organization? If you answered yes to this question, then chances are your organization is in one of two camps:

1) QA is really an impediment

or

2) QA is actually ensuring that your organization is releasing quality software.

QA is really an Impediment

Some organizations still have formal QA departments that execute testing as a separate phase than the development team. While this may be a necessity in some industries due to laws and regulations, for most other organizations where this is not required, it is usually a sign of a QA team that is not ready to change. It is a sign that this QA team is not ready to meet the needs of a software team that is being asked to deliver software more frequently and keep the level of quality high.

Usually this is a sign that some members of this QA team are concerned about the obsolescence of their role as they see signs of the developers being able to do their jobs through automation.

However, if this is the type of team in your organization, then someone needs to make them aware that the move of the majority of software organizations towards Agile is an opportunity rather than a threat.

When we encounter teams like this we ask them; “Why would you prefer to do a job that is very repetitive and sometimes not valued, over a job that would challenge you and would be valued by the organization?” There is a new role for QA in the Agile world, QA teams that are seen as an impediment just need to be shown what these new roles are.

QA is actually keeping the organization humming

With the ever increasing demands to release software more frequently, sometimes QA seems like an impediment but the reality is, it is QA that is actually allowing the team to deliver the software. Deadlines are forever pressuring developers to write code faster and get it out. This constant pressure can cause developers to cut corners in an effort to “just get it out”. In these types of cases, most developers actually find solace when their QA teammate helps remind them the implications of releasing code that’s just not ready. It is in this solace that the appreciation for their QA teammate is highest. At this point the developer and QA actually work together to ensure that a better quality software is released on time.

When this happens it is one example of building in quality rather than trying to test in quality!

In this example the QA team member initially looks like an impediment but he/she is actually trying to ensure that the software is released with quality rather than working in a “Break/Fix” mode.

The concept of building in quality has been around for years. One of the best known advocates of building in quality is Philip Crosby. Mr. Crosby was one of the first people to advocate that if you build something of quality, then Quality is Free! He had many different ways of delivering this message to management but this was the essence of his message.

Most QA people in organizations have this kind of a mind set and try to advocate it but are frequently seen as signs that the QA person is an impediment to just getting it out! Remember that when a QA person provides their feedback on the state of a feature in the software, they just want to deliver the right feature, at the right time with the quality that the end user would expect.

With the move to Agile, the decision to ship has now been moved to being one the Team makes together based on their Definition of Done. Even though the Team now works together, the QA person will still bring this quality mindset to the team, a mindset that should be shared across the Team.

If you are still thinking that despite a QA person’s good intentions, they are still an impediment, think of one more thing.

Delivering quality software means that you incur less Technical Debt, less Technical Debt means that the Team will be able to work on new features in future sprints rather than working on refactoring code and features.

Finally, these higher quality deliverables are essential if one of your goals is Continuous Integration and eventually Continuous Delivery. It will mean that your organization is able to respond quicker to market forces and it will translate into a competitive advantage for your organization. An advantage that will translate to savings and sales for the organization!

If you want to know more about how to ensure that your QA team members can help ensure higher quality deliverables, while meeting the fast moving software delivery train, please contact Exempio for a consultation.