Testing or Quality Assurance.....

Ok so I've had a few discussions over the past week that got me thinking (It may be painful, and often has dire consequences but I do occasionally partake in this past time).

So are you testers? Are you QA? Does it matter?

You could be either or you could be both it depends on your approach and no one approach is right or wrong.

I took to Google to see if there were any wider opinions on this and came across this blog post
http://www.developsense.com/blog/2010/05/testers-get-out-of-the-quality-assurance-business/

Now I'm not suggesting any of his opinions are invalid in any way. Moreover I actually think that his point is perfectly valid, certainly from an attitude/interaction perspective.

Getting the respect from the developer and dealing with things you raise in the correct manner is a large part of testing. Testers are testers for a reason and usually have a given skillset that allows them to be good at validating software.

What I think the above blog post misses (or avoids) is that different teams and team dynamics, different development models, different structures etc. do influence where and how testers (or Quality Analysts) should be involved. There isn’t any hard and fast rule around how involved testers should be or how far the influence of said testers extends.

Let’s take an example:

A traditional development team following Waterfall: Testers get provided with requirement documents and write all the test scripts while developers perform their magic. A code complete build gets handed over. Testers cast there critical eye over the software in a structured way and report back defects they find. This may go round a few iterations until everyone is happy to release the software (or until someone high up in the business says it has to go out in its current state).

Generally a team working in this way will have reasonably structured and very specific roles such as business analyst creating requirements, developers writing code and testers checking that the software works as expected. As such you will usually find accountability directly attributable to a given function for failings and therefore it is in the interests of a tester to ensure they are fully focused on performing the testing as effectively as possible. This isn't necessarily a bad thing but it can sometimes foster a "that's someone else’s problem/fault" attitude within the separate entities.
Given this scenario, I would generally agree that a tester’s role isn't Quality Assurance but more Quality Control (a part of a quality assurance function but not the whole picture). I've been dragged into talking semantics but I will spare you the 'what is quality?' rant.

Ok let’s take an alternative example:

A forward thinking development team trying to deliver value quickly following Agile: A product owner (product team) produce stories in line with the users functional needs. Although the expertise within the team is obvious, the team as a whole are responsible and accountable for delivery. The user stories are fleshed out as they move to the top of the backlog with input from the whole team. The development team (including test expertise and product owner) want to target a right first time approach rather than a find and fix approach. They release monthly but are targeting moving to continuous delivery and because of a good level of automation have a risk based approach to release (regression) testing, keeping the required level to what is necessary.

In contrast to the more traditional software development approach, the roles in such teams are not as clearly defined, it is just understood that as a team they are responsible for delivery. Analysis, test and development skillsets are all present in the team however it is important that whilst those with the expertise provide the guidance and advice on their specialist areas, the team input together into decisions and work. In a team such as this, to effectively provide delivery on a regular basis every defect found by test after completion of the development work is a delay. It is in the entire teams interests to ensure all the cogs of the team are working as well as possible towards efficient delivery and where this is not the case it is identified as early as possible.

In a scenario such as the above I believe it is important that one or more people in the given team have an inquisitive approach, willing to ask the right questions and to challenge whether things are being done with consideration for quality in mind. This is in much the same way as it is important to have someone who is challenging whether the solution is the right technical solution (generally a dev skillset). They are not responsible or accountable (that sits with the team as a whole) but have the right knowledge and experience to ask the right questions. Following this idea, is it farfetched or inaccurate to suggest that in its simplest form you may have the following specialism within a team?

• Team Lead (Scrum master, Enabler or other)
• Developer (technical guidance/coding)
• Quality Analyst (product and process quality guidance)
• Product Owner (Domain and functional guidance)

Ok that doesn't necessarily mean that the Quality Analyst role fits nicely into a Quality Assurance bubble. Text books around Quality Assurance widen out the remit of Quality Assurance drastically. It does however demonstrate that a test role involving finding defects is not always representative of the needs of a test/quality role within a software development team. In actual fact the ability to be the team’s quality conscience can be a more preventative way of avoiding defects. This in my honest (albeit biased) opinion blurs the boundary from test into Quality Assurance sufficiently to suggest it cannot be discarded as a part a test/QA role. Helping to build quality in, as well as finding those things that slip through the net, isn't too taboo is it?

I'm sure you are more than bored by now so in keeping with my previous post I leave you with an utterly fascinating random image: