Review of the Book ‘Lessons Learned in Software Testing’

This is a quick review of the book “Lessons Learned in Software Testing” in a unique way. We really hope you like it. Checking on it now. 

Here are 10 Worst Things a Critic Would Say About Your Software:

It is typical practice to include a list of known issues with the QA sign off email.

This helps teams make the right decisions as to:

• Let the end-users know the problem areas
• Plan your training accordingly
• Work on Change Management
• Include these issues in the help files and documentation so we can provide alternatives, etc.

The list includes confirmed defects that were either deferred or not fixed due to time constraints and such.

[image credit]

I came across an interesting concept that is related to this concept recently during the re-read of “Lessons Learned in Software Testing: A Context-Driven Approach- by Cem Kaner, James Bach, Bret Pettichord”.

One of the lessons in this book was: “Lesson 209: A useful release report lists the 10 worst things critics might say.”

The book suggests that when QA is done testing and during sign off it is a good idea to include a list of 10 things that the critics might say about the product. This list could influence whether the product is ready to go live or not.

Further explaining this point, the book says: “…this approach lets you maintain your position as a critic of the software, rather than attempting to provide a fair assessment of the software.”

This felt like such a good idea, totally do-able and extremely useful.  I was wondering why I have never done this before.

How is this different from the known issues list we are already providing?

The former contains only the confirmed bugs not fixed yet. Functionality that isn’t working as intended – mostly minor ones. You are confined by the boundaries of what the software is supposed to do’ and “what it is not supposed to be’.

Critics have no such limitations.

So, this is where you can get candid and give your honest opinion.

What might this list contain?

• Functionality problems
• Performance issues
• Design suggestions
• Enhancement suggestions
• UI/UX
• Clarity and relevance of error messages, etc.

Example exercise:

Let’s do this for an application that is a car dealership site of sorts. It is a work in progress. Let’s assume the first release testing is done and is now ready for release.

Also check => More Software Testing Exercises Here

So, here is what my top 10 critic list would be. Also, since you are going to be unfamiliar with the site, I am going to include screenshots (wherever applicable) for an explanation.

10 Worst Software Critics Based on “Lessons Learned in Software Testing

(Note: Click on any image for an enlarged view)

#1) The hero image title capitalization would be better. Right now, it says “realize your dreams”. It looks better as “Realize Your Dreams”

#2) The “BUY CARS” page takes the user to the home page too. We have decided to implement the functionality in the future releases, but for now, it might be better to remove the “Buy cars” menu item altogether.

Why give the user something that they can’t use?

#3) Sending a message to a dealer is a good idea. However, car salesmen are famous (or infamous) for not letting the customer leave without buying the car. So the chat option might be more on point.

#4) The “Write Your Message Here” text is accepted as the default one and when the message is submitted, it sends the body of the message as “Write Your Message Here”. The default should be empty.

#5) Nowhere on the site, there is a sale policy mentioned. It might be a good idea to include that too.

#6) The Favicon can be more effective. Maybe include a mini-car there?

#7) “CONTACT US” page will have a form that the user can fill out in order to have their queries resolved. Until that happens, an email, phone number, or physical office address as the static text has to be displayed.

#8) The user interface is good but a bigger and higher resolution car image can be more impactful.

#9) It is hard to navigate to the home page from the admin module. It does not have a “Home” link.

#10) The “VIEW INVENTORY” term for the site sounds too industrial. To make it more readable, we must try “FIND YOUR CAR” or something along those lines.

The list is not exhaustive and not always constant. Different team members can have different insights. There can also be more than 10 items on it. Pick the ones that seem most relevant.

Also, note that only a few of the items are functional problems.

I had fun doing this because who does not like pointing out problems. Right? 🙂

Exercise for you:

For beginners and experienced professionals, this would be a wonderful practice so I urge you to try ANY site/mobile app/windows system and critique it. If willing to share, share the URL of the application and your list in the comments below. We would love to compare notes with one another.

Recommended read =>“10 Lessons Learned in 10 years of Software Testing career”

A quick book review- “Lessons Learned in Software Testing”:

Finally, I can’t finish this post without pointing out a few things about “Lessons Learned in Software Testing”.

This is my second time reading it. The first time, I took everything at face value. But now, it was so wonderful to test my knowledge. If you haven’t read it already, I highly recommend trying it.

=> Get the book here.

What will you find in this book?

There are 293 points in the book. Topics range from what it means to be a tester, testing techniques, automation, bug advocacy, test documentation, context-driven-testing, people management, etc. If this happens to be your first book and introduction into testing, you are in good hands.

What will you NOT find in this book?

This is not a practical guide to anything. So, if you are looking for practical concepts on how to write test cases or how to calculate function points, this book is not what you should be reading.

Here are a few excerpts from the book that grabbed my attention and might pique your interest:

• If you expect to receive requirements on a sheaf of parchment, stamped with the seal of universal truth, find another line of work.
• When you perform a test by hand, you bring to bear the entire range of human capabilities. You can improvise new tests or notice things that you did not or could not have anticipated. Test automation is a faint, tiny echo of that rich intellectual process. That’s why it’s nonsensical to talk about automated tests as if they were automated human testing.
• Not all problems will be fixed. Don’t insist that every bug should be fixed. Pick your battles!
• If you declare there shall be no heroes in your company, you won’t get any (Talking about people management)
• Be a volunteer, not a victim. (This can be easily taken out of context. This is a point that reminds us to prioritize your obligations and plan accordingly)
• A template is no substitute for skill.

Overall, it was a very satisfying read.

Conclusion

We really hope this quick review of the “Lessons Learned in Software Testing: A Context-Driven Approach” book was helpful to you.

What software Testing books did you find most useful? Also, if there are any books you would like reviewed here, do let us know! We will surely analyse and share the review here.

About the author: The 10 critiques and book reviews are compiled by Swati S. – STH team member.

Happy critiquing! We would be thrilled to read your findings. Make sure to give your feedback in the comments section below. We would love to hear from you.