← back to the section

The application has crashed on the test environment, the developer asks you to "have a look at the logs" — and the log sits on a server running Linux, reachable only through the terminal: a text window where you type commands instead of clicking with a mouse. Don't be put off: five commands are enough to get to the line you need.

cat app.log 8,240 lines INFO ORD-76 paid INFO cart cleared INFO ORD-77 created DEBUG cache warm INFO ORD-77 item add WARN pool busy INFO ORD-77 pay start INFO ORD-78 created ERROR ORD-77 timeout INFO session close INFO ORD-77 created INFO ORD-77 item add INFO ORD-77 pay start ERROR ORD-77 timeout grep "ORD-77"4 lines INFO ORD-77 created INFO ORD-77 item add INFO ORD-77 pay start ERROR ORD-77 timeout tail -n 22 lines INFO ORD-77 pay start ERROR ORD-77 timeout the cause is hereattach it to the report

Nobody reads the whole log by eye: the file holds 8,240 lines. grep keeps only the lines about the order in question — four of them — and tail takes the last two. Three steps narrow the stream down to a single line that shows the cause: the order timed out.

Why a tester needs the terminal

The terminal is not opened for its own sake but for three ordinary jobs. The main one is logs: text files where the application writes what it is doing and what errors it catches; when something goes wrong on the server, the answer is usually in there. The second is checking a file: did it arrive, does it hold the right data. The third is an environment you cannot reach any other way, because it has no interface at all.

The terminal itself is a dialogue: you type a command, press Enter, the system runs it and shows the result.

Files in Linux are organized into directories (folders) just like on any computer, and the first thing to do is get into the one where the logs live:

  • pwd — show where I am.
  • ls — what is in the current directory; ls -l — in detail (size, date), ls -a — including hidden files.
  • cd directory-name — go into a directory, cd .. — one level up, cd with no argument — back home.

Viewing files and logs

Four commands do the actual reading:

  • cat file — print the whole file. Fine while the file is small.
  • tail file — show the last lines; tail -n 50 file — the last 50, tail -f file — follow it live: new lines appear as they are written, right while you reproduce the bug.
  • head file — the first lines instead.
  • grep "text" file — find the lines containing a given string: grep "ERROR" app.log shows every line with an error. Logs get enormous, and grep pulls out exactly what you need. -n adds the line number, -C 3 shows three lines around the match: what matters in an error is not the heading but the stack under it.

You reproduced the bug — so you go into the logs and narrow the output, the way the picture shows:

cd /var/log/app                       # where the logs live
ls -l                                 # which files are there and when they were written
grep "ORD-77" app.log | tail -n 2     # lines about the order, the last two of them
tail -f app.log | grep "ERROR"        # follow new errors live

The vertical bar | is a pipe: the output of the left command becomes the input of the right one, and the order decides. grep "ERROR" app.log | tail -n 20 picks errors out of the whole file and shows the last twenty. But tail -n 20 app.log | grep "ERROR" looks for the error only inside the last twenty lines of the file — and usually returns nothing, even though the error is there in the log.

Where to practice

You don't need to install Linux: there are online terminals (search for "online linux terminal", webminal for example) — you open one in the browser and work with real commands. On a Mac the terminal is already built in and understands the same things; on Windows, WSL or Git Bash behave similarly.

Where time gets lost

The log lines you find are attached to the bug report — and the defect stops being "something went wrong". Three things get in the way:

  • The terminal is feared as "programming" — while five commands are all it takes.
  • A huge log gets read by eye instead of grep "ERROR" — and you drown in thousands of lines.
  • An unfamiliar command is typed on a production server. Reading (cat, tail, grep) is safe, everything else — only with understanding.

In short

  • Five commands are enough: ls and cd — where I am and what is here; cat, tail, grep — what is inside the file.
  • cat is for small files; with a big log you look at the end (tail -n 50), and tail -f shows lines right while you reproduce the bug.
  • grep narrows the log down to the lines you need — by the word ERROR or by an order number.
  • Order decides in a pipe: grep selects across the whole file, while tail cuts the file first — and the error may never reach what is left.
  • Reading files is safe, changing them is not: an unfamiliar command is not typed on a production server.