an important tool in the work of a tester

Hey Habr! My name is Anfisa Odintsova, I am a mentor at the Yandex Practicum on the course “Test Engineer”. Now I work in JoomPay, and earlier – in Yandex Zen and VK. In this article I will talk about an important aspect of testing – working with logs. Indeed, in the world of software development, logging plays a key role in ensuring the quality and debugging of applications. For testers, logs are a valuable tool that helps us understand how an application works, detect potential problems, and make our testing more efficient.

We will consider why logs may be needed in the work, what types of logging exist and what can be useful to us inside the log.

What are logs and when to look at them

Logs are records of events and messages created by a program or system while it is running. They are a source of information about what is happening inside the application at a certain point in time. Logs contain various data, such as error messages, warnings, information about the execution of certain actions, and much more.

When a tester looks at the logs

Depending on the type of testing being carried out, the tester can use information from the logs.

• When testing a new feature. It is worth keeping the logs open, they will help track the correctness of certain operations, the sequence of events, and other aspects of the application’s functionality.
  For example, if an error (ERROR) or warning (WARN) falls – we will talk about them in more detail later – we could always inform the developer and quickly neutralize the problem.

• When releasing an application and conducting regression testing you need to check the logs, developers often do this in teams.

• When checking interaction with external systems, such as databases, APIs, or other services. Logs can contain information about requests and responses, data transferred, status codes, and other interaction details.

• To more accurately determine the cause of the bug and debug the error. The logs may contain the necessary information to identify the bug, the logs may contain useful information about the exceptions thrown, stack traces, error messages or insufficient data that can help reproduce and understand the cause of the error. And the more information we bring to the developer, the faster he will fix the bug.

• To evaluate application performance. The logs may contain information about the execution time of certain operations, the use of resources (for example, processor, memory), and other performance indicators. The tester can use this data to identify bottlenecks in the application and suggest improvements.

• When working with system events. You may be asked by the developers or you yourself will need more detailed information to understand the operation of the system.

Types and levels of logs

First, let’s look at the categories of logs. Logs come in different types and levels of detail and criticality.

Logging levels

Logging levels determine how important information will be written to log files or displayed when the program is executed. The top level contains the most important messages. It is worth paying attention to them in the first place. The lower the logging level, the less critical, but more detailed information is contained in the log.

The tester needs them to understand whether there is a bug / how serious it is and whether it is necessary to start a bug and submit a bug report.

Logging levels are:

• FATAL: is the highest severity level of the logs and indicates the most critical errors and problems that can lead to the immediate termination of the program or system. Logs with a FATAL level usually indicate serious failures that require immediate attention and correction.

• ERROR: This level is used to record bugs and issues that may cause the application to run incorrectly. Logs with an ERROR level indicate problems that require intervention and correction.

• WARN: the WARN level indicates warnings and potential problems that are not fatal errors. Logs with a WARN level may include messages about misuse of the application, incorrect data, or other situations requiring attention.

• INFO: this level provides information about the progress of the application and important events. Logs at the INFO level contain messages that help you keep track of the main operations and state of the application. For example, they can report the start and end of certain operations, loading resources, sending and receiving requests, application state changes, and other events that can be useful for tracking the progress of a program.

• DEBUG: contains details about the progress of the application, significant variables, and other data that can be useful in detecting and fixing errors.

• TRACE: This is the most verbose logging level. TRACE level logs contain very detailed information about the state of the application, including variable values, execution steps, and other details. They are commonly used during debugging and development for deeper analysis of the application.

Levels of detail most commonly encountered by a tester

The tester most often works with errors (ERROR, rarely FATAL) and with warnings (WARN). But in order to obtain information, sometimes it happens to refer to information logs (INFO).

The logging level can be configured depending on the needs of the developer or tester.

Usually in production, the level of detail is not set to the highest, so as not to overload the logs with a large amount of information. While during development or debugging, you can use levels of detail such as DEBUG or TRACE for deeper analysis and problem tracking.

Visually, logging levels can be represented as follows:

What types of logs are there and why should a tester know them

There are several different types of logs that are widely used in programming and system administration.

Why should a tester know them? To understand what type of logs to use to check and debug a server or client, for example when testing a backend, we most likely need server logs.

A tester most often works with application logs, server logs, and system logs. Let’s see what each type means:

1. Application logs. These are logs created by the application itself during its operation. It can be web, desktop and mobile application. They contain information about the execution of operations, events, error conditions, requests, responses and other events within the application.

2. Server logs. These are logs generated by servers and web servers. They contain information about server operation, requests, errors, connections, and other events occurring on the server. Server logs help server administrators and developers monitor server health, detect performance and security issues, and configure the server environment.

Server logs are often divided into two types:

• Error logs (this is error information)

• Access Logs (general information about requests and responses to the server)

3. System logs: These are the logs written by the operating system. They contain information about the operation of the operating system, events, errors, system status, processes, network connections, and other system events.

These are the main types of logs that a tester usually has to deal with. There are also other types, but most often the tester does not use them in his work.

What is stored in the logs

Different types and logs of different details contain information of different types. The information in the logs also depends on what the developer decided to put there, and what levels of detail and criticality of the logs will be used also depends on the development decision.

Most developers try to follow the general rules for writing logs. For example, almost any log has:

• system information (time and date of the event, event ID and other service information);

• log level;

• message text (for example, error messages);

• context (more information).

Let’s see what it looks like in the error message:

date and time: 2023-05-18 10:23:45 – Specifies the exact time the error occurred.

log level: [ERROR] – indicates the error level.

Context: [Server] – indicates the component or module of the system in which the error occurred.

Error message: Exception occurred while processing request – description of the error itself.

call stack: The following lines show the call stack and indicate the classes and methods where the error occurred. This example indicates that the error occurred in the handleRequest method of the MyController class (line 32), then in the processRequest method of the Server class (line 87), and so on.

Conclusion

With knowledge of system logging, the tester can easily understand what is happening while working with the application, quickly track down errors and better describe errors within their reports. This will seriously speed up the process of fixing the bug, and hence the speed of developing new features and releases.