With Halloween around the corner, the blog The Tester’s Horror Stories (Halloween Special) interested my this week.  The blog talked about the different types of things that can be very frightening to a tester.  It listed things like:

• Buggy software
• Inferior Test Environments
• Missed deadlines
• Feel underappreciated
• Breaking bad news
• Catching up newer technologies
• Onsite-offshore model
• Accidentally turned ON/OFF or deleting something
• Low status in the industry

I personally have been a victim of accidentally deleting something.  I had all of my test results recorded for a huge section of the product I was testing.  Unfortunately, I accidentally deleted the file with all of the information and had to redo everything.  It was by far a tester’s worst nightmare.

The writer of this blog tells the story of how he was extremely good at documentation and could get everything written up extremely quickly.  The tester went into work the day after everything was completed as he usually would.  He was called first thing in the morning into a meeting with the manager and was asked why he had written up so many invalid bugs.  The news was already spreading to the client and the manager needed an answer instantly.  Obviously as a tester it is extremely important to always make sure the bug is actually valid before you go ahead and write it up.  However, I liked how this blog more touched on the fact that you need to be able to hold yourself accountable to any mistakes you may make as an engineer.  If your name is on it, you need to take full responsibility and explain what was going on and why you did what you did.  Humans make mistakes and most of the time it won’t be the end of the world, but not owning up to it is a lot worse.

From the blog CS@Worcester – Alex's Comp Sci Blog by alexsblog13 and used with permission of the author. All other rights reserved by the author.

This week I decided to read up on Quora instead of an individual blog.  I specifically was interested in the question, “Is Software Testing easier than Software Development?”.  I found Doctor John Miller to have a very interesting and accurate response to this question.  He was the test lead at Microsoft for 7 years, and developed for Microsoft, Google and Amazon for 18 years.  He makes the point that software testing is not easier than software development at all, it’s just different.  A common misconception is that the “less intelligent” software engineers will become testers.  However, Miller says that a lot of the time Software Testing can be more difficult then actually developing the code base.  “Neither job is intrinsically harder. They require different sorts of thinking and different emphasis in code artifacts.”

I completely agree with Miller on his response.  Many of the other responses were saying that software testing is a lot easier then software development.  I find that to be very untrue.  Of course it takes a certain type of mind to be a great developer.  Having said that, you also need to have a certain type of mind to be a great tester.

One of the posts stated:

“It’s certainly true that testing is a lot easier than development. You have to know how to code in at least one programming language to do development. You only have to know how to turn on a computer to start being a tester.”

The fact that people think you only have to know how to turn on a computer to be a tester is crazy to me.  There is so much more to it then that.  You need to be able to 100% think logically to frame test scenarios beyond the box.  It can be incredibly difficult and involved.  I think software testers are very under rated and need to get more credit for what they do.

From the blog CS@Worcester – Alex's Comp Sci Blog by alexsblog13 and used with permission of the author. All other rights reserved by the author.

This week I listened to a live talk, “Fixing Performance Problems Using Someone Else’s Toolbox” by a Java expert.  The title of this video was originally what caught my eye.  As soon as I was about 2 minutes into the video, I was a little apprehensive about finishing it.  He basically was just describing what to do when the tools you depend on to test performance are no longer available.  There are tools like JConsole, Visual VM, and Java Mission Control that people usually depend on for fixing performance problems.  The Java expert talking (not sure why he didn’t say his name?!) told a story about his personal experience with a customer.  The customer went to him and said that the whole system is slow, and it’s taking forever just to login.  When the expert went to use his tools that he relies on to fix performance issues; he realized they weren’t working.  He then started to panic a little bit, but he knew that with the knowledge he had, he could figure this out a different way.  He went on to describe a series of problems that kept getting in the way of his alternative solutions.  There were things like the firewall blocking RMX, JMX not being turned on, and the system not having a X server at all.  Although I am not at all familiar with fixing performance issues, the way he went about everything and his thought process was the reason why I chose to write about this talk this week.

As a future software engineer I need to have the mindset that there is more then one way to fix everything.  When your favorite tool breaks, you need to be able to work around that issue even if it’s not the most efficient and convenient way to do it.  This video opened my eyes to the fact that all of these tools that we are so dependent on, are not by any means the only way to get things done.  We are all so used to doing things the easiest way by using tools to make things a lot quicker..but in reality we don’t NEED them.  An example in just everyday life that I can use to compare this to is, say for example your washer and dryer breaks and you don’t have the money to replace it.  Initially you are going to freak out and think, “Great now I can’t wash my clothes, what am I going to do?”  The reality of it is that you are going to have to find another option, like going to the laundry mat.  I know that may sound terrible and extremely inconvenient to have to drive somewhere just to wash your clothes, but it is possible and it’s not the end of the world.  Engineers need to be able to think logically and think about all of the possible solutions to a problem.  Your original solution may work, but what if a major component of that solution breaks?  As a computer scientist, you need to be able to apply the knowledge that you have when a tool you depend on breaks; both in the computer science world and in everyday life.

From the blog CS@Worcester – Alex's Comp Sci Blog by alexsblog13 and used with permission of the author. All other rights reserved by the author.

This week I decided to research and look up the most popular Software Testing blogs.  The name James Bach came up on nearly every website, so I started to look through his page.  I came across a post called, Variable Testers, posted kind of a while ago but I enjoyed reading it.  He talked about a personal experience he had where the vice president of a software engineering company told everyone that “they need to formalize their work”.  James went on to tell the story of how he immediately raised his hand, even if it wasn’t the most appropriate thing to do that the time, and argued that his statement was completely wrong and he couldn’t possibly of meant it.  The point of this article was to make it clear that variability is not a problem at all.  He uses the example that there are a bunch of different cars on the road, but is that really a problem?  I completely agree with James.  As a tester, why would you want to be exactly the same as every other tester?  Yes, of course there is always going to be a tester that is per-say “better” then another, but does that make them bad?  Just because someone has a different way of doing something, it doesn’t make it the wrong way!  James thinks it’s absolutely insane that someone that high up and familiar with the engineering process can even make a statement like that.  I liked how James was not afraid to raise his hand and totally tell the guy off.  I can see why people like his blog so much! He is very honest, I am definitely going to read his stuff more often.

From the blog CS@Worcester – Alex's Comp Sci Blog by alexsblog13 and used with permission of the author. All other rights reserved by the author.

This article originally caught my eye because of the title, “What To Do When There Isn’t Enough Time to Test?“.  I have been a Software Engineer intern at a company called Innovative Defense Technologies for the past 3 Summers.  I started off my internship as a Freshman (incoming Sophomore) not knowing too much about programming, so yep, I was thrown right into testing.  I have learned through my experience as an intern that there is always something else that can be tested.  Code is constantly changing as the developers fix bugs, or add new features to the product.  As a tester in a company, it is your responsibility to be able to keep testing all of the old stuff, while also keeping up with the new.  I have become extremely familiar with the testing process, and trust me when I tell you .. there is NEVER enough time to test.

The main point of the article,written by STH author Swati S., is to give testers tips on what to do when they are running out of time, and how to prevent that from happening in the first place.  The first tip that stuck out to me was to never under-estimate how much time you need.  You always want to over-estimate to make sure you 100% give yourself enough time to test everything.  There is always the chance of you running into a problem that may take you longer then expected to deal with.  When I first started integration testing, my first Summer as an intern, I remember being very overwhelmed and feeling rushed because I under estimated how long it would take me.  Another tip that I liked, was to use a test management tool.  It is a lot easier to keep track of everything when you use something to help make life easier.  I thought the conclusion in this article was very interesting.  It states, “Finally, despite all the precautions and measures if you still find yourself crunched for time, ask help.  Most teams are willing to participate in a war room session to get things back on track.”  I can say that though personal experience this is very much true.  Although testing may not be the most fun thing in the world to many developers, most people are always willing to help when they know you are trying to get everything ready for the release!  Overall, this was a great article and I would recommend any new tester to take the time to read through it.

Links to some more blogs I’ve viewed this week:

1. What Test Engineers do at Google
2. From jUnit to Mutation-Testing
3. When to Stop Testing
4. How To Be A Productivity Junkie
5. Google Testing Blog: Hackable Projects

From the blog CS@Worcester – Alex's Comp Sci Blog by alexsblog13 and used with permission of the author. All other rights reserved by the author.

Hi my name is Alex Bindas.  I am currently a Senior majoring in Computer Science at Worcester State University.  I just made this blog for my Software Quality and Assurance Testing course, but may eventually use it in the future for professional or personal reasons.

From the blog CS@Worcester – Alex's Comp Sci Blog by alexsblog13 and used with permission of the author. All other rights reserved by the author.