Here they are - a collection of quite a number (250+) of the many online articles on Java, Software engineering (architecture, the development process), XML etc. that I've read over the last years - probably going back to 2001. I've included a URL and a personal score (on a scale of 1 to 5 with 5 being awesome).
I hope you'll find this useful - some of these articles took quite a bit of digging to find but were well worth the effort.
http://spreadsheets.google.com/pub?key=prCSPRhj1PCGuYZvjEITgXw&output=html
Please feel free to shoot any comments, edits, suggested additions (or deletions?). Because the underlying spreadsheet is on Google Docs (love it!) it will get updated on a semi-regular basis as the reading list continues to expand.
8/6/07
4 reasons it sucks to be in QA
Well that's my take on it folks - of all the roles in the Software Development Life Cycle probably QA has it worst. Managers, Architects, Developers, Business analysts - no-one takes as much BS or has such a thankless role as the valiant folks in your average QA team.
Now I hope most of you reading this will disagree but I'm betting there's a lot of nodding heads out there (probably mostly from folks in QA).
What are the main reasons for this you say? There are four as I see it:
1) Respect
QA tends not to get respect from people in other roles - but most especially and most oddly the least respect (most disrespect) comes from software developers. Personally I find this strange that developers have such disrespect (sometimes even open and outright disdain) for those tasked with ensuring the quality of the product being delivered.
I think a lot of developer frustration comes from the questions and problems that arise out of the QA team/group. Yes, often QA folks don't understand the ins and outs of an application. If that's because someone in QA doesn't want to learn then that's a worthwhile beef but more often than not the QA team are STARVING for information.
Often they're brought in at the last minute, given a vague, incomplete and out-of-date spec and told "Hey go test this!". Yes the developers had the same spec and were told "Hey go code this!" but they're finished building out the app so they've (hopefully) fleshed it all out at least in their heads and in the software they've built.
Developers deride the QA role - "What do those guys know? They're just testers!".
That's just the wrong attitude. These guys and gals are the ones who, at the least are helping to make the product (not code folks - product!) better, and at best saving your ass from being fired for shoddy work. You and they are on the same team though you may not realize it. Try to remember that.
Another reason that I feel developers beat on QA is that the developers get beat on themselves (think Dilbert) and like some bullied kids they look to take it out on the only one's they can - someone weaker - not managers, not architects, not the business analysts, not other developers - who's left? QA!
I've seen it many-a-day - the self-righteous attitude developers take in correcting QA or better yet informing them that their "bug" won't be fixed because it "works as designed" or they spent 5 seconds trying to reproduce the bug and could not.
I'm not saying "works as designed" or "unable to reproduce" are a bad reason to kill a bug - just the attitude that goes with it. Call the tester - explain why it works that way - should the docs be updated to make that clear? Possibly! If you can't reproduce a bug maybe there's some context or other missing information - maybe it's particular to the tester's environment. Just blowing things like that off might make a developer feel good but it diminishes the overall product and the team too. Take the time to do it right - a phone-call or walk-by will take 5 minutes at most.
2) Responsibility vs. Power
The QA team have a very important responsibility - they are the gatekeepers of product quality. At least in theory anyway! Also quality is a hard thing to identify or quantify. Is it the overall user experience, the number of bugs, the number of critical bugs, how do you define "critical"? Just too many subjective things. Oh and usually they're understaffed and/or under-tooled.
However for all this responsibility they have the least power. In the hierarchy of management structures QA comes pretty much last.
Everyone else thinks they can do the QA job - how hard can it be? But the reality is very few people can do QA right. And especially not developers! We are our own worst enemies in this case - we use the application like we coded it not like it was meant to be used.
3) Last to be hired and First to be fired
In the boom and bust cycle of software QA folks seem to be the last to be hired - usually towards the end of the boom when all your new customers start to complain about the bugs from all the newbies you hired at the start of the boom. But then when the bust inevitably comes QA folks are first on the chopping block followed by middle managers. No wonder there aren't many experienced QA folks about - again it's a widespread lack of understanding of the importance of QA and testing in the software process.
4) Paradox of excellence
The "Paradox of excellence" is something we're all familiar with but may not know it. Since the art of software (it ain't engineering or science yet) is not well understood, few outside of software can understand how hard it is to do software "right" - with few bugs. It takes a long time. Therefore when software is done right people don't perceive the absence of bugs - they just see that the process seemed to take forever to complete.
Basically the "paradox of excellence" states that you don't get credit for problems that never happened. Typically in the normal software shop when bugs happen and they are fixed fast by developers the developer gets kudos. Who gets kudos for the lack of bugs in a release? No-one.
So if QA does their job right - no-one notices. The same is true for developers to an extent but they can usually redeem themselves if and when bugs do show up. QA have no such opportunity - if they *do* spot issues they becomes "spoilers" for the party giving the bad news no-one wants to hear.
With those four issues facing you as a person in QA - lack of respect, little power, no praise, fear of being laid off, how much motivation would you have every day?
In my opinion a rock solid QA person is one of the most critical roles on a project. In fact in my experience the best QA people know the application better than the developers, the managers, the analysts and even the users. They know the ins and outs - breadth and depth and know where most of the bugs pop-up! I wish most developers were so aware.
Solutions?
How do we resolve this problem for folks in QA? There are two steps - the first easy and the second not so much:
1) Co-locate QA and Developers
Have developers and QA sit side-by-side and work together closely throughout the entirety of the software lifecycle. Make them truly part of the team! Have lunch together!
Physical separation of QA from the dev team is a bad idea. Having separate reporting structures for Dev and QA might be good since having same reporting structure creates a little "conflict of interest" - management understandably want good news, QA are rarely bearers of good news - but it's news that needs to be heard!
2) Developers and management need to snap out of it!
Frankly this treatment of folks in QA is one of those little "secrets" in software that we should be ashamed of if we consider ourselves to be "professionals" in the true sense of the word.
Developers and management need to respect the critical role of QA, the complexity of their job and most of all to drop by their cubes and say thank you for all their hard work they do without much praise - day-in, day-out. Your product is better for it, the industry is better for it (and could do with much more of it) and thus the rest of us managers, architects and developers are better for it.
Now I hope most of you reading this will disagree but I'm betting there's a lot of nodding heads out there (probably mostly from folks in QA).
What are the main reasons for this you say? There are four as I see it:
1) Respect
QA tends not to get respect from people in other roles - but most especially and most oddly the least respect (most disrespect) comes from software developers. Personally I find this strange that developers have such disrespect (sometimes even open and outright disdain) for those tasked with ensuring the quality of the product being delivered.
I think a lot of developer frustration comes from the questions and problems that arise out of the QA team/group. Yes, often QA folks don't understand the ins and outs of an application. If that's because someone in QA doesn't want to learn then that's a worthwhile beef but more often than not the QA team are STARVING for information.
Often they're brought in at the last minute, given a vague, incomplete and out-of-date spec and told "Hey go test this!". Yes the developers had the same spec and were told "Hey go code this!" but they're finished building out the app so they've (hopefully) fleshed it all out at least in their heads and in the software they've built.
Developers deride the QA role - "What do those guys know? They're just testers!".
That's just the wrong attitude. These guys and gals are the ones who, at the least are helping to make the product (not code folks - product!) better, and at best saving your ass from being fired for shoddy work. You and they are on the same team though you may not realize it. Try to remember that.
Another reason that I feel developers beat on QA is that the developers get beat on themselves (think Dilbert) and like some bullied kids they look to take it out on the only one's they can - someone weaker - not managers, not architects, not the business analysts, not other developers - who's left? QA!
I've seen it many-a-day - the self-righteous attitude developers take in correcting QA or better yet informing them that their "bug" won't be fixed because it "works as designed" or they spent 5 seconds trying to reproduce the bug and could not.
I'm not saying "works as designed" or "unable to reproduce" are a bad reason to kill a bug - just the attitude that goes with it. Call the tester - explain why it works that way - should the docs be updated to make that clear? Possibly! If you can't reproduce a bug maybe there's some context or other missing information - maybe it's particular to the tester's environment. Just blowing things like that off might make a developer feel good but it diminishes the overall product and the team too. Take the time to do it right - a phone-call or walk-by will take 5 minutes at most.
2) Responsibility vs. Power
The QA team have a very important responsibility - they are the gatekeepers of product quality. At least in theory anyway! Also quality is a hard thing to identify or quantify. Is it the overall user experience, the number of bugs, the number of critical bugs, how do you define "critical"? Just too many subjective things. Oh and usually they're understaffed and/or under-tooled.
However for all this responsibility they have the least power. In the hierarchy of management structures QA comes pretty much last.
Everyone else thinks they can do the QA job - how hard can it be? But the reality is very few people can do QA right. And especially not developers! We are our own worst enemies in this case - we use the application like we coded it not like it was meant to be used.
3) Last to be hired and First to be fired
In the boom and bust cycle of software QA folks seem to be the last to be hired - usually towards the end of the boom when all your new customers start to complain about the bugs from all the newbies you hired at the start of the boom. But then when the bust inevitably comes QA folks are first on the chopping block followed by middle managers. No wonder there aren't many experienced QA folks about - again it's a widespread lack of understanding of the importance of QA and testing in the software process.
4) Paradox of excellence
The "Paradox of excellence" is something we're all familiar with but may not know it. Since the art of software (it ain't engineering or science yet) is not well understood, few outside of software can understand how hard it is to do software "right" - with few bugs. It takes a long time. Therefore when software is done right people don't perceive the absence of bugs - they just see that the process seemed to take forever to complete.
Basically the "paradox of excellence" states that you don't get credit for problems that never happened. Typically in the normal software shop when bugs happen and they are fixed fast by developers the developer gets kudos. Who gets kudos for the lack of bugs in a release? No-one.
So if QA does their job right - no-one notices. The same is true for developers to an extent but they can usually redeem themselves if and when bugs do show up. QA have no such opportunity - if they *do* spot issues they becomes "spoilers" for the party giving the bad news no-one wants to hear.
With those four issues facing you as a person in QA - lack of respect, little power, no praise, fear of being laid off, how much motivation would you have every day?
In my opinion a rock solid QA person is one of the most critical roles on a project. In fact in my experience the best QA people know the application better than the developers, the managers, the analysts and even the users. They know the ins and outs - breadth and depth and know where most of the bugs pop-up! I wish most developers were so aware.
Solutions?
How do we resolve this problem for folks in QA? There are two steps - the first easy and the second not so much:
1) Co-locate QA and Developers
Have developers and QA sit side-by-side and work together closely throughout the entirety of the software lifecycle. Make them truly part of the team! Have lunch together!
Physical separation of QA from the dev team is a bad idea. Having separate reporting structures for Dev and QA might be good since having same reporting structure creates a little "conflict of interest" - management understandably want good news, QA are rarely bearers of good news - but it's news that needs to be heard!
2) Developers and management need to snap out of it!
Frankly this treatment of folks in QA is one of those little "secrets" in software that we should be ashamed of if we consider ourselves to be "professionals" in the true sense of the word.
Developers and management need to respect the critical role of QA, the complexity of their job and most of all to drop by their cubes and say thank you for all their hard work they do without much praise - day-in, day-out. Your product is better for it, the industry is better for it (and could do with much more of it) and thus the rest of us managers, architects and developers are better for it.
Subscribe to:
Posts (Atom)