Log analysis is an important part of improving the quality of an application. However, it is often assumed that software logs are only useful to developers. This is, of course, incorrect. Some less experienced QA engineers even find looking into application logs intimidating, as it can be difficult to understand what’s available there. But, if you know what you should be looking for, log analysis can be very useful in your daily work as a QA engineer. It’s also useful for developers to have this information already available in the bug report. So, what should you be looking for in application logs?
First, you need to check that you have access to the logs of the application that you want to test. Logging is usually enabled in test environment builds, so if you have access to that, you can definitely check to see if you can find your specific application log and whether it is readable.
Error messages
Once you have confirmed that you have access to the application logs, it’s time to think about the different types of loglines and choose the one that would be most useful for you. There are many loglines that could be useful for QA engineers. You can think of any specific keywords that could indicate the part of the application that you found an issue on. After you find that part, you can check for errors, forbidden, failure or warning messages.
Crash log
One of the most useful loglines that you can search for is crash log. From my experience I can tell you that this logline has saved me from reporting multiple bug tickets for the same crash. Often the same crash is happening in many different parts of the software for different reasons like lacking device memory or some device-specific reason. To look for crash loglines, you can search for keywords like ‘crash’, ‘fatal exception’, ‘stopped responding’ and ‘fatal error’.
Network failure logline
Another useful logline that you can search for, in cases when it seems that there are issues connecting to some services, is network failure logline. This is not something that is typically logged for applications but it can be very useful, at least in a test environment, when you’re running a lot of automated tests.
Packet log
Last but not least is media packet logging. This is commonly used in communication applications to identify issues in calls. This is very useful for test automation reports as it can identify similar failure reasons in many different test scenarios. Terminology for this is project specific so I’d advise to check with the developers if anything like this is implemented and how it is defined in the log lines.
An example would be sent and received packets during A/V and screen sharing meetings. Logs should show how many packets were sent and how many were received to identify if audio and video files were actually sent or received. This would clearly explain on which end the issue occurs. For instance, when a remote user doesn’t receive any video, we can see that the video actually wasn’t sent from the other end.
Be curious and look at applications logs
There are definitely many other loglines that can be used, so be curious when working with the developers to see if there is any information that you can find yourself when there is a specific pattern to issues that you are facing regularly. If you can’t find a logline in the app you’re testing that would really help your daily work, don’t hesitate to bring it up to your team as this can help both QA engineers and developers.
Are you a seasoned QA engineer or maybe you’re looking to start your career in quality assurance? We’re always on the lookout for awesome new people to join our team. Check out our careers page for our latest open positions.