Mastering the Core Logic of Software Testing: From Black‑Box Basics to Strategic Design

I wrote this article to share valuable experiences that can help new testers and seasoned colleagues understand the underlying logic of testing, beyond writing test cases, reporting bugs, developing automation, and building platforms.

Testers should not become mere PRD carriers, and senior testers should not be limited to tool developers.

A solid grasp of basic testing theory and coding skills is essential; lacking either prevents a tester from becoming excellent.

1. Core Capabilities of an Outstanding Tester

According to the Testerhome 2021 Annual Testing Industry Survey, the three core capabilities are:

Programming/Scripting/Automation, Communication, and Testing Theory – the most valued skills.

Database, Performance, Security, and Big‑Data algorithms – demand has grown sharply since 2020.

These three core abilities remain stable, while new technical requirements keep emerging.

Since the early days of QTP, automation has been a goal for testers; today, many frameworks exist, and the market expects testers to write automation cases and maintain automation platforms.

However, as coding skills improve, fundamental testing knowledge is often neglected; the three core abilities must progress together.

From many recruitment interviews, I found that over 60% of testers cannot apply systematic test‑case design methods or think about test analysis and strategy, often reducing testing to PRD breakdown.

I hope the testing industry continues to evolve, balancing new skills with professional testing expertise.

2. Underlying Logic of Black‑Box Testing

What is black‑box testing?

It treats the program as a black box, checking whether functionality follows the PRD, whether inputs are accepted correctly, and whether outputs are correct, without considering internal structure.

Understanding this definition is crucial because it reveals the truth behind testing.

When faced with a new business type, mastering the underlying logic of black‑box testing lets you adapt quickly without a long adjustment period.

Our testing approach is always to verify that the program functions according to the PRD, receives appropriate inputs, and produces correct outputs.

First, master the PRD, analyze its inputs and outputs, and you can achieve about 80% coverage.

Remember: read the definition carefully three times when you are unsure how to start testing a project.

Emphasis: Pure black‑box testing is rare; you must also understand the processing logic and thoroughly analyze the PRD.

3. Detailed Black‑Box Logic: Input‑Output Testing Model

Input : Any action that triggers system execution, not just UI fields. Inputs can be classified by architecture layers:

1. UI‑level inputs

Normal operations – standard inputs like text fields, buttons, checkboxes, dropdowns; abnormal operations – out‑of‑range values, rapid repeated clicks, etc.

Complex operations

Composite operations – combinations of functions; business‑scenario‑related combined actions.

Parallel operations – concurrent actions by multiple users on the same feature or data.

Reverse operations

Rollback – browser or app back navigation.

Cancel – user aborts a process, requiring save or prompt handling.

Delete – system‑provided data removal.

2. Service‑layer inputs

API calls – external interfaces are common and error‑prone inputs.

File uploads – e.g., Excel or XML files from FTP trigger processing.

MQ messages – flexible inputs that may contain file paths or other data.

For any upstream input, analyze each field, understand possible values, and consider business‑origin meanings; historical data may contain unexpected values.

Use equivalence class partitioning to analyze inputs.

3. Data‑layer inputs

Data changes – monitor insertions, deletions, or field modifications in the backend.

Cache changes – monitor cache updates and timing.

Scheduled tasks – time can also be an input.

Output

Visible output : UI feedback such as dialogs, prompts, redirects, data changes, images, videos, etc.

Invisible output : Database modifications, cache updates, file changes, data sent to downstream interfaces – often the hidden source of bugs.

Visible output validates most functionality, but invisible output is critical for system stability.

Therefore, testers must consider both user‑view and system‑view perspectives.

4. Underlying Logic of Test Analysis and Design

Test analysis and design are the core capabilities of a tester. The black‑box model and input‑output model address functional testing, which covers 80‑90% of testing but is not the whole picture.

Key question: When you receive a project, how do you test it and ensure quality?

Many answer: analyze requirements, write cases, execute, report – a linear process that does not guide analysis.

Use the 2W+1H method (Why, What, How) to structure analysis:

Why? – Understand the project background and user needs.

What? – Define what to test and the test scope.

How? – Choose test strategies and methods.

Test leads (or test architects) also consider:

When? – Project timeline.

Who? – Available resources.

Project managers add:

Where? – Test environment, platforms, browsers, OS, etc.

How Much? – Cost, effort, server resources.

Answering these questions drives effective test analysis and design.

Further details can be explored in the HTSM heuristic testing model, which aligns with the 2W+1H approach.

5. Inner Skills Development for Testers

Communication and expression are among the top three core abilities for testers. Below are key practices:

1. Proactive communication – In fast‑changing e‑commerce projects, actively engage with product, development, and other testers to uncover hidden issues.

2. Establish personal standards – Use the requirement specification as the primary reference, but perform independent analysis.

3. Maintain a skeptical attitude – Question every requirement, flow, and edge case to uncover hidden defects.

4. Think from both company and user perspectives – Consider system complexity, inter‑dependencies, and potential impact on downstream teams.

By sharing these experiences, I hope to contribute valuable knowledge to the testing community.

— end —