The Design of Software (CLOSED)

A public forum for discussing the design of software, from the user interface to the code architecture. Now closed.

The "Design of Software" discussion group has been merged with the main Joel on Software discussion group.

The archives will remain online indefinitely.

QA Resources

Does anyone know of any good resources to point a full-time tester too that would help to improve/expand their skills?

I am leading a development team working on interfaces between various products. The interfaces themselves are not traditional “applications” where you click one button and get one result. I have been able to incorporate some good test-driven-development practices to improve my unit testing. But unfortunately, I don’t have any good guidance for a full-time QA person on how to validate the correctness/performance/etc. of these programs.

Unfortunately, Joel himself seems to only dedicate a few articles to this subject (I only found 5 blog entries on JoelOnSoftware by searching for “tester”). If anybody has any good suggestions I would appreciate it.

And, Joel, if you’re reading this, I would really like to see some real-world examples from Fog Creek of your use of QA people in the development of your numerous applications.
Justin Barker Send private email
Thursday, September 14, 2006
 
 
James Bach's blog (http://www.satisfice.com/blog/) is devoted to testing and has a link to cem kaner's blog as well.
expr
Thursday, September 14, 2006
 
 
I don't know of any resources.

To be fair, I don't think there is any one size fits all solution. The only thing that I believe all QA testers have in common is the documentation side, not the actual testing side.

"...any good guidance for a full-time QA person on how to validate the correctness/performance/etc. of these programs."

Well, you really have three options.

1) The testing programs are programs too. They can be tested and validated by the same methods. Admittingly, there comes a point where you'll either have to read the source code, or trust the assumptions.

2) Each version that you test should have a paper trail such that you can easily see what the intended differences between each version of the software. Ideally, you should be able to start with the first version and go forward (or the last and go backwards) and see how the software is developed as well as why those decisions were made. If a particular decision didn't make sense or a feature took much longer to implement than planned, then you can look more closely at that part of the code.

3) You can rely upon a "subject matter expert" to confirm that the actual output is indeed correct.

The common theme in all three cases is that you NEED good documentation about what was planned, what was put in, what was removed, and why. Unit tests and a good paper trail will catch the vast majority of problems, excluding useability issues.

For useability issues, there's really not much you can do except click the buttons and do "hallway testing", that is, do other people click the same buttons?
TheDavid
Thursday, September 14, 2006
 
 
Thank you for your comments! Both are very helpful. I especially appreciate the link to James Bach’s blog. I can’t stress enough how important being plugged-into a thoughtful, professional online blog/community is for modern “knowledge workers.” These communities are vibrant, mentally-stimulating, and also just fun and this is exactly what I was hoping to suggest to my QA-professional colleague.

Also, please feel to provide more suggestions. This is really good stuff.
Justin Barker Send private email
Thursday, September 14, 2006
 
 
Former COBOL Programmer
Friday, September 15, 2006
 
 

This topic is archived. No further replies will be accepted.

Other recent topics Other recent topics
 
Powered by FogBugz