How to Extract and Implement Tool Requirements from Daily QA Work

It is well known that QA work covers a wide range, from reading requirement documents to functional testing and bug verification, requiring many auxiliary tools to improve efficiency or ensure quality; each tool originates from a clear need and development purpose.

Conversely, when we encounter inconvenient situations during work, we should consider whether a tool can solve the problem.

This article starts from small details, focusing on how to propose new tool requirements or optimisation points from daily project work and presents several generic solution ideas.

01 Discovering Needs

Problems create needs; discovering problems is the most important step.

In stable legacy projects, it is hard to think outside existing frameworks, so we should consciously look at the following situations to generate new ideas.

1. Routine Processes

Everyone knows that human‑computer interaction mainly relies on mouse and keyboard. If we replace them with more direct inputs such as voice (e.g., TNT) or brain signals (e.g., Neuralink), we apply the first‑principles thinking.

We do not need to focus on disruptive ideas; we only need to scrutinise familiar processes.

Case: Downloading Local Server Packages

Previously, the planning team needed to download a daily build package (>2 GB), extract it, and copy a folder to a specific project directory. This workflow lasted over a year until the project scaled up, bandwidth became a bottleneck, and the issue was noticed.

The optimisation was simple: during the build, package the pkgs directory into a compressed file and upload it, reducing the download size from 2 GB to 110 MB and improving efficiency by 18×.

From this example we see that a small step can greatly optimise the whole process; we should not simply adapt to the status quo.

2. Repetitive Operations

When we encounter repetitive tasks, we can consider scripting; if the workflow is largely the same, we can combine scripts with configuration files.

Case: QA Server Startup Configuration

Previously each QA server had a hard‑coded Python script containing database address, server IP, etc. Adding a new pre‑startup POP‑PO message required editing every script, which became untenable as the number of QA servers grew.

The solution was to replace hard‑coded scripts with a generic logic that reads configuration from a central server, pushing the script and config to each QA server automatically.

3. Cumbersome Steps

Complex daily testing steps (SVN update, client version switch, server start, opening GM tools, etc.) can become as difficult as putting an elephant in a refrigerator; we should think about simplifying them.

Case: GM Shortcut Module

Testing often requires frequent modification of character attributes via GM commands, which involves entering IDs and values manually. By creating a visual tool that maps IDs to avatars and provides sliders or direct input, the process becomes mouse‑driven and far more efficient.

4. Hard‑to‑Handle Manual Problems

Some tasks are difficult to handle manually, such as verifying loot‑box contents or monster drop rates. Tools can automate these checks.

Case: Loot‑Box Item Testing

Planning tables list item IDs and probabilities, but it is hard to see the actual items. Converting IDs to icons and displaying probabilities visually makes the information instantly understandable.

5. Error‑Prone Areas

Manual copy‑paste operations often lead to missing punctuation or extra symbols. Tools should add safeguards, such as a confirmation dialog for dangerous commands like server shutdown.

Solution Approaches

1. Visualisation

Transform text or data into images (charts, maps, icons) to make information more accessible and to compare multiple values efficiently.

2. Automation

Automation reduces manual workload; it can be as simple as batch scripts or as advanced as robot‑based testing for large‑scale data (e.g., leaderboard stress tests).

3. Other Inspirations

Observe everyday tools, UI patterns, and games for ideas—e.g., using tabbed interfaces, map‑based icon placement, or progress estimations similar to subway station displays.

When designing a new tool, gather user feedback early, iterate on common pain points, and refine the UI accordingly.

Conclusion

Tool requirements can be broad (a platform) or narrow (a single helper script). The goal is always to improve efficiency and solve problems; QA professionals should continuously question current issues, propose solutions, and treat tools as products to be polished.