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.

Recommendation of test engineering books

I've read a few books about testing software and how to introduce testing techniques into a working software environment. Ofcourse it always sounds nice in theory, but how do you developers test in realworld projects?
What kind of techniques do you use? And are there some test engineering books you would recomment others?

Greetings, Dave.
Just Dave
Thursday, February 24, 2005
Do you mean unit or functional testing?
Thursday, February 24, 2005
Has some material aimed at beginners. Has some sample forms to jump start your thinking.
Thursday, February 24, 2005
A list of software testing books can be found here

' '

I have changed sides and I am now busy creating bugs rather than testing for them so I hesitate to recommend any. I found the best advice when attending a Specialist Interest Group in Software Testing meeting and talking to people working in the front line. The people there seemed quite happy to share their experience in the coffee breaks.

This sounds trite but I think the first step is to make sure the developers accept there is a problem and create their code accordingly. I still hate it when someone finds a bug in my code, but I am no longer in denial and have learnt not to take it personally. To see the testers as there to help improve the software not lay the blame on your doorstep. It can be a big step for a fragile ego to take.

 Back in the early 90s when I was involved in a QA programme we did not find a single programmer in the company who had received any formal training in software testing. Has this changed? I would hope so but I have not asked the question recently.
Friday, February 25, 2005
It will probably make things clear to let you know why I asked my question.
I would like to introduce good testing practice into a working environment. Today there are no structural testing practices, just some manual tests procedures which will be no suprise lack any control of being done.
My first structural test procedure will be to introduce unit testing. I understand the unit testing concept, and  it works.
The next step is to introduce a complete test plan through out the whole design-implement-acceptance-use trajectory.
Here I would like to know what kind of methodology and techniques real life developers use.
I read some articles and books on this subject, and as I stated in my first post, it all sounds nice. But does it hold in the real world? Some tend to be very formal (checklists, some people to check the checklists), and seems to me to introduce alot of overhead. And I question the completeness of such checklists. But maybe I'm wrong.

I looked at the amazon url Peter gave, but it seems that the reviewers are very negative about this book. One reviewer said that the book assumes to be used in a very mature environment. Unfortunatly mine isn't mature.
Peter, maybe your would explain your book recommendation?

I agree with Royboy that talking about testing and exchange experiences is a good way to gain real world test experience, but I hoped that there was good an article or a book on the subject.

Greetngs Dave.
Just Dave
Friday, February 25, 2005
I have two pretty decent testing books.

Testing Computer Software, 2nd Edition by Kaner is the better of the two.

Bankstrong Send private email
Friday, February 25, 2005
I met Cem Kaner (author of the book above) in Portland at a presentation he gave.

I asked him if anyone had tried putting a bunch of high school students in a room to TRY to break a program. He just gave me a dirty look :-)

I, and an engineer I used to work with, had an uncanny ability to break software. In fact, this other engineer crashed the company's whole main frame.  We just tended to say "well, it SAYS it will copy a directory, so I tried to copy a 20 GB directory. Hmmm.. wonder why it crashed".
Mr. Analogy {ISV owner} Send private email
Friday, February 25, 2005
trying to get a testing program going in an organization that doesn't support it can be rather difficult. Instead, why not try something a little bit different: (1) Track EVERY bug that you have. And also, track the amount of time spent on bugs. (2) Determine what parts of the system are being used the most. This can be accomplished by surveying your customers.

With this data, you can then build a case for better testing.

In the meantime, try promoting Unit testing and tools like JUNIT/NUNIT.
Patrick Send private email
Friday, February 25, 2005
There's been a growing software testing movement for more agile methods, focused on testing and not on checklists and doc writing - google for "Exploratory Testing".

Book: "Lessons Learned in Software Testing"

James Bach's site:

My experience is that the 0th and 1st steps of improving testing processes are to:
- get automated nightly builds and installs going
- get automated nightly tests going (starting with unit tests, adding other regression tests).

Everything else (automated and manual functional, system, configuration, environment, load, etc. testing) is a lot easier to get going, maintain, and grow if those are in place. 

Its usually pretty easy to get developer and manager support for nightly builds and testing. Throw in a web site that everyone can look at easily each morning,

Managers will want metrics.  One easy one, besides defect metrics, is to add code coverage numbers based on unit testing.  Try something that integrates easily with unit tests, like Emma,, with Java and Ant. 

The IEEE 829 spec is a widely used software testing specifications if you're going to go the checklist/lots of documentation route.
los Send private email
Saturday, February 26, 2005

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

Other recent topics Other recent topics
Powered by FogBugz