This is the final article in Manual Testing Foundation. After a round of requirements, test process, test cases, bugs and reports, we can finally talk about tools.
I deliberately left tools until the end because beginners easily learn backwards: memorising where Jira lives and which button to press in Postman, then freezing when asked why an Expected Result field is needed or which business rule a request is checking.
Tools make work faster and leave a better trail. They do not replace the thinking that comes first.
Project and work tracking
Jira, Azure DevOps, GitHub Projects and Linear can all track backlog, tasks, bugs and progress. Testers commonly use them to:
- Read stories and acceptance criteria.
- Track related builds or releases.
- Log and triage defects.
- Link bugs to requirements, tests or pull requests.
- See scope changes and dependencies.
The tool name matters less than the workflow. A Jira with 27 statuses still cannot save a team if nobody knows which build a Fixed bug is in.
Test management
TestRail, Zephyr, Xray, Qase and Azure Test Plans help manage test cases, test runs, results and traceability.
They start becoming useful when:
- Several people edit and run tests.
- One case runs on multiple builds or configurations.
- You need execution history and release reports.
- The spreadsheet starts growing columns named
final_v2_really_final.
A small test set can still use Markdown or a spreadsheet. Don’t buy a tool because its dashboard looks pretty; find out whether the real pain is versioning, execution, permissions, traceability or reporting.
APIs and network
Postman, Bruno, Insomnia and command-line tools such as curl call APIs. Browser DevTools shows requests, responses, cookies, storage, timing and the console.
A manual tester does not need to become a backend developer before opening the Network tab. Reading the method, URL, status, headers and body already makes a bug report much better than “clicking doesn’t work”.
Do not put production tokens, cookies or customer data into a public workspace, screenshot or collection committed to Git.
Database and data
DBeaver, DataGrip, pgAdmin and database clients help query and prepare data. Testers commonly use SQL to:
- Confirm state behind the UI or API.
- Create or find data for a scenario.
- Investigate a failure.
- Check migrations and data integrity.
Read and write permissions should be separated. Running an UPDATE without a WHERE on a shared environment is a very fast way to learn SQL, though your colleagues may find the lesson expensive.
Evidence and system observation
Screenshots, screen recorders, browser HAR files, application logs, Sentry, Grafana and Kibana help preserve evidence and investigate.
Choose what fits the failure:
- Static UI: image.
- Timing or animation: video.
- API: request/response and correlation ID.
- Backend: timestamped logs.
- Performance: metrics and traces, not the feeling that “it seems a bit slow today”.
Always hide secrets and personal data before sharing.
Accessibility and compatibility
Browser DevTools, axe, Lighthouse, screen readers and device/browser cloud services can help. Automated accessibility scans catch only some issues; they do not replace manual keyboard or screen-reader testing.
Compatibility must follow the support matrix. Testing ten random browsers is less valuable than testing the browser, OS and viewport the product actually promises to support.
Communication and documentation
Slack, Teams, Confluence, Notion and repository Markdown are only places to keep information. Important decisions must go somewhere the team can find again, not live forever in a private chat.
If a requirement is agreed in a call, record the acceptance criteria. If a workaround is accepted, update the ticket. A project’s collective memory should not depend on one person still working at the company.
How do you choose a tool?
Before adding a tool, ask:
- What is the specific problem?
- Does the tool integrate with the current workflow?
- Where does the data live, who can access it and are there secrets involved?
- Can the data be exported if we change tools later?
- Are the licence, operating and learning costs worth it?
A free tool that costs three days every month in data cleanup is not really free. A paid tool that the team uses as an online spreadsheet does not automatically become a good investment.
The end of Foundation
We have gone from what Software Testing is to reading requirements, designing and running tests, logging bugs and reporting. This knowledge will not turn anyone into a seasoned tester overnight, but when you open a real project at least you know what you are looking at and which question to ask.
The next part moves to Robot Framework. From here there will be code, command lines, libraries and bugs created by the automation script itself — which means the testing safety net also needs proper testing.
