Jira, Linux and other everyday tools

Beyond frameworks and pipelines, a tester works inside a team's set of tools: a tracker for work and bugs, a place for test cases, Linux servers with logs, and the infrastructure that makes tests pass or fail. Interviewers check that you can use these, because a good bug report or a quick log search often matters more than another automated test. This article covers the essentials of each.

Jira and how testing work is tracked

Jira is a web tool for tracking work. It organizes work as issues (also called tickets). Common types are Epic (a large feature), Story (a small piece of work that gives a user some value, with acceptance criteria, the list of conditions that must be true for it to count as done), Task, Bug and Sub-task. Issues move through a workflow such as To Do, In Progress, In Review and Done, and teams often add testing states. A tester's typical flow:

• Read stories during refinement (the ongoing work of discussing and detailing upcoming stories, often in a regular team meeting) and add questions and missing cases to the acceptance criteria.
• Link test cases to the story, so you can see which requirements have tests (coverage).
• Log each defect as a Bug with a clear title, steps to reproduce, expected and actual results, environment and build, severity (how serious the bug is), and evidence (screenshots, logs, request and response), linked to the story and the failed test.
• Retest when it is fixed, then close it, or reopen it with new evidence.

Test management tools

Tools such as Xray and Zephyr (inside Jira) or TestRail (standalone) separate three ideas. A test case is the reusable description of what to check. A test run, or execution, records the result of running chosen cases against one build or environment. A test plan groups runs for a release or sprint (a work period of one to a few weeks). Automated results can be imported from JUnit XML, so manual and automated results appear together. The value is traceability: you can follow the link from requirement to test to result to defect. A defect is another word for a bug.

Linux commands testers use

tail -f app.log                 # watch new log lines live
tail -n 200 app.log             # the last 200 lines
grep -n "ERROR" app.log         # matching lines with line numbers
grep -c "ERROR" app.log         # count matching lines
grep -ri "timeout" logs/        # search a folder, ignoring case
ps aux | grep java              # find a process
kill 12345                      # stop it by process id
chmod +x run-tests.sh           # make a script executable
df -h                           # free disk space (full agents fail builds)
du -sh target/                  # size of a folder
curl -i https://api.example.com/health   # call an API, show status and headers
ssh qa@staging-01               # log in to a server
scp qa@staging-01:/var/log/app.log .     # copy a log to your machine

Here | (a pipe) sends the output of one command into the next one. A typical use: an API test fails on staging (a test copy of the application), so you ssh (log in to another computer) to the server, tail -f the service log, repeat the call with curl, and grep the log for the request id (a unique ID that identifies one call, often found in a response header).

Networking basics

A network works in layers, where each layer does one job. The OSI model describes seven layers; in practice the four layers of the TCP/IP model (the model the internet uses) are enough: link, internet (IP addresses), transport (TCP and UDP) and application (HTTP, DNS). TCP is connection-based and reliable (it makes sure all data arrives), used by HTTP/1.1 and HTTP/2; UDP is lighter and does not make that promise, and is used by DNS lookups and by QUIC, which carries HTTP/3. You do not need more detail than this for most interviews. DNS turns names into IP addresses, and a port picks a service: 80 HTTP, 443 HTTPS, 22 SSH, 4444 Selenium Grid.

Errors map to layers. "Could not resolve host" is DNS; "connection refused" means the host answered but nothing listens on that port; a timeout often means a firewall (a filter that blocks some network traffic), a VPN (a private network link, often needed to reach company servers) or an overloaded service; certificate errors are TLS. Knowing the layer tells you whom to ask.

Caches, queues and the cloud

Kafka is a system that stores a stream of events and is used for messaging: one service publishes "order placed", and others read it later. Results then become asynchronous (they arrive a little later, not in the same moment as the request), so tests must check repeatedly with a time limit instead of asserting at once or sleeping for a fixed time. Redis is a very fast store that keeps data in memory. It is often used as a cache (a place that keeps copies of data for quick reuse), for sessions or for rate-limit counters (counts of how many calls a user made). A cache can return old data after an update until the copy expires or is cleared, so test cache clearing and expiry. Many "flaky" tests (tests that sometimes pass and sometimes fail) turn out to be late events or old cache entries.

Test infrastructure increasingly runs in the cloud: virtual machines and containers for CI agents, managed databases and queues, secret managers instead of shared passwords, and hosted browser and device grids (services that run browsers and phones for your tests). Capacity can grow for a big parallel run and shrink afterwards. Testers need to know how tests reach these systems (networks, VPNs, self-hosted runners) and to clean up the data and resources they create. Teams also use AI helpers to suggest tests, review pull requests and group failures; treat their output like any tool's and check it.

How to answer in an interview

For Jira questions, describe the flow from story to test case to bug to retest, and stress the links between them. For Linux, give the log-search example above. For networking, map one error message to its layer and to the person you would contact.

Common mistakes

• Bug reports without steps, environment or evidence.
• Reporting bugs only in chat or as comments that nobody can track.
• Calling a DNS failure or a refused connection a product bug.
• Fixed sleeps in tests of asynchronous systems.

Recap

Jira tracks stories and bugs, and a test management tool tracks cases and runs; links between them give traceability. A dozen Linux commands cover most log work. Network errors point to a layer, and queues and caches explain many "flaky" results, so tests must wait for effects with a time limit.