(It had better be 'for dummies,' after all, I'm writing this for me.)

Let's start with a basic definition: a software bug is when software does something the user doesn't expect (or doesn't do something the user expects.)

From here, intermediate questions arise: who is/are the user(s)? What is/not expected? What is/not occuring?

As in writing, the first step is defining the target audience. My current component will be used by the service administration team when the end user complains. (Remember, it's "software as a service," so my user is not necessarily the end user.)

In this case, this means time is critical, accuracy paramount. The paying customer is already upset, so the service admin team needs to be able to right the wrong quickly.

In my eyes, so long as my component does not adversely affect the paying customer's user experience, said customer will not have any firsthand awareness of my product. This allows me to focus on the service admin team as my 'user.'

What is expected? Data. My 'component' is how the system logs errors (and warnings and normal running state, as well.) The admin team will be looking through logs for a specific customer's specific issue, and quickly. They need to know what the user tried to do, what the system tried to do, and have some sense of where the disconnect lies.

• Did the user fat-finger something, so it's a garbage-in-garbage-out situation? (I call this 'pilot error.')
  
  
• Did the user type the command as specified, but the documentation was unclear if that was the right command, or what the output would contain? (Documentation bug.)
  
  
• Did the system do something funny? (This is what most people think of when they say, "software bug.)

The reason this all is at the forefront of my mind is because tis been my every waking thought for the past week, and will continue to do so for the next month.

Today, however, was a funny day. The past few days I've been going crazy staring at log files. When you have "software as a service," that implies many components moving in sync with each other. This in turn leads to the likelihood that the logs are not consistent -- most SaaS project/products are not conceived fro the ground up as a unified whole. They're usually amalgamations of existing components.

Which means a motley collection of logging formats, filenames, location, data stored, etc.

So, the past few days, I've been staring at log files. 200 or so. Per day. In a small system - each component is represented, though not scaled out to how they will be when the service is available to paying customers. I don't want to think about how many log files the scaled out system will generate. But I'll have to, that's part of my job. Just a later part.

For now, I'm just looking at the logs and flagging anything that looks out-of-the-ordinary. Too verbose: a line that gets repeated over and over again, but doesn't tell the admin team if it's okay to ignore it (if so, why repeat it umpteen gazillion times?) or how to fix it. Too terse: something critical has happened, but not enough details to diagnosis it. Inconsistent: it says it failed, then says it passed, for whatever reason.

That's my first pass -- just looking at a running system, and see if the areas where things go boom have enough data so the admin team can troubleshoot it and prioritize fixing it.

My second pass would be to do the normal stuff and make sure it doesn't generate any error messages.

My last pass would be to try the abnormal stuff and make sure it does generate error messages related to my trying to break things.

Anyhow, one of the software programmers walked up to me today and asked, "You just raised two dozen issues in my code. I was wondering if that's all you think you'll find."

I had to explain that I was only doing the simplest test: what does a normally running system say/do? I haven't gotten to functional pass or negative / destructive testing yet.

The look on his face made me smile.