QA Command Line Basics

I will not forget watching a developer debug a critical issue in seconds while I was still waiting for my log viewer to open. He typed a few mysterious commands and … boom, had the exact error message. That was my wake up call to learn the command line.

If you think CLI is just for developers, think again. It’s the ultimate QA superpower that will make you faster, more independent, and much more valuable to your team. Let’s start with explaining what is Command Line Interface or in short CLI. A Command Line Interface (CLI) is simply a text-only window where you type instructions to your computer instead of using a mouse to click buttons in a GUI interface.

Why Every QA Should Learn CLI

Speed: Tasks that take minutes of clicking become seconds of typing

Independence: No more waiting for developers to send you logs or files

Power: Search massive files, monitor systems in real-time, automate anything

Career Growth: Technical QAs are in high demand and command higher salaries

Getting Started: How to Open Your Command Line Interface On Your Computer

On Remote Servers (AWS EC2, etc.):

ssh -i /path/to/your-key.pem username@server-ip

Pro Tip: Keep your .pem files organized in a ~/.ssh/ folder for easy access

What Are Command Flags? (The “Bells and Whistles” of CLI)

If you plan to use CLI, it is important to understand the flags. When you type a command in the prompt, sometimes it works perfectly all by itself. Other times, it needs a few bells and whistles to give you exactly what you want.

Those “bells and whistles” are called flags. Think of it this way:

• Sometimes you just open your phone’s camera and take a picture.
• Other times, you turn on flash.
• Or switch to portrait mode.
• Or enable HDR.
• Or record in slow motion.

Same app. Different settings.

That’s exactly how command flags work. We can use the analogy here: commands are theApp, and flags are the settings of that App. The command is the main action. The flags are the settings that adjust how that action behaves. Let’s look at a simple example: listing files in a folder.

If you are inside a project folder and you type: ls , You might see something like this, the list of files in that folder:

app.log  config.yml  test_results  run_tests.sh

That’s it. Just names. This is like opening your phone’s gallery and only seeing photo titles, no details. Now let’s add a bell and whistle with the -l flag:

ls -l

Now the output looks more like this:

-rw-r--r--  1 qa  staff   2048 Mar  1 10:15 app.log
-rw-r--r--  1 qa  staff    512 Mar  1 09:50 config.yml
drwxr-xr-x  3 qa  staff     96 Mar  1 09:30 test_results
-rwxr-xr-x  1 qa  staff   1024 Mar  1 08:00 run_tests.sh

Now you’re seeing:

• File permissions (-rw-r--r--)
• Number of links
• Owner (qa)
• File size (2048 bytes)
• Last modified date
• File name

Same folder. Same command. But with the -l flag, you turned on detailed mode.

Why Flags Matter for QA

As you can see, commands by themselves give you the basics. But adding flags to a command is like turning on features to get the information you really need.

If you only type commands without flags, you’re using the basic version of the tool. But flags unlock the real power.

A Quick Note for Beginners:

If this section is a bit confusing right now, don’t worry. I know it can feel a little overwhelming at first. You can always come back to this after you’ve worked through the rest of the blog. As you practice more with the commands and flags, it will all start to make more sense. I will end this section with a little tip. As you start using commands and flags, you might wonder, “What flags can I use with this command?”

There are easy ways to find it out.

1. Manual Pages
   Most commands come with a manual page that lists all the available flags and options. To access it, just type: man <command_name>

For example, if you want to know more about the ls command and its flags, you would type: man ls

2. Help Command
   Many commands also offer a quick help summary by typing:
   <command_name> –help

For example: ls –help

Essential Commands for Daily QA Work

1. Navigation & File Management (Type the following bold words in your terminal)

• pwd => See where you are, say you are in /home/downloads directory, it will show it)
• ls -la => List all files with details, under your current directory.
• cd folder_name => Move to a folder, if you are in /home folder and want to go /home/documents, you may type ‘cd documents’, it will take you to documents folder
• cp file.txt backup/ => Copy files, for example copy file named file.txt to backup folder.
• mv old.txt new.txt => Move or rename files, i.e content of old.txt moved to new.txt
• rm old_log.log => Delete files (be careful!)
• mkdir test_results => Create new folders

When you need this: Organizing test artifacts, setting up test data, cleaning up old results, or just finding your way around a server.

2. Log File Mastery

• grep “ERROR” app.log => Find all “ERROR” instantly from the file app.log
• grep -C 3 “Exception” => Show 3 lines before/after the match for context “Exception”
• tail -f app.log => Watch logs in real-time during testing on screen with scrolling
• less app.log => Scroll through files easily, like browsing a page (press q to quit)
• head -20 file.log => See first 20 lines from the file file.log
• tail -20 file.log => See last 20 lines from the file file.log

When you need this: Debugging test failures, monitoring application behavior during test execution, or finding specific errors in large log files.

3. Downloading & File Compression

• wget https://example.com/test-build.tar.gz => Download file name test-build.tar.gz
• curl -O https://example.com/test-data.csv => Another way to download
• tar -xzvf build.tar.gz => Extract tar.gz files (similar to extracting zip file)
• unzip package.zip => Extract zip files
• tar -czvf logs_backup.tar.gz /path/to/logs/ => Create your own archive at /path/to/logs

When you need this: Getting the latest build to test, extracting deployment packages, or bundling test results to share with your team.

4. API Testing from CLI

• Quick health check of a website: curl https://staging-api.com/index.html
• Send test data to API curl -X POST -H “Content-Type: application/json” \   -d ‘{“test”: “data”}’ https://api.example.com/endpoint 
• Check response time curl -w “Response: %{http_code} Time: %{time_total}s\n” https://api.example.com

When you need this: Quick API smoke testing, verifying endpoints are alive before starting tests, or testing webhooks & endpoints without using Postman or similar tools.

5. Database Verification

• Assuming you’ve MySQL cmd line tools installed, you may type at the prompt, mysql -u qa_user -p -h db-server test_database (Basically you’re connecting to mysql db with your credentials). Now after connection established, query db directly
• mysql> SELECT COUNT(*) FROM orders WHERE status = ‘failed’; 
• PostgreSQL   psql -h db-server -U qa_user -d test_database, after connection established psql> SELECT * FROM users WHERE created_date > ‘2024-01-01’;

When you need this: Verifying test data was created correctly, checking database state after test runs, or validating data migrations during deployment testing.

6. System & Server Monitoring

• top or htop => See running processes and resource usage
• df -h => Check disk space
• free -h => Check memory usage
• ps aux | grep java => Find specific processes
• netstat -tulnp => Check what’s running on which ports

When you need this: Load and Performance testing – monitoring server health during stress tests, checking for memory leaks, or verifying the application is running on expected ports. Also useful when tests are running slow and you suspect system resource issues.

7. Connectivity & Port Testing

Basic Server Connectivity:

• Check if a server is reachable (basic connectivity) ping example.com 
• Test if a specific port is open and responding telnet example.com 80 telnet example.com 443 telnet example.com 22 
• More modern alternative to telnet (often pre-installed) nc -zv example.com 80
• Test multiple ports  nc -zv example.com 80 443 2
• Check if a web server is responding curl -I http://example.com    
• Get just headers curl -I https://example.com    

More Practical Examples:

• After deployment, verify all required services are reachable ping app-server-01
• nc -zv app-server-01 80 443 22
• curl -I https://app-server-01/health 
• If API tests fail, first check connectivity telnet api-staging.company.com 443
  If connection fails, it’s an infrastructure issue, not a test issue

When you need this:

• Deployment verification – ensuring all services are reachable after deployment
• Troubleshooting test failures – isolating network issues from application bugs
• Firewall validation – verifying only required ports are accessible
• Environment setup – confirming test environments are properly configured

8. Security Testing Basics

As a QA, you’re often the first line of defense for basic security issues. These commands help you spot obvious security problems.

File Permission & Ownership Checks:

• Check file permissions (look for world-writable files) ls -la /app/config/ , Look for files with permissions like -rw-rw-rw- (666) or -rwxrwxrwx (777) 
• Check for files owned by root but writable by others find /app -type f -perm /o=w -ls 
• Check SUID files (can be security risks) find / -perm -4000 2>/dev/null

Network Security Checks:

See what ports are open and what’s listening netstat -tulnp

ss is newer alternative to netstat, ss -tulnp 
Check if sensitive ports are exposed to the world

nmap -sT localhost  # scan local machine for open ports 
Verify SSL certificate openssl s_client -connect example.com:443 < /dev/null

Integrity & Checksum Verification:

Verify downloaded files haven’t been tampered with md5sum application.jar sha256sum application.jar 

Content Security Checks:

Search for hardcoded passwords in config filesg

grep -r “password” /app/config/ –include=”*.properties” grep -r “pwd\|pass\|secret” /app/ –include=”*.java” –include=”*.py”  # Check for exposed API keys grep -r “AKIA[0-9A-Z]” /app/  # AWS key pattern

When you need this:

• During deployment verification – checking file permissions and sensitive data exposure
• Build validation – verifying downloaded artifacts match expected checksums
• Security audits – identifying misconfigured services and exposed ports
• Compliance testing – ensuring basic security standards are met

9. Permission Fixes

• ls -l script.sh → Check file permissions
• chmod +x deploy.sh → Make a script executable
• chmod 755 config.file → Set specific permissions

When you need this: When automation scripts won’t run due to “Permission denied” errors, or when you need to modify configuration files and get “Access denied” messages.

10. Finding Anything

• find /app -name “*.log” → Find all log files
• find /var/log -mtime -1 → Find files modified in last day
• grep -r “DatabaseError” /path/to/logs/ → Search through multiple files

When you need this: Locating configuration files on an unfamiliar server, finding all recent log files, or searching for specific error patterns across multiple files.

Automation & Scripting

Simple One-Liners:

Count test failures grep “FAILED” results.xml | wc -l 

Backup test results with timestamp cp -r test_results/ test_results_$(date +%Y%m%d)/

Basic Script Example (run_smoke_tests.sh):

#!/bin/bash echo ” Starting smoke tests…” echo “Timestamp: $(date)”  # Clean old logs rm -f /home/qa/logs/*.log  # Run API tests python3 /home/qa/tests/api_suite.py –env=staging  # Run UI tests   python3 /home/qa/tests/ui_suite.py –browser=chrome  echo ” Tests completed at $(date)”

When you need this: Automating repetitive test setup/teardown, running scheduled test suites, or creating consistent test environments.

Modern Tech Stacks

Git & Version Control:

• git clone https://github.com/company/repo.git
• git pull origin main => Get latest code
• git status => See what changed

When you need this: Getting the latest test automation code, updating your test scripts, or collaborating on test development with your team.

Docker & Containers:

• docker ps => See running containers
• docker logs container_name => Get container logs
• docker exec -it container_name /bin/bash => Enter a container

When you need this: Testing containerized applications, checking if all required services are running, or debugging issues in specific microservices.

Cloud CLI (AWS Example):

• aws s3 ls s3://my-bucket/ => List files
• aws ec2 describe-instances => Check server status
• aws logs get-log-events –log-group-name my-app => Get cloud logs

When you need this: Accessing cloud resources directly, downloading logs from cloud storage, or checking infrastructure status during environment validation.

Real-World QA Scenarios

Scenario 1: Production Issue Investigation

Instead of waiting for help, you can:

ssh -i key.pem user@production-server

tail -f /var/log/app/error.log
grep “NullPointer” /var/log/app/app.log

Scenario 2: Performance Testing Setup

Before starting load tests, verify system state:
top free -h
df -h
netstat -tulnp | grep :80

Scenario 3: Deployment Validation

After deployment, quickly verify everything works:
nc -zv new-server 80 443 22
curl -I https://new-server/health
mysql -u qa -p -h db-server -e “SELECT COUNT(*) FROM users”

Important: “Command Not Found” & How to Fix It

Here’s a secret every CLI user learns: Not every command works everywhere by default.

When you type a command like mysql or docker, you’re actually trying to run a separate program. If that program isn’t installed on the system you’re using, you’ll get a “command not found” error.

Don’t panic! This is normal. It just means you need to install that tool first.

• mysql / psql: These are database clients. You need to install them on your machine to connect to a database server.
• docker: This is a containerization platform that needs to be installed separately.
• aws / gcloud / az: These are Cloud Provider CLIs that you install to manage cloud resources.
• git: While common, it might not be on every server.

What to do? If you get a “command not found” error:

1. Ask your team: “Hey, I’m trying to use the mysql command on the staging server, but it’s not found. Is it installed, or is there another way to connect to the database?”
2. Search online: “How to install MySQL client on [Your Operating System]”
3. Check your path: Sometimes the command is installed but in a non-standard location.

This doesn’t mean you’re doing something wrong. It just means you’ve identified a dependency. Part of becoming CLI-savvy is learning what tools are available in each environment.