Unit Testing, Agile Development, Leadership & .NET - By Roy Osherove
It's hard to find people to build a serious QA team with.
The ones that can do it well often want to be in Engineering.
The ones that want to be in QA often can't do it well.
Funny about this article. I just finished my first independent test contract (I have 4.5 years of professional experience at Intel and other places before that). The guy I did it for is a private developer who has never had a tester and only used me for the project to see what it would benefit him for a change. After setting up a Flyspray bug tracking server and finding about 30 bugs in 8 hours, plus numerous suggestions, he not only now believes in having a tester but he's already asked me to help with another client's project at a minimum of 5 times the hours he booked me for the current one. It's nice to be wanted.
As to the whole issue about anonymous testers, that's why I have a resume and references, to show credibility. Also, I think any 'skilled' or 'experienced' tester has, or should have, the ability to NOT need much hand holding in order to understand a new product depending on the level of complexity. Oh, and another thing, I think a lot of devs would generally benefit just from having a tester (anonymous or not) evaluate their product on the basis of the 'user experience'. Useful information is often gotten that way. The tester does not have to be 'the ultimate tester' to do this.
I think the bigger issues an anonymous tester would end up getting dinged for is not being a good communicator. I know many technical guys who can't describe an issue to save their life. Several guys I've worked with in the past (working qa engineers) also have this problem and don't understand that communication is a big part of the job.
Boy, that was longer than I intended.
Merry Christmas all!!
I could not agree with more with the commentary on uTest.
Software QA is serious business and it appears that uTest looks is aimed at software vendors not willing to invest in creating a quality product. The use case seems to be the following:
a) Think of a product
b) Write some code
c) Hope it will work — oops! it does not
d) Get it QA-ed (uTest, tryBeta!)
e) Fix or patch bugs that get discovered — ones that don’t lie along to bite the customers later
I think this is not the way Software QA and Software Engineering ought to be.
For a serious QA team — please visit http://www.atishae.net/. We will help you deliver a better product, faster!
Will it destroy your Q&A?
Maybe, maybe not.
There is no harm in trying something new.
It could be better for some things and worse for others.
That's the beauty of evidence based management.... why not try everything and compare the outcomes?