About a year after I started at Intridea I went to a QA conference in Las Vegas. Up to that point I had only really done QA in an agile web development environment, and I remember being absolutely floored when I took a mental survey of the people I had been attending talks with and realized the following: 1) Most of them were involved in only one project at their jobs; 2) Most of them had entire MONTHS for testing between new releases and deploys; and 3) Many of them either hated or feared the developers of the software they were testing. I was taken aback! “SAYWHAAAA?” I uttered dramatically.
If the thought of “agile development” incites images of developer-ninjas leaping through the office in stretchy black attire, and squashing codebugs with their killer ninja stars, you’re wrong. Well, 1/2 wrong. Really, it just means you work on a much faster paced development cycle, which requires ninja-like devs!
Instead of having 3 months between deploys, you might have one week or even just three days; and working for a web development team means you’re working with 5+ projects at a time on that super schedule instead of just one. It can get pretty hectic and overwhelming, and you never run out of things that need to be done. You need to be in tune with your inner ninja. Here are a few tips for ensuring quality in an Agile environment (and coming out with your psyche intact):
Create a Wiki or Knowledgebase
When you’re working on 5 projects, and each project has a staging server, a dev server, and a production server in addition to multiple logins for each server, you’re going to have a lot of credentials to remember. Add to that each nuance of procedure for each project and even if you can commit that many usernames, passwords and procedures to memory, odds are, someone on the team will forget.
One day I realized that I was spending quite a bit of my day going into my notepad, and copying over some URL or login or procedure detail that someone on the team had questions about. I’d say I spend 50% less of my day answering those questions now that we have a wiki with info on every project we work on! When someone asks a question that’s covered in the project’s wiki I refer them to the URL that won’t just give them the answer to that question, it’ll tell them everything they need to know for the project! When there’s a change I update the wiki instead of emailing the changes to everyone. Every time I have new info, they have new info.
This level of transparency ensures that people can easily reference information, and everyone is working from the same set of facts and assumptions.
Relax!! No one is out to get you.
I think that as a group, QA engineers are cynical and suspicious by nature. Unfortunately, I’ve seen that cynicism cross over into paranoia that a particular developer has it in for you. They’re OBVIOUSLY bouncing this ticket back and forth with you because they enjoy wasting your time and watching you squirm, AND they block you with 500 errors while you test. Sneaky sneaky developers. If you sometimes find yourself thinking along the same lines, just remember: they’re thinking the same thing. Odds are they’re also really frustrated about a bug that they think they’re solving and you think they aren’t.
I think it’s important to keep in mind that at the end of the day you’re both trying to do the same thing: deliver a quality product to the client. When you’re elbow deep in ticketing and regression testing it’s hard to keep perspective, but the developers want to deliver a product they’re proud of just as much as you do. You’re on the same team, and you should make an effort to keep that in mind.
Take time to organize
Sometimes the best thing you can do for the QA project is “go dark” and turn your computer off for a few. When I need a plan of action I like to get out a pad of paper and pen (or colorful markers) and make lists. Sure you can make lists with your computer ON, but it’s important to eliminate distractions and really focus on what needs to get done. Email, Present.ly, IM, and Campfire notices create a huge distraction for me, and I’ll find myself looking down at my list saying “now where was I?” four or five times before I’m done. When you have lots of projects that all need QA hours, taking 20 minutes to focus only on scheduling will ensure you don’t forget anything; more importantly, it’ll ensure that you have a realistic idea of what kind of hours you have over the next few days which helps to eliminate accidental over-scheduling (A QA Manager’s nemesis).
Take a break when necessary
Zombies are no good at QA and are usually being used for some evil purpose! (the dictionary said so.) Avoid zombiedom by taking breaks. If you feel your eyes start to cross, or your blood pressure start to change drastically, or if that odd tick in your eye-cheek area comes back, TAKE A BREAK!
Take 5 minutes to look out the window (the other glowing square in your room), or take 10 to walk around the building (hire a dog to chase you if you lack motivation), or get a snack and a drink (screw carrots we’re talking chocolate), but whatever you do, don’t work as a zombie. You’re not doing anyone any favors, and your refreshed mind will get more work done in 45 minutes than your zombie mind would have done in 2 hours.
Be nice!
We’ll still have our moments, and as much as we try to stay zen and draw patterns of peace in the sand, you’re probably going to reach a point that you’d rather be strangling someone than pretty much anything else. Instead of using your caps lock for evil and commenting “STILL NOT FIXED TOM. please reassign to me when it’s FIXED AND READY FOR VERIFICATION. (read: do your job)” why not be nice? Why not say “Hmm…This seems to be a tricky one. I did a cache clear, reboot, and tried on 3 different computers, but I get the same error every time. These are the steps I take:” and then re-list each step you take, re-word what you did before, but add any details you think might be helpful. Sometimes I offer to schedule a time to re-create the error at a time that the dev can watch the logs as it happens, because in the end we all want the same thing (remember: THEY’RE ON YOUR TEAM!).
The agile environment demands a lot from developers and the QA team. It requires that you come into the process with a clear and focused mind, ready for organized and productive pandemonium. Luckily, I’ve been able to identify some ways to target and enhance my inner ninja, and hopefully these tips can help you in your own agile processes!
