In my application there are multiple log files existed in test environment and production environment. How those application log leads to better software quality?
2 Answers
Application logs provide human-readable view on the application's internal state. It has low impact on software quality directly unless logging is explicitly stated as a feature and there is the risk of defect in logging mechanisms.
However logs let you understand the root cause of the issue (or even what the issue is) without necessity to debug your application in a runtime which is significantly more costly operation.
Hence I would define three points of how well-developed logs impact software quality:
- Logs let you understand what the issue is (since sometimes there is no visible marker of something is going in the wrong way)
- Logs let you understand the root-cause without runtime debugging that saves a lot of time
- Logs let you verify if the defects has been fixed if there is no other available relevant footprint your app leaves.
-
Thanks a lot. by the way, I want to learn about how to make the most of log files, make correlations between much log files from different service. such as Yarn, Hiveserver2.– lin0XuCommented Jul 5, 2018 at 9:55
-
Good practice: If the developers are writing log files, which would generally be seen as best practice, it's indicative that they are following other best practices.
Visibility: You can look through a log file to find warnings or errors easily. This can help to find issues you may not have observed using just the applications UI (for example). You might catch errors you otherwise wouldn't have - leading to more defects, more fixes, and better quality.
Debugging: In addition, you may be able to gather useful information regarding a particular error/bug. This means the quality of your defects will be better (contain more information) and make the developers life easier as they can scan through the log file and see what was happening in the run up to the error. This results in more effective bug tickets, faster turnaround, less time wasted, more bugs fixes, and better quality.
-
-
Not really to be honest. I've mostly just manually scanned through them when debugging/recon. If I was in a small team and had the ability - I would setup a small set of log tests / log scans which would purely scan through the logs after tests are performed and search for "level:ERROR" and similar and simply get a count. Keep an eye on those numbers, and if possible, look into it. I have heard that can be a useful or interesting datapoint. I've no real useful insight into that though, sorry.– DtotheKCommented Jul 6, 2018 at 10:16