views:

324

answers:

9

Looking back at my career and life as a QA engineer, there were plenty of different ways I improved my QA skills and testplans- reading other people's testplans, readings specs, reading books, listening to podcasts, watching screencasts.

My question is: What is the most effective thing you have done that improved your QA skills? What would you recommend to others that want to improve?

I do expect varied answers here and no single "one size fits all" answer - I would like to know what worked for different people.

+3  A: 

I don't believe that technologists should be bifurcated as "developer" and "QA". I think that's nonsense. Developers should be hired to also do QA. Of course they should not be QAing their own code.

They could do development for 3 months and shift to QA for 3 months. It's important to understand both sides of the story. Developers would write much better specifications if they also did QA. They will stop dishing out rubbish. QA on the other hand will be able to debug stuff better coming from a developer experience.

I really hate this QA vs. developer thing that happens pretty much everywhere. The loser is technology.

venksster
http://www.merriam-webster.com/dictionary/bifurcate
venksster
+3  A: 

Learn the difference between crash, freeze, slows down and incorrect results, so that you can always provide that at the start of your reports. :) For how simple it is to note this, it is absolutely amazingly helpful!

Edit: There are many things to being great in QA. This one lets the devs know you have a clue from the very start of reading your submissions. They'll listen to your reports first/higher priority because you'll consistently give them the feeling that they'll get somewhere on it.

280Z28
+2  A: 

Keep a log classified by programming language. History tends to repeat itself and memory is fragile.

Vinko Vrsalovic
+2  A: 

Keep track of the steps needed to reproduce errors. If it can't be reproduced, note it and don't expect a fix.

Take screenshots of any error messages and include them or forward them to the developer.

Try rebooting and see if that fixes it. Have somebody else try to reproduce it before you forward it to the developer.

A good tester is a programmer's best friend.

Beth
A: 

I started to write my bench-testing code into the comments of my release code. I spent many years as a maintenance programmer and troubleshooter, and I learned to despise many programing habits of my peers. However, every now and then one of them would actually write bench-tests into the comments: those guys were gold as far as I was concened.

RBarryYoung
A: 

Developing using TDD has helped my QA skills if only because now I'm starting with tests and working backwards rather than trying to scramble at the last moment to stick in the tests.

For others, my main suggestion would be to do some self-analysis and then see what one thinks is that next big thing to add to their development arsenal,e.g. is it learning how QA fits into new software development methodologies, is it seeing what QA is currently done where you are, what tools you have to assist with QA. It may be some trial and error to find what is that thing that takes one to the next level, but it can be so worth it or at least to me it is.

JB King
+3  A: 

One attribute of every good QA that I've worked with is that they are an expert on the domain subject matter, the business requirements and the needs of the end users.

If you're just testing to a spec document, or worse, only checking that the software does what the developer told you it should do, then you're missing a big chance to improve the whole project.

TickleMeElmo
+1  A: 

Be able to 'empty your mind' and mimic a new user, where anything is possible and probable. Can be difficult to do when in a professional role and familiar with the product.

Seba Illingworth
A: 

Hey. If by QA you mean all aspects of application testing, not just unit testing, than learning to write bugs reports is one of the most important things to improve. Always. Therefore for me it would be writing, writing, writing... and analyzing other people reports.

yoosiba