The Software Testing Club recently put out an eBook called "99 Things You Can Do to Become a Better Tester". Some of them are really general and vague. Some of them are remarkably specific.
My goal for the next few weeks is to take the "99 Things" book and see if I can put my own personal spin on each of them, and make a personal workshop out of each of the suggestions.
Suggestion #43: Read the release notes for products you use (or even ones you don't use), many list the bugs they've fixed. Test whether the same bugs exist in your product. - Amy Phillips
I received an interesting request through Twitter from someone who was interested in making a shift into software testing. She asked me what she could do to start to help learn about and understand how to test applications, and as I was getting ready to reply to her, I noticed that this was the next suggestion. How convenient :).
Workshop #43: Look at the release notes of a variety of applications that are similar or share a scope with your application, or an application you are interested in. Using the release notes as a list of ideas, see if another application may have similar issues.
Many software applications issue release notes with the updates that they provide. These release notes talk about new features and they talk about bug fixes. The release notes are, of course, relevant to the application in question, but it also can act as a "suggested areas of interest" guide to other applications.
Let's take something basic, like a image manipulation tool. These tools often use similar controls, have similar paradigms, and therefore, might have similar implementation problems. One company's release notes for their product, if it contains a number of bugs, can provide good avenues to explore a similar product. This will require a bit of extrapolation, since the tools themselves may do things in different ways (there may not be an exact A:B comparison between two tools).
Let's consider the way that an image application handles format conversions. Application A may have a workflow to increase or decrease the resolution, and in product A, there is a note that the constrain options are not scaling correctly (the increase in size and dimension with an increase in pixels or DPI). If that's an area that was an issue for one application, is it possible that another app, with similar controls, may have a similar problem? This gives some avenues to consider as we explore two apps with similar functionality.
Even if the two apps "work", there might be significant differences in how work-flows are being sequenced. One of the heuristic oracle examples is "consistent with other products". If you notice that a work-flow for Application A is significantly simpler than Application B, we can make a case that we need to rework or reconsider how we execute these steps, since Application A is much more efficient and straightforward.
This argument may or may not have sway, depending on how much of a de-facto standard Application A is. Consider a program that has Spreadsheet functionality. Excel has gone through and made comprehensive changes to how they handle certain formulas. Those changes going into Excel could have enormous sway over another spreadsheet provider's formula calculation algorithms. In short, if Excel makes a change/fix, other companies will likely follow suit.
One other good aspect of reviewing the release notes is that you can go through and verify for yourself that bugs in the release notes have been fixed. This can be another interesting avenue to explore. Take the current release notes, and review the bug fixes. See where the bugs in question have been reported (which version) and download *that* version. How easy is it for you to reproduce the bug? Once you have determined that you can reproduce the bug, upgrade to the latest version, and see that the bug has actually been fixed. the release notes say it's been fixed, but has it really? Can you prove them wrong? It's possible you can't, but you may find a different issue in the same area as a result of the latest fix.
Bottom Line:
If you are interested in seeing what bugs or issues are in systems, it can be very instructive to see what bugs have been fixed. Bugs tend to congregate together. It's rare that a bug in functionality happens entirely in isolation. When there are issues in one area, there are very likely to be more issues lurking nearby. Installing old versions and confirming bugs, and then uploading new versions to confirm bugs is great practice.
No comments:
Post a Comment