• info@helpingtesters.com
  • helpingtesters

Role of Quality Assurance in Team Dynamics

August 20, 2016
quality control, Quality Assurance, qa

None of us is as smart as all of us’ said Ken Blanchard, a famous American management expert. This ten-word quote sums up how important teams are for any activity, be it a sport where you have a tangible outcome or a software delivery where the outcome is intangible. This article focusses on the role of quality assurance in ensuring the right dynamics within a software team is maintained in order to achieve a higher Quality Assurance of output.

The 3 Pillars

Software teams have traditionally been made up of three pillars – Business Analyst (BA), Development and Testing. Gradually teams realized that testing is just a subset of a bigger activity called Quality Assurance (QA) which talks not just about ensuring the software built is defect-free but also takes steps to validate the requirements themselves.

An interesting article detailing the differences between Quality Assurance (QA), testing and Quality Control (QC) can be found here. QA is the judiciary which keeps in check the legislature (Business Analysis) and executive (development). Without effective QA, there is no Dev or BA.

The 3 Amigos

With the world becoming agile, the 3 pillars have been re-christened as the 3 Amigos. The roles have also become agiler and the power of QA has been taken to new levels. BAs are defining the acceptance criteria in the requirements itself.

Development is looking at Test Driven Development (TDD) as an automated way of testing their code functionally and regressively. Even though a lot has been written about the effectiveness of QA in guaranteeing a Quality Assurance outcome, not enough has been penned down on the role of QA in team dynamics.

What differentiates agile teams?

  • When we think of factors that differentiate between agile teams, the common guesses that crop up are team size and skills of members.
  • With the advent of agile definitions and standards, team composition across the globe has pretty much become standardized. They are small with less than 7 members, with not more than 2 members per functional role.
  • Smaller the team, agiler their way of thinking. Hence, take team size out of the equation as a differentiating factor for agile teams.
  • With information being so freely available nowadays and new technology cropping up at every turn, talents have found ways to cope with such dynamicity and easily adapt to changes.
  • Many organizations have a center of excellence (CoE) to ensure teams get all the technical help they require when they start out on a new venture. Even functional expertise has been documented profusely. Hence, take skills out of the equation.
  • Of course, there are other small variables like infrastructure, product visions, stakeholder support etc.
  • But, apart from all these, what makes one of two teams which are identical in team size, skill set, enabling functions to shine? The answer lies in team dynamics. The most intangible of all factors.

Team Dynamics

A team is more than just a group of people. Any organizational strategy that ignores the role of human psychology in the Quality Assurance of final product is set to fail.  Team dynamics is defined by Business Dictionary as “The behavioral relationships between members of a group that is assigned connected tasks within a company. Dynamics are affected by roles and responsibilities and have a direct result on productivity.”

Conversational example

Below are excerpts of conversations from teams A and B. Both are 3 member teams with the 3 Amigos. Let us see if is possible to get inferences on team dynamics from the two.

  • Excerpt 1 (Team A)
  • BA: Good morning Dev and QA (Team answers in chorus ‘Good morning!’). This BAsprint we are looking to build a dashboard which displays all the account information relevant to a particular online user.
  • DEV: OK, what are we looking at in terms of the dashboard?
  • BA: What we are looking at is this (Pulls out a sketch of what BA thinks the dashboard should look like). Basically, it needs to give all the account details and balances.
  • DEV: Looks cool, how about the color schemes?
  • BA: I am looking at the same model as the existing Account Information screen.
  • DEV: OK then, can be done.
  • QA: OK. What is the acceptance criteria?
  • BA: 1. Page displays after login; 2. Page displays account details and balances; 2. Page is on same layout and color scheme as Payments
  • QA: Fine.
  • BA: All right. Good luck!
  • Excerpt 2 (Team B)
  • BA: Good morning Dev and QA (Team answers in chorus ‘Good morning!’). This sprint we are looking to build a dashboard which displays all the account information relevant to a particular online user.
  • DEV: OK, what are we looking at in terms of the dashboard?
  • BA: What we are looking at is this (Pulls out a sketch of what BA thinks the dashboard should look like). Basically, it needs to give all the account details and balances.
  • QA: Looks good, are you looking at providing this for both online and mobile users?
  • BA: Good point, I think we need to add that as part of the story description and acceptance.
  • DEV: If that is so, we need to factor that in for our story point estimates. We might have to also split them into smaller stories. How about the color schemes?
  • BA: I am looking at the same model as the existing Account Information screen.
  • QA: OK. What is the acceptance criteria?
  • BA: 1. Page displays after login; 2. Page displays account details and balances; 2. Page is on same layout and color scheme as Payments.
  • QA: That is great for the happy path. How about accounts which are in negative or below permissible limits? Do we highlight them in red?
  • BA: Yes, let us add that into the acceptance criteria.

<And the discussion continues…>

It does not take a genius to understand that Team B is more effective, and would bring out the better product. What made the difference? A passive QA in Team A as against a QA who thought outside his role and has matured to a point where he/she is able to provide value by filling in the gaps.

This is a simplistic representation of one excerpt from the life of a product team, but a QA role, by virtue of his responsibility of assuring not only that the product built is correct, but also that the correct product is built becomes the penny that tilts the balance in Team B.

A person that does these two effectively puts himself in a position where he can question both BA and Dev. Conflict breeds creativity, and a richer and more realistic acceptance criteria are born out of the conversation- and that makes all the difference!

Dev-QA

Make QA Effective

How does one make QA effective? Below are some points to keep in mind.

  • Co-locate the QA with the rest of the teams (same geographical location).
  • Ensure QA is enabled. Involve QA from the beginning of time, from the time the product backlog is getting formed.
  • Enable QA both functionally and technically. It is understood that each of the amigos has their specialized roles to play, but enabling QA as a horizontal rather than a vertical ensures certain dependencies are identified earlier in the life cycle. It is a known fact that unearthing problem early and left-shifting defects are the need of the hour.
  • Sometimes it might not seem important for a QA to be involved in technical discussions, but often times a mature QA gets a lot of clues from such discussions about some aspects in the software that are prone to break. Leave the decision point to the QA, whether he/she wants to be part of a discussion or not.

Quality Assurance – Aspects of Personality

Talking about team dynamics and the importance of QA of making it a success merits a mention of what sets apart a great QA from an average one. At the end of the day, every person is different but there are some exceptional qualities that set the bar for Quality Assurance.

  • Patience – A QA might need to be involved in discussions which might not have a direct bearing on his roles/ responsibilities. Keeping patience in such meetings and understanding the indirect implications of such meetings on the effectiveness of a QA’s role is an important aspect.
  • Ability to think out of the box – A QA’s responsibility is to ensure Quality Assurance. Quality Assurance is such an ambiguous term and difficult to quantify. This gives a great opportunity for the QA to step out of the comfort zone, and make his/her own definitions. This is where the lines between QA and BA start to blur and the team moves up one gear.
  • Ability to change perspectives – When a product is developed, there are some assumptions made at various level, some are documented while most are not. QA needs to be able to unearth these assumptions, challenge them and derive his/her test cases out of these gray areas. In such cases, a QA might have to think of an end user, or developer, or even a business analyst’s perspective and constantly change gears.
  • Excellent Communication – Co-location does not invalidate the need for effective communication and agile does not invalidate the need for effective documentation. A QA’s documentation becomes extremely important in auditing the software, understanding where the weaker links are and for more effective collaboration. In calls, it is often seen that an effective QA brings up the best in both the other Amigos and promotes valuable debates and discussions.

Quality Assurance – The Benchmark of Good Teams

QA has become the benchmark of not just the Quality Assurance of the product, but also the Quality Assurance of teams. The final product or software is just a consequence of all things done well at a scrum level – be it well-defined and small requirements, technical skills implemented without losing sight of the end goal, and most importantly an effective QA who ties together the whole team irrespective of technical and functional differences.

Choose your QA well, and you choose the team’s destiny. Good luck.

 

 

About the author

Aarti Suresh author

Aarti has about 9 years experience in manual and automation testing. Although her primary work area is automation she also enjoys manual testing from time to time.

Leave a Reply

Your email address will not be published.