The Practical Guide to Set High Standard of a Software Log File

Each software system has a log file. Part of them written automatically by the system but a big part of logs written by the developer during the development.

A  log file is a file that records either events that occur in an operating system or other software runs or messages between different users of communication software. 

Logging is the act of keeping a log. In the simplest case, messages are written to a single log file.

The software log is a common record and keeping data tool for software developers to troubleshoot the system. The audit file records the “what happened, when, and by whom” in the system.

Logging is used to record information about the execution of a program for debugging and testing purposes.

The audit log can identify security breaches and other computer misuse. Logging can produce technical information usable for the maintenance of applications, servers, or websites.

For Web searching, a transaction log is an electronic record of interactions (console log) that have occurred during a searching episode between a Web search engine and users searching for information on that Web search engine.

Why a Log File so Important from QA and Development Perspective?

The importance of writing to the log is huge, especially in systems of “close domain”, like financial, defense, and medical systems. In case of a bug in production, the developer requires to investigate the bug.

On these terms of systems, the developer not capable investigate the issue remotely that why the log files should cover as much as possible the features, networking, transactions, and events.

The audit can serve:

– to define whether a reported issue is actually a bug

– to help analyze, reproduce and solve bugs

– to help test new features in the development stage.

If the log coverage not enough the developer is going to waste the expensive time of investigating the issue in a software lab.

Today, in a software market we can find advanced logging tools that support logging of complex data structures, call stacks, threading behavior, and also support real-time monitoring of applications.

How to Set the Professional Standard of a Software Log File?  Here is a Practical Example : 

Level		Description
OFF		The highest possible rank and is intended to turn off logging.
FATAL		Severe errors that cause premature termination. Expect these to be immediately visible on a status console.
ERROR		Other runtime errors or unexpected conditions. Expect these to be immediately visible on a status console.
WARN		Use of deprecated APIs, poor use of API, ‘almost’ errors, other runtime situations that are undesirable or unexpected, but not necessarily “wrong”. Expect these to be immediately visible on a status console.
INFO		Interesting runtime events (startup/shutdown). Expect these to be immediately visible on a console, so be conservative and keep to a minimum.
DEBUG		Detailed information on the flow through the system. Expect these to be written to logs only.
TRACE		Most detailed information. Expect these to be written to logs only.

What are Common Logs Types?

Event logs-record events taking place in the execution of a system in order to provide an audit trail that can be used to understand the activity of the system and to diagnose problems.

Event Viewer tracks information in several different logs.

Windows Logs Include:

•  Application events. Events are classified as error, warning, or information, depending on the severity of the event.

• Security-related events. These events are called audits and are described as successful or failed to depend on the event, such as whether a user trying to log on to Windows was successful.

• Setup events. Computers that are configured as domain controllers will have additional logs displayed here.

• System events. System events are logged by Windows and Windows system services and are classified as error, warning, or information.

• Forwarded events. These events are forwarded to this log by other computers.

What Makes a Software Log Better?

The system should have 2 log levels at least, and be able to turn off tracing for performance.

• The programmer should be able to route these event streams to different locations.

• This allows you to easily keep logs for historical records, while not having them cluttered with debug info that you only want for tracing problems

•  The log made for humans, not machines, so legibility is crucial

•  Presentation of events in order of occurrence

•  Log in which the programmer/tester can easily find out what work has been done by the system.

•  Dates in region-specific formats. In the U.S., people put the month first (“06-02-2012” for June 2nd, 2012, which makes no sense), while many people in the rest of the world write a robotic-looking “2 June 2012”, yet pronounce it differently. “2012-06-02” works logically from largest to smallest, doesn’t overlap in ambiguous ways with other date formats, and is an ISO standard. Thus, it is the recommended date format for software logs.

•  Avoiding needless data copies

• Testers want to know enough information about what action is about to be performed to go back and poke around if something goes wrong. For example message ID’s email addresses, something that uniquely identifies the work item.

• Easily log sorting

• Include timestamp in the log entry

• In a large software system a tester should be able to receive logging from customers encountering problems .it also helps if you can control which parts of your application will log; for example, if there is a problem regarding ID user information you can add “ID LOGGING =EVERYTHING” and received detailed logging information on that without seeing the log information from every other section of the program.

Is this post helpful for you? Share your thoughts in comments on how it helped you. 

Join to Productive Hut Family and be part of a testing community!