The best practices for Logging Software Testing Bugs
• To take image of every step in the process.

[James’ Reply: That is not a best practice. If it’s a practice you like, just say that. Meanwhile, you should talk about what situations would not benefit from this practice.]

• A lot of tools automate a number of features of the procedure, which serve up to add to effectiveness and decrease costs.

[James’ Reply: I don’t know what that means, but it can’t be a best practice, since there is no such thing as a best practice.]

This might be a magnificent method to demonstrate reports to managers. Thanks again for this post!

I keep on coming back to it time & time again. I give it to testers but usually I hand a copy to the developers. They complain at first and after they read it they go: “Hey, this is really a good idea….”.

Maybe you should re-work this into something more prominent & permanent on your site. I think it adds a lot of value.

I also find logging especially interesting from an automation perspective. I can have watchers on a log, that alert me if certain conditions that I want to know about occur (i.e. see if a defect has actually been resolved if there is doubt about the fix).

[James’ Reply: Burp Proxy.]

Sebi

David

The benefit is much bigger for progress/status reports (that are seen in the screen as actions happen), but it is the same for logs:
There are times where an application will crash, but all the data the users/testers have is what was done until now. The developer can (easily or not) deduce what the app was doing when it crashed because he knows the flow — but the users are left with guessing.

Without this little aid, if function E crashes when called after D, but E is *not always* called, a log for crash would look like “A, F, B, D, ” while a log without crash would look “A, F, B, D, G, A”. Hard to see the reason, right? Had the testers know that function E was starting, the ‘sporadic’ issue would have been isolated much more easily.

Well, I guess the point is made, will stop repeating :).
Thanks!!

As you say, not only it is hard for one routine to know what will be the next routine called, but doing that would wreck modularity cohesion and low-coupling :).

But for most part (perceiving delays, or analyzing hangs for example) logging at the beginning of each routine would be enough.

[James reply: Okay, so logging “I’m about to try this… if you don’t hear from me, tell my wife I love her…”]

If I may, let me add a 14th point, an insight I learned from a tester in my team:
For functions the software does by itself, in addition to logging the result of each step after it happens (imported data; generated report; exported graph…) it is very useful to log *what the next step will be*. This way, when a failure occurs, it is easy to know what the software was trying to do.

Since I learned that, I am paying attention to it, and impressed by how much common logs or progress reports lack this.
It takes a lot of time for an operation to happen, but you need to wait until the end of it to know which it was.
Once my computer froze during Windows’ shutdown with the “playing logoff sound” screen. I’m pretty sure the sound playing was over, and was left wondering what caused the OS freeze.

Hope you approve the addition 🙂

[James’ Reply: Let’s say I’m a programmer. How would I actually implement this? Are you just saying you want me to log the start of events, instead of just logging when things end?

Obviously, I can’t know, from within a specific routine, what the next thing will be.]

One thing that was nice was that the logs were not written to files, rather they were submitted via XML objects to a logging service which greatly enhanced the efficiency and was less of a drain on the system (as writing to disk is slower and more of a resource hog). Also, there was a configuration file which allowed us to set different logging levels for each environment (info, error, debug, etc…). The data/variable pairs would align with a global variable for whatever environment in which the code was deployed.

[James’ Reply: Cool. I have also used SQL Server transaction logs as log files, and you get those for free in database apps.]

I hesitate to say this, but we were a scripted organization 🙂 I hope we’re allowed to post here.

[James’ Reply: You can post it. But what do you mean by it? Detailed procedural scripts? If so, why? You had logging, which is like having a GPS track of where you were patrolling, but you still felt that letting your drivers patrol as they saw fit was bad?]

While we may differ on certain aspects of testing, I agree wholeheartedly that logging (or the absence of) is one of the most overlooked gems for a tester. Monitoring and rigid examination of logs is something I try to instill into each member of my testing team. When engaged in a project in the planning and analysis phases, it’s also something I urge the architects to consider.

[James’ Reply: We don’t yet know if we differ. I do plenty of planning in my testing, when the situation calls for it. To be exploratory means to not STOP planning once you have a “plan.”]

[James’ Reply: Excellent point.]