CTAL-TAE · Question #107
A TAS uses a commercial test automation tool and the default logs generated by the inconsistent formats such as different types of messages (pass/fail steps, screenshots, warnings, etc.) To solve…
The correct answer is B. Implement the custom logging functions to support different levels of tracing. Option B is correct because implementing log levels (e.g., DEBUG, INFO, WARNING, ERROR) gives testers a "volume knob" for output - you can run verbose tracing when investigating failures and use a higher-threshold level for noisier tests, directly solving the excessive-size…
Question
A TAS uses a commercial test automation tool and the default logs generated by the inconsistent formats such as different types of messages (pass/fail steps, screenshots, warnings, etc.) To solve this issue some custom logging functions have been created from the test scripts, making it possible to log the different types of messages with the same format. However, this may cause a problem due to excessive size of the logs which can make it difficult to find the required information. Assume that all the default logs will be disabled when running the automated tests and that some tests will not generate excessively sized logs. Which of the following represents the BEST suggestion for implementing the custom logging functions?
Options
- AImplement the custom logging functions without saving timestamps
- BImplement the custom logging functions to support different levels of tracing
- CImplement the custom logging functions without saving stack traces
- DImplement the custom logging functions to redirect the logs to multiple files
How the community answered
(30 responses)- A7% (2)
- B77% (23)
- C13% (4)
- D3% (1)
Explanation
Option B is correct because implementing log levels (e.g., DEBUG, INFO, WARNING, ERROR) gives testers a "volume knob" for output - you can run verbose tracing when investigating failures and use a higher-threshold level for noisier tests, directly solving the excessive-size problem without sacrificing diagnostic capability.
Option A is wrong because timestamps are essential for correlating events, measuring duration, and establishing the sequence of steps that led to a failure - removing them degrades log usefulness significantly.
Option C is wrong because stack traces are critical for pinpointing failure root causes; stripping them makes failures harder to diagnose, which defeats the purpose of logging.
Option D is wrong because splitting logs across multiple files doesn't reduce total log volume - it just fragments the same data, potentially making it harder to trace a single test's execution.
Memory tip: Think "levels = filter, not delete." Log levels let you suppress noise dynamically (set level to WARN for chatty tests), while A and C permanently delete useful data, and D just reshuffles the same mess.
Topics
Community Discussion
No community discussion yet for this question.