I recently read the blog post “Top 5 Lame Excuses for Not Having Enough Testers/Testing”,  by Debasis Pradhan. This blog post goes along with the common theme of nailing home the importance of testing/testers (which is why I chose this post), but this time it focuses of the main excuses given not to have them. The five excuses listed were :

1. My Product isn’t Finished Yet
2. Quality is Everyone’s Responsibility; No Dedicated Testers are Needed
3. We have Budget/Time Constraints
4. My Product is Perfect. It doesn’t need Testing
5. A separate QA team can build an ‘US vs Them mentality

The pitfalls listed above can be fairly easy to fall into. As a developer and especially as a business any opportunity to cut costs and just push a product out there is instantly jumped on. Unfortunately testing is what takes a hit when we try to cut these corners. In the blog post the author counters the first point by stressing the importance of testing during development. Without testing, sure the product will be “completed” faster, but it will probably be riddled with bugs and end up costing you more, or damaging your reputation with your client(s) when you deliver a sub-par product. The other point that stood out to me was the last one, having worked on a QA team (though it might not be the same everywhere) I’ve noticed the QA and Dev have a great relationship.  If the communication is there between the teams, then it benefits everyone. The QA team gets a better understanding of the specs and what is being developed, and the Dev team gets to focus on developing without having to stress too much about testing and meeting specs.

Here is the link to the post: http://www.softwaretestingtricks.com/2013/02/Top-5-Stupid-Excuses-Lack-of-Enough-Testers-Testing.html

From the blog CS@Worcester – Site Title by lphilippeau and used with permission of the author. All other rights reserved by the author.

I chose to write my post about this article because I am guilty of thinking “I’m pretty sure this works” and not testing my code, then running into a bug later on. I’m not the only one is guilty of doing that, developers and companies around the world often do the same thing, and though sometimes we get away with it, other times it completely blows up in our faces. I wanted to read this article to see the arguments the author had against this common dev habit.

The first and most obvious argument that the author gave was making certain that the system actually met it’s objectives. Developing a product is expensive, and companies might think that it’s more effective to just have the developers “test” as they code, and save money by not having a dedicated team (or at least not a big one). The problem that comes up with this is that as a dev the pressure is on you to just get the product out there, and testing often takes a backseat. Yes, you might have saved some cash by skipping on testing, but you’ll end up losing a lot more money when the client gets the product and it doesn’t even work!

The author had many more strong points, but the most significant was how he elaborated that in some cases, not testing enough can be catastrophic and even fatal. For most software we typically test with a pretty high level of confidence, we might test a few edge cases here and there and move on. In other cases (Air Traffic Control, Medical Software, etc) you have to test for certainty or else you have a lawsuit or even death(s) on your hand.  This post was mostly geared towards the importance of testing for businesses in general, but it did a pretty good job solidifying in my mind how important that testing that I never want to do is. It made me realize developing isn’t just about getting any code out as quickly as possible, and that in the long run good testing will save you time and money.

source: http://www.softwaretestingtricks.com/2013/08/Importance-of-Cost-effective-Software-Testing.html

From the blog CS@Worcester – Site Title by lphilippeau and used with permission of the author. All other rights reserved by the author.

I read the post “Top 5 Common Myths in Software Testing”,  this is a somewhat old post, but all of the myths mentioned inside it are still going around to this day.  The 5 myths that the author debunked in order were:

1. Software Testing is a Mundane No-Brainer Job
2. A Tester Should Be Able To Test Everything
3. A Tester’s Job is to Find Bugs
4. Testers Add No Value to The Software
5. Test Automation Will Eliminate Human Testers

For the first myth, the author argues that the job is only mundane and boring if you are doing it wrong. He argues that testing cannot be boring if you see the process as information gathering and not just running routine tests looking for bugs.  For the second myth he argues correctly that testers are limited by a variety of different factors such as time, or inability to test certain cases because of the lacking infrastructure. The author makes it clear that while one of the key roles of a tester is to find bugs, it is not their only, (and this also leads to the next myth) testers ensure that the product actually meets the requirements, make sure the product is user friendly, etc. He also explains why he believes that Automation will never replace human testers, and that reason is emotion. Essentially he believes that no matter how advanced Automation becomes it will never have that human perspective.

The reason that I chose this post is because I had some preconceived notions about testing that were quickly proven wrong when I did an internship as a tester. I wanted to see if the things that I believed  before were any of the common myths inside this post. After reading the article I realized that I believed all the these myths before my internship experience.  The biggest one for me was “A Tester’s Job is to Find Bugs”, while this was true, we also had many more responsibilities. One thing that surprised me was the strict standards that the testers had for documentation, they took this REALLY seriously! If an API was not extensively documented, that would be considered a severe bug. That level of detail showed me that testing really isn’t just finding bugs, but also making sure that the product simply works, and most importantly is easy to use. This article really hit home the point for me.

It can be found at: http://www.softwaretestingtricks.com/2012/04/top-5-common-myths-in-software-testing.html

From the blog CS@Worcester – Site Title by lphilippeau and used with permission of the author. All other rights reserved by the author.

Welcome to my Software Testing blog, this is the first post.

From the blog CS@Worcester – Site Title by lphilippeau and used with permission of the author. All other rights reserved by the author.