In the last blog, we made the case that everyone on the agile team owns quality and provided some ideas on how team dynamics can help build quality into the product. In today’s post, we will discuss some additional ideas on how your software QA teams can work together and ensure quality is on the forefront of everyone’s mind when building a product.
As we noted in our previous post, waterfall tended to equate testing and quality, which can lead to all kinds of bad habits – the main one being that testing (defect detection) should be the primary means of developing quality products. In agile, more emphasis must be placed on quality assurance (defect prevention) since there is limited time to execute tests. Basically, issues should be identified before they can even make their way into the actual code.
A cool by-product of the pairing is an increase in trust and understanding between two groups that traditionally may have had a tenser relationship.
To build quality anywhere and everywhere, professionalism needs to be nurtured within the team. Professionalism is exemplified through both mindset and actions. For example, the team needs to be doing the right things, not just doing things right. We need to be thinking strategically rather than tactically. Going through the motion of design inspections, requirements discussion when we don’t truly understand the acceptance criteria is an example of doing things right.
Building what the customer wants in a way that is functional, is doing the right things. Both are important, but building an errorless product that nobody wants will cause major problems in the viability of our business. As such, teams need to really understand from their POs what the vision of the product is, how that vision aligns with the needs and desires of the customers, and how they can best meet those needs. Professionalism is more than just being really good at something – its about asking the right questions and working together to get the best answers possible.
We can also grow our team’s level of professionalism by moving from I-shaped to T- shaped team members. I-shaped people only do what they are good at. For example, if I am a java developer, I only do java coding. T-shaped people have a core area of expertise but have a willingness and ability to do tasks outside of that area of expertise. So sometimes a developer will need to help with testing or a tester may need to help with documentation, or all the team members need to come together to finalize the training materials. Teams need more T-shaped people. I-shaped people lead to silos, which is what we want to move away from.
Finally, to be a good team member means that we focus as much on how we work together with our teammates as on our core areas of expertise. Each person on the team has his or her strength, but each of us has to expand our capabilities beyond our strengths. Working together as a team, relying on the skills each of us brings to the collective table can inject quality and value into the products that we deliver.
Up next:
Learn more about our software test management workshop to ensure quality in your testing processes.