Author Archives: Matthew Foley

Bug Taxonomy – Classifying Software Bugs

This week I have decided to change things up a bit. Seeing as we are now past the halfway point in the semester, I decided to start exploring some blogs other than the group I normally browse, just to try and find a different voice, a different point of view. I am happy to report I have succeeded in this mission, and have found a blog post by Michael Stahl on that clicked with me.

One of the recurring problems we face as testers is making sure that we have covered everything that could possible happen in a piece of software, good or bad. Stahl suggests using bug taxonomy as a way to think of new ideas on what needs to be covered. This type of taxonomy is not trying to compare types of testing with type of bugs, but trying to put software bugs into categories. If you have a list of categories you can go to each time you run through the testing gauntlet, it may allow you to think of new tests that need to be written for your product. A few bug items under the category of performance he suggests are from Testing Computer Software, by Cem Kaner, Hung Q. Nguyen, and Jack Falk: slow program, poor, responsiveness, and no progress reports. His list goes on, but you get the point.

Once I saw this list of categories, this strategy totally made sense to me. Basically, have a list that is entitled “Have I covered:” or something to that extent. Running through the list forces you to think of scenarios you may not have covered, but should be covered. And since the list is categorized (i.e. performance, user experience, etc.) it allows you to focus on one testing area at a time. I can tell you that after reading this post I made a list of things I need to go back and check on for something I am working on at work. So, this strategy has already paid dividends for me.

Although other testers list can be useful and is a good way to share ideas, Stahl strongly suggests making your own list to reference again and again. This is because you may not agree with how another person’s list is laid out. For example, in the list from Testing Computer Software, Stahl mention how under the performance category is “no progress reports”. He feels it should be under a user experience category. I agree that is should be under user experience, but these lists are all up to the testers opinion, so it is not wrong that the book has it in a different spot. This can be avoided by making your list.  

I really enjoyed this blog because making a bug taxonomy list seems like a relatively simple way of trying to find new tests. It practical, and be applied in everyday use without a big hit on time. We always talk about how important time is with testing, so if there is a quick and efficient way that is going to help make my tests better, I am in.


Link to picture:



From the blog CS@Worcester – README by Matthew Foley and used with permission of the author. All other rights reserved by the author.

What is Smelly Code and Why Your Code May be Stinking Up the Room -Continued…

So, we meet again with what makes code stink. As I mentioned in my blog last week, this is a continuation from the same post that I covered last week, as there were simply too many points I wanted to hit upon to fit in one post. For those who missed last week’s post or can’t remember, smelly code is basically trends in code that commonly known to cause problems. The goal is to make sure you code doesn’t stink when you are done with it, or you’ll regret it later down the line.

The next item on the list are comments. Comments can be great. They provide insight into how the developer was thinking, why they designed it the way they did, what is going on in that quadruple nested for-loop below the comment, etc. The thing is, if you are really a good developer, an argument can be made that the code can speak/explain itself. Personally, I’ve always found comments useful and insightful, but the point here is that your code should not be so ambiguous or so complicated that you need an entire paragraph just to explain what is going on. While I don’t necessary agree that there should be no comments at all, I do agree that comments should be kept to a minimum, and if you can’t, something is wrong with your code.

Pressing further down Jeff Atwood’s list of smelly code we run into the category of duplicate code. Please don’t duplicate your code. The reasons are self-explanatory, but I will reiterate: it is bad, wasteful, and inefficient. If you need to perform a task more than once, put it in a function, simple as that. You’ll save everyone a few headaches. Similarly, he mentions dead code. That is code that is sitting in there, wasting its life away as a comment or performing some task is never used, wasting resources. There should never be a need to leave unused code. The wonderful invention of version eliminated the need to leave old code sitting in a program.

The last item on his list that I want to touch upon is the bad habit of making items public when shouldn’t be, or as he calls it, indecent exposure. There should be a strong effort to make everything is as private as possible, and there should be a damn good reason if it not private. Exposing the internals of a class is dangerous and unwarranted. Unless something absolutely has to be public, it should stay private.

There were items on Atwood’s list that I felt were unnecessary or didn’t completely agree with, but overall, I found his list of code warning signs useful and brought up many valid points. As developers we want our code to be clean, efficient, and easy to read. I feel that going through this list would certainly help anyone reach that goal. A lot of the items on the list are thing experienced developers should know better than to try anyhow, but it can’t hurt double check when you are done. I know I certainly will try to run through his list in the future.


From the blog CS@Worcester – README by Matthew Foley and used with permission of the author. All other rights reserved by the author.

Quality Assurance – The Most Important Aspect of Testing

A big part of testing is making sure that the product you are working on is going to be a highly reliable, quality piece of software. Quality assurance is a big part of testing as a poorly designed product could mean bad news later on down the line. recently posted a blog that dives into this subject.

The first thing that stood out to me in the blog was a formula: Quality assurance = quality control + defect prevention. This formal makes a lot of sense to be. One of the main goals of testing is making sure it works as it should and if it doesn’t making sure someone knows it needs to be fixed. That is the quality control portion of the equation. The second part, defect prevention, is preventing bugs from getting into the software in the first place or recognizing a problem before it happens. I feel if you complete testing with confidence that those two items have been completed, you have done your job as a tester.

Now, how might one go about making sure they hit the mark with the formula? First of all, reviews are a very important aspect. This includes design reviews, specification reviews, code reviews, etc. I cannot express the importance of reviews. Getting other sets of eyes on things are crucial to making sure nothing is missed. From my experience at work, reviews are done for anything and everything, and if a review isn’t done it usually sent out with a disclaimer that whatever is being sent out is a draft. It will bite you if you don’t. Another important step to meeting the requirements of the formula is logging any issues that may have been find when testing. Any issue, not matter how small, should be logged and investigated to determine the problem and if any action is needed. This relates to the next item of the list, which is finding the root of the problem. Often a bunch of little issues that have to keep being fended off are really due to some underlying issue. It is important to make sure that you find the real issue, and not just cover it up. Lastly, make sure as a tester you utilize the resources you have available to you, especially your manager. They have the ability to get you what you need and probably know that quickest way to get it. Most of the time they are more than willing to help as your work reflects on them as well.

This blog provided a nice intro into testing with quality assurance in mind.  I found their thoughts to be intriguing and will be on the lookout for more blogs like this one considering how important quality assurance is to a piece of software.


From the blog CS@Worcester – README by Matthew Foley and used with permission of the author. All other rights reserved by the author.

What is Smelly Code and Why Your Code May be Stinking Up the Room

Code Smells. Kind of a strange phrase, isn’t it? At least I thought so while perusing Professor Wurst’s concept diagram. I decided to look it up out of curiosity and found some interesting information on it.

Well, what exactly does it mean? In short, code smells is basically code, trends, patterns, etc. that indicate there may a be an underlying issue with the code that could cause issues later down the line and/or is already causing problems. Now, that doesn’t mean the “smelly” code will always cause problems. It could be there for a specific reason. Perhaps it has to handle an odd scenario or something similar, but the point of knowing what smelly code is to be able to determine where there my be common issues or bad habits. In his blog at, Jeff Atwood dives into some signs of stinky code…

Going through his list, there are several that stuck out to me. The first couple involve length. Long methods are trouble for several reasons, but perhaps the most important is they can be hard to read and trouble shoot. Atwood mentions that methods that are significantly longer that the rest of the methods in the class/program are often trouble and it is a good idea to break it into smaller methods if possible. He also mentions lengthy parameter lists. The more parameters, the longer and more complex the method is going to be. I have to say I agree with both of these. Nothing is worse than trying to read through an endless block of code. Items can get lost and users can easily get confused or lost while trying to decrypt what is going on.

Next on the list are “oddball solutions”. If there is a problem that needs to be solved multiple times, there should only be one way of getting to that solution within the code. There may be multiple ways to get to an answer (i.e. 5*1 = 5 and 1*5 = 5), but the way of getting to the answer should be consistent throughout your code. I agree with his thoughts here. Seeing two different equations to get to one solution could certainly confuse the reader. Not to mention that if the process is the same it should probably just be put into a method anyhow.

Last on the list this week are temporary fields. Make sure that all the fields are actually needed. Unnecessary fields can cause, you guessed it, confusion. The user may think they are needed for some reason and may deem the program to not work properly or something similar. Not to mention that fields that need to be filled out each time the program is run can be extremely annoying while trying to test, so you are doing yourself a favor by keeping the number of fields down as well.

Since I have found this blog particularly useful and insightful, I plan to continue with a part two next week, so stay tuned.



From the blog CS@Worcester – README by Matthew Foley and used with permission of the author. All other rights reserved by the author.

Anti-Patterns Part 2

So this week I have decided to pick up where I left off two week ago and discuss some more anti-patterns I have found. I find them to be quite useful as they are often easy to pick out/recognize, thus they are easy to avoid. This blog by Sahand Saba discusses several of them, but once again I will pick and choose a few as space is limited.

Have you ever been looking through some code and seen random, ambiguous numbers everywhere? I’m sure you have, so I am sure you know how annoying it is. These “magic numbers” make code hard to understand and can cause problems when trying to modify it later down the line. Always try to associate numbers with a variable or at the very least some sort of description to go along with it. It will prevent headaches and problems in the future. These “magic numbers” have always been a pet peeve of mine, so this just drives the point home further for me.

The next one I’ll admit I have a tendency to do, but after reading what Saba had to say about it, I am going to try and avoid doing it in the future. This anti-pattern is being afraid to add too many classes. The story goes, sometimes developers are afraid to add more classes and they think it will increase the complexity. However, in reality, it is just the opposite. Saba likens it to a tangled ball or yarns vs single strands of yards. Which is easier to work with? I think you know the answer. That example really made it clear to me that smaller, simpler classes really do make it easier and less complex.

Over analyzing is the last one I wanted to mention. This is basically thinking and discussing about a problem so much, that no work actually ever gets done on it. To avoid this, it is suggested that you break apart the problem into smaller pieces/iterations (a.k.a. Agile Software Development) and address them one step at a time. This way the overall problem is far less overwhelming and easier to deal with. I feel that this a very important skill to have and makes life a lot easier when dealing a massive, overwhelming issue. I always try to take this approach, although sometimes it can be easier said than done.

There are several other anti-patterns discussed including dealing with team meetings, management, etc., but since I am running out of space, I will leave them for another time. However, I wanted to reiterate that I feel anti-patterns are a great way to learn good coding practices. It is basically learning from other people’s mistakes and experiences, so hopefully their mistakes will allow you save some time and headaches in the future.



From the blog CS@Worcester – README by Matthew Foley and used with permission of the author. All other rights reserved by the author.

Excuses Can Be the Death of a Product

As we find ourselves really getting into the thick of the semester, I still find myself going back to the same site to find stuff to write about for this class. I’ve found to really useful and has provided me with some valuable advice. Now, about this week topic, which is “5 Excuses Every Software Tester Must Stop Giving”…

Excuses are wonderful thing when testing software as it often provides an out for when tests fail or don’t go quite as expected. It often takes a realist to get to the truth of the matter when it comes to finding the true bugs within a piece of software. This article discussed five in total, but there are two that stood out to me and since space is limited, I will focus on those.

The first one discussed is not having full control over a test environment. This allows one to blame the environment when a test doesn’t go as planned (i.e. claiming it wasn’t configured correctly). Although this can be frustrating, it can be beneficial as it gets your product out of the ideal, perfect scenario sandbox it has been developed it. It allows both the testers and developers to see how it can handle an environment closer to what it may actually be in when the product is released. Yes, technically it may not be configured correctly, but guess what, it probably won’t be in the real world either so it is important to see how it handles these situations. The article also mentions that if you really need control over the environment, you should work closely with whoever owns it. Either way, saying you don’t have control is really a poor excuse and I know personally, I will be sure to try and not use this as an excuse.

The other “excuse” that stood out to me is about not having the ability to do anything other than manual testing. In other words, you only have time to/are only allowed to do basic, by the book testing. The tester cannot collect metrics, run stress tests, etc. I agree that this often the case, but the article points out some good ways around this that I know I will take into account in the future. The main point of the work-arounds is that a lot of this “non-functional” testing may be able to be done while you are doing to regular testing. Instead of just running through the procedure, watch performance metrics at the same time for example. Maybe grab someone else to help with this rather than asking them after or doing it yourself. In other words, kill two birds with one stone. In may be a bit more challenging, but it can save time and allow for the testing to collect the information they need.

This blog provided some good detail on how to stop making excuses while testing. Excuses can kill a product as often time they are used in a way to avoid the truth. You may be able to push the truth off further down the road, but eventually it is going to come out, and one can only hope there will still be time to address the real problem.




From the blog CS@Worcester – README by Matthew Foley and used with permission of the author. All other rights reserved by the author.

When Time and Testing do not Play Nice (Which is Almost Always)

The more I continue to browse the various blogs on testing, the more I find myself gravitating to a certain kind of blog. There are many blogs on different kinds of testing, new types of testing, etc., but I find myself often going to help/tips type blogs. I find them to be quite useful, because they are easy to apply to my job. One I found this week was “What To Do When There Isn’t Enough Time To Test?”. Well, that is a very good question, isn’t it? Testing is very important and time is almost always limited. There are deadlines to meet, people to see, and places to go. Time crunches are common for testing and seeing as the course for this blog is about testing, I felt this might be some good “real world” advice.

There are lots of reasons why time be tight when testing. They talk about several reasons why this might happen, all of which I have seen before. The three big ones discussed are a poor time estimating to being with, technical problems, and disagreements between teams. Generally, it is not a good idea to have an aggressive timeline for testing. It often backfires as it is never going to go exactly as expect. I agree that technical problems are often a cause for delays, especially if the product is new and some exploratory trouble shooting is needed. This relates back to making sure you’ve allow for enough time. I’d rather be done early than stuck working nights and weekends to meet a deadline for testing. The third, disagreements, is not very common. And when I do see it, it is often due to a miscommunication more than anything. If there is a disagreement, I’d like to think it would be worked out swiftly and in a professional manner.

The article then goes into how to make sure your team does have enough time to test. The first one mentioned, is making sure you have estimated enough time. This crucial to having a successful testing experience. Now, time estimating relates a lot to what they mentioned following this: know how long the testing has taken in the past, know what the team is capable of, keep track of your progress, etc. Do you know that there is a high probability that a certain aspect of the product is going is going to break? If so, that should be factored it. To me the easiest way to make sure there is enough time to test is to think of the worst-case scenario and make sure you have allotted enough time to complete testing should that situation take place. Granted, often teams do not have the luxury of that much time, so making sure there is enough time to test goes back to having an efficient overall operation with realistic goals and deadlines. Be ambitious, but so ambitious that it comes back to bite you.

This article provided some great advice on how properly schedule testing and is something I will be sure to reference back to time and time again.


From the blog CS@Worcester – README by Matthew Foley and used with permission of the author. All other rights reserved by the author.