Archive for March, 2010

Finding worth in the bad days

There are days we all like to talk about. You walk in and you feel great. Bug are easy to find, easy to fix and easy to approve. The documents are where we expect to find them and they are in good shape. Our questions get answered, our deadlines get met and we feel … admit it… a little like superstars.

But no job can be like that every day…

Some days you show up late to a morning meeting, you don’t even know what questions to ask not to mention where to find the answers and you can’t seem to wrap your brain around a certain test case that needs debugging. If you work in QA long enough, eventually there are going to be test escapes, and they are going to be your fault. Test escapes are one of the worst feelings I know. So how do you muster up the energy to get through those days?

Of course- you get through it because this is your job and you want to do well/get paid/not get fired. But that can’t be the only motivator.

In college, I was a history major. I spent long hours behind piles of old books and magazines combing through dates and details looking for the information I needed. I didn’t always want to be there- but what I realized was that there was a lot of value in working when its hard to stay motivated. How is that possible? When I wanted to be there, I was fueled by adrenaline and general good-moodness. It helped me to be creative, optimistic and to be full of ideas and connections. But the days I didnt want to be there, I had to push myself through with sheer will. Creativeness gave way to careful game plans and determination. If I read closer or looked deeper, it was because I was afraid that if I slacked off, I’d have to do work over. I learned to harness those bad days and make them useful. As with so many things about my major, I have since discovered, that skill is useful in my life as a QA.

No one would want to deal with it all the time, but the occasional bad day can really do amazing things for productivity. If your creativity is lagging, you have to be more thorough in your test writing process to cover all your bases. If you feel miserable because you missed a bug- use it to rewrite a test case and cover that scenario in the future. If you don’t know what questions to ask, maybe a reread of the documents or a conversation with the developers is in order. If nothing else, the determination to move through your task list and cross things off will help you clear out a lot of work, and helps to put you in a great place for those good days.


Write bugs that get fixed

It seems simple enough- find an issue, file a bug, wait for it to be fixed. The tough part should be finding the bug in the first place, but sometimes it isn’t.

1- Time constraints. When deadlines loom, the team may be anxious to get the project out the door and ignore “minor” issues that can be fixed post launch.

2-Complexity. Even simple sounding bugs have have complex integration with other functionality or require a lot of rework – and no one likes rework.

3- Dismissal. No one likes to hear this one, but it happens. Sometimes bugs get dismissed because a) the developer doesn’t trust the QA or hasn’t seen the issue b) it feels like a rare corner case c) it is hard to reproduce d) there are a lot of other demands on the team at the time and your bug simply falls off the radar.

How can we avoid these issues?

We can write clear bugs. Reproduction steps are one of the strongest tools we have. One of my favorite QA interview questions involves getting candidates to write reproduction steps for an unexpected action. It is a really important skill for QAs. Project managers and engineers need to really understand how we got to the issue we did and be able to see it themselves- not to mention how much it helps us if we have to explain our bugs to someone.

We can follow up on issues. How many times have you written a bug just to let it slip by unnoticed while you found more issues? Checking on the status of issues isn’t as exciting as finding new ones, but it is important if you are trying to get something fixed. If a bug gets put in deferred, make sure you know why. If it is fixed- does the fix match the documents?

We can be knowledgeable. Sure, we aren’t developers- but it helps if we know about about the software they are writing. If there are lots of false alarm bugs or low priority issues labeled as high priority, the team will start to trust us a little less. Knowing about the documents, the software and the issue make you a much more creditable source and seems to help your bugs get fixed.

We can “file” some bugs off the record. I’m not really promoting this- especially if your company is big on formal policies. But, if it makes sense for your team, letting developers know about smaller issues first, offline, not only gives them a head start, it puts us all on the same team. We aren’t filing bugs against developers, we are working with them to make sure everything runs right.

Does anyone else have tips for making sure bugs get addressed?

Article in TEST!

I have an article in this month’s TEST magazine called: Keep the User in Mind. You can find it on their website here, but I will paste the text below, also. Also in the March issue, they are running the completed “High Tech in High Heels” series from this blog, so keep an eye out! I am very excited to contribute to this awesome magazine.

Keep the user in mind

Devon Smith* QA Lead at Agora Games LLC in New York says you need to keep the user in mind, especially as you approach release time.

It’s late on the last day of testing and your eyes are a little blurry from some last minute verifications. Your bug list is longer than you expected, and the coffee in the break room is long since burnt. Everyone is ready for you to sign off and you can hardly remember why that final test really matters. After the meetings have been held, requirements agreed upon, and countless lines of code written and implemented, QA testing can seem like a roadblock to the exciting part – the great release. But it is exactly in that moment, with a stale cup of coffee in your hand and one last run through to do on the software, that you most need to remember who you answer to: the user.

Each team has different priorities in a release, and sometimes, that leaves Quality Assurance pulled in a lot of different directions. On one side there are the project manager’s deadlines, on another are ambiguities in the requirements document, and on still another is the cool new engineering solution the developers are trying out. Working between the different departments is part of what makes QA challenging and interesting. Understanding and balancing the motivations and needs of each team helps us to do a better job, but the people we really need to understand are the users. We need to understand them to recognize the limitations of the software, to know how business goals will be met, and to appreciate how real people will use the fancy designs and complex solutions. That is our angle. Our goal is to focus on the user. Keeping the user in mind while we test helps keep us rooted in the real world, helps us to stay focused, and helps us deliver that quality release.

We may verify everyone elses’ work, but the users verify ours. They keep us accountable. Often, we are encouraged to test in a hurry, keep our bug counts high, and track the severity of our defects. Those are just outward measures of what is really important. On that last night of testing, when debugging and manual tests seem endless, remember that you are the last stop between the software and the user. It is not about the bug counts, or documents or deadlines – it is about watching out for the users, who truly are the final sign off on quality.

*Devon Smith is the QA Lead at Agora Games LLC in New York. She has been working in software testing for three years, has a bachelors degree from the University of Washington in Seattle and worked at Sun Microsystems before coming to Agora. Her feature, High tech in high heels appears in the March issue of T.E.S.T magazine.

DiffMerge for Text Update Testing

I just started using a Diffmerge for testing text updates to websites. It allows a graphical comparison of two text files and it highlights the differences between them. This is proving incredibly useful for big text updates to the websites I test. All you do is save a copy of the specification document with the new wording and then save a notepad of the text that appears on the site in staging. It will do the careful checking for you and clue you in to any inconsistencies.

If you have a lot of text updates, especially if they are legal notes or terms of service, it can be hard to catch every little error no matter how careful you are. This tool is easy and helpful and it gets you back to the functionality areas of testing quickly.