We’ve worked hard to integrate our Quality Assurance analysts with our development teams, but getting a testing framework off the ground can be difficult for many teams. If you’re a designer or developer who is new to testing in an agile environment, here are the most important ways you can help your team.
You Don’t Have to be QA to Test
This is a big one: you need to forget the notion that only a QA person can test work. This is a backwards and an anti-teamwork way of thinking. Yes, QA is the primary responsibility of the QA team member, but it is a team responsibility to get it all done. In Agile, if one team member falls behind, the entire team falls behind.
For instance, a developer with some downtime can easily grab a story and start testing it. And to answer your question: yes, a developer can – and should – send it fully through the queue to “Done” status.
Seem like madness? It’s actually quite sensible. When a developer sets something ready for QA, they are declaring their confidence that what he or she has made is ready to go live. To properly QA a story, you simply are there to say that you agree or disagree. In a true agile environment it is expected that to an extent you may be able to help with another team members role even if it is outside of your job description.
It is time to forget about labels and keep doing what it takes to help the team.
Here’s a not-so-secret secret: the better you communicate with your team, the smoother your team will operate, especially when it comes to ensuring quality. This doesn’t just mean that you need to have good verbal and written skills, but you need to be there in the trenches with your team assigning the amount of effort for the work and making sure that there is accountability for missed deadlines.
Never be afraid to ask “Why?”
If you are supposed to receive a story to test and the developer misses a deadline, don’t be afraid to ask them why it is late. This lets you know what to expect when you get the story and could possibly help identify roadblocks you could assist with to help them. Also be prepared if you assign effort to a story and say it will take you one day and it takes two days. The developer should also ask you the same question.
It is key to let go of QA as a siloed department and embrace it as an integral part of the team. A QA person – whether they’re dedicated QA or a team member with QA skills – needs to have the same responsibilities as anyone else on the team.
Just like you wouldn’t change a tire with a ham sandwich, you shouldn’t test without the proper tools or environment. Here are a few of my favorites.
- Telerik Test Studio
- XSS Me (FireFox Plugin)
- SQL Inject Me (FireFox Plugin)
- Ghost Lab
Watch Out for These
Many developers make the mistake of pigeonholing QA into simply checking for functionality and design breaks, but you need to keep the full site experience in mind.
- Target demographic
- User load (How many will be on the site at any given time)
- User Experience (UX)
- Supported Browsers
- Supported Devices
No matter how good a site looks or functions, it’s still a failure if a consumer can’t use it. The same goes if the site cannot handle the amount of traffic visiting it and goes down.
Let It Go
In a nutshell, you must first let go of labels, silos and a waterfall mentality before you can fully integrate QA into your agile team. Don’t be afraid to step out of your comfort zone and take charge to ensure what you release is the best it can be.
What the public sees creates the image of your company. Don’t you want that image to be a good one?
Image credit: Per Erik Strandberg