Many of the servers that run applications run on Linux, and they're managed through the terminal — a text window where you type commands instead of clicking with a mouse. A tester sometimes needs to look in there: check server logs, inspect a file, find a specific line. Don't be put off — a handful of commands is all you need to get started.

Let's go through the essentials: how to navigate directories, how to view file contents and logs, and where to practice without installing anything on your computer.

Why a tester needs the terminal

Not every tester needs the terminal every day, but the skill is valued and often required:

  • Logs. When something goes wrong on the server, the answer is usually in the logs — text files where the application writes what it's doing and what errors it catches. You read them in the terminal.
  • Checking files. Confirming a file was uploaded and that it contains the right data.
  • Working with a server directly. Sometimes a test environment is only accessible via the terminal.

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

Files in Linux are organized into directories (folders), just like on any computer. The basic navigation commands:

  • pwd — show where I am right now (which directory).
  • ls — show what's in the current directory. ls -l — detailed (size, date), ls -a — including hidden files.
  • cd directory-name — go into a directory. cd .. — go one level up. cd with no argument — go to the home directory.

A typical sequence: pwd (where am I) → ls (what's here) → cd logs (go into the logs directory) → ls (see which log files are there).

Viewing files and logs

The main reason a tester opens the terminal is to read logs. Useful commands:

  • cat file — print the entire file. Good for small files.
  • tail file — show the last lines. tail -n 50 file — the last 50 lines. tail -f file — follow the file live: new lines appear as they are written (handy for watching logs while you reproduce a bug).
  • head file — the opposite: the first lines.
  • grep "text" file — find lines in a file that contain a given string. For example, grep "ERROR" app.log — all lines with errors. This is the most valuable command: logs can be enormous, and grep pulls out exactly what you need.

A real-world example: you reproduced a bug, you go into the logs directory and type grep "ERROR" app.log | tail -n 20 — "show the last 20 lines containing errors." Often the cause is right there and you can attach it to the bug report.

Where to practice

You don't need to install Linux — there are online terminals (search for "online linux terminal," for example webminal or similar): open one in the browser and practice with real commands. You can get comfortable with ls, cd, cat, tail, and grep in a couple of evenings without breaking anything on your own computer.

If you're on a Mac — the terminal is already built in and understands the same commands. On Windows, WSL or Git Bash give similar behavior.

Where this applies

The terminal moves a tester from "I only see the interface" to "I can see what's happening on the server." The application crashed — you look at the logs with tail and grep, find the error, attach it to the report. You need to verify a file was created or data was written — you check with a command. It's not a must-have skill for day one, but it noticeably raises your value and is often asked about in real jobs.

Where beginners stumble:

  • Being afraid of the terminal as "programming." In practice, reading logs requires five commands: ls, cd, cat, tail, grep.
  • Reading a huge log file line by line instead of using grep "ERROR" — and drowning in thousands of lines.
  • Running unfamiliar commands on a production server. Reading (cat, tail, grep) is safe; anything that modifies or deletes — only with understanding and care.

What to learn next. You've covered the tools section. What's left is one more type of testing — localization testing — and then moving on to working in a team.