This review actually covers the 1st edition, and not the current 2nd edition.
I read this a long time ago - made my notes and have subsequently lost them. So I start again.
My basic memory from the last time I read it recalled as: “a good book for beginners”. So I’ll see what a second reading does for me.
The first section of the book gives a basic introduction to software testing based on pragmatism.
While part 1 does have a section on the “Realities of Software Testing”, the section “What exactly does a software tester do?” gives out what I consider unwise advice in form of:
“The goal of a software tester is to find bugs, find them as early as possible, and make sure they get fixed.”
I would not state a definition like this to beginner testers as I know from experience what kind of behaviours this will drive into overly zealous young testers. Certainly our goals include the finding of bugs, yes preferably as early as possible, but “making sure they get fixed”?. When a junior tester takes ‘making sure they get fixed’ rather than a bug advocacy or ‘information providing’ role, they end up acting as ‘gatekeepers of quality’.
So I hope the beginner tester will not take this definition fully to heart. After making this statement Ron then goes on to temper it slightly with one of his tester attributes stating ‘(mellowed) perfectionists’ (not quite the ‘make sure they get fixed’ attitude) and then we learn that “Not all bugs you find will be fixed”. But a slight tempering does not fully mitigate the repeating of this phrase throughout the book.
I find it entertaining, and yet saddening, that one of my biggest problems with the book stems from the 6 words “…but making sure they get fixed”, but then testing does attract pedantic monsters (not one of Ron Patton’s attributes of a good tester).
And so…moving on… I do hope the beginner testers learn from the ‘Realities of Software testing section’ as Ron has built this up from experience.
Testing Fundamentals provides useful approaches to testing from, and without, specifications. Including:
- Perform high level reviews
- Build your own ‘spec’ which tells people what you plan to test
- Use an ambiguity checklist
- Don’t forget to test error messages
The fairly short dynamic black box section packs a lot into its 26 pages. For example, the Data boundary discussion read as a more pragmatic and thorough discussion than normally outlined by beginning tester books and provides a small set of classes to look for for other boundaries: Slowest/fastest, shortest/longest, empty/full, etc.
I will have no hesitation in recommending this section to a beginner tester as it provides a broad coverage very quickly and I wish I had had it available to me when I started out.
I found part III - applying your testing skills the weakest section. Hopefully testers can generalise from the section and apply some of the lists as heuristics. The configuration chapter goes into more detail than most testers will use, but I hope testers can generalise from it and apply configuration lessons presented here to more than just the hardware. The Usability chapter will hopefully encourage testers to keep their eyes open as they test to items beyond the specification and requirements.
Part 4 consists of two chapters, one on automated testing and the other on beta testing. The automated testing chapter hints at tools that I don’t see many testers using (monitoring software) so I gave positive marks on seeing that mentioned and Ron tempts the reader with a tool called “Koko the smart monkey” but a little unfairly as the tool doesn’t appear downloadable or available from anywhere online that I could find, so while the chapter offers possibilities it provides a very basic overview of automation. Similarly the beta testing chapter, I found too sparse.
Chapter 16 starts with the important distinction between ‘planning your testing’ and ‘writing your test plan’.
“The ultimate goal of the test planning process is communicating (not recording) the software test team’s intent, its expectations, and its understanding of the testing that’s to be performed… Of course, the result of the test planning process will be a document of some sort.”
This chapter combined with James Bach’s Test Plan Building Process and Test Plan Evaluation Model should put a junior tester in a good position to construct a good test plan that communicates their intents and concerns.
The Test Case Chapter (17) provides the splendid advice of
“[test case] level [of detail] is determined by your industry, your company, your project, and your team.”
In other words, your context.
“It’s unlikely that you’ll need to document your test cases down to the greatest level of detail…”
I consider this good advice for testers to take, that you treat the level of detail required for your documentation as a negotiation with the project to meet its needs.
Chapter 21 embraces the unfortunate decision to embed a lot of information and web links in the “Career as a Software Tester” when an up to date online web page with this information would support the reader better but the text book does not seem to have a major up to date web presence.
So…I come to the end of the book and have mixed feelings.I like part 1, 2, and 5, but was less keen on parts 3, 4 and 6. fortunately I consider parts 1,2 and 5 as the most important parts. I did not see enough in the book that would irreparably damage a beginner tester so I can recommend Software Testing by Ron Patton to the beginning tester - mainly because of its down to earth tone and hints & tips approach.
You will need a Github account to comment. Or you can contact me with your comment.
I reserve the right to delete spam comments e.g. if your comment adds no value and its purpose is simply to create a backlink to another site offering training, or courses, etc.