The Underlying Logic of Software Testing: Core Skills & Black‑Box Strategies

Source: TesterHome Community

 

---

 

Foreword

I’m writing this article to share what I consider to be valuable insights, in the hope of helping new colleagues who have just started testing, as well as experienced testers.

I hope that our new friends and those about to embark on a career in testing can understand the underlying logic of testing – that is, the points that may be hidden from view in our daily work, not just the obvious tasks like writing test cases, filing bugs, developing automation, or building platforms.

As the saying goes: outsiders watch the spectacle, while insiders know the craft.

I believe testers should not become mere conveyors of Product Requirements Documents (PRDs), and senior test engineers should not just be developers of testing tools.

For testers, a solid grasp of fundamental testing theory is a must, and development and coding skills are equally indispensable. Lacking either makes it difficult to become an outstanding tester.

Many testers in the past chose this path because they disliked coding. However, in the future – or even now – a tester who doesn’t understand code will struggle to excel.

Conversely, someone who only knows code but lacks a grounding in testing theory – such as test analysis, case design, and testing strategies, or who knows a little but rarely applies them in practice – is certainly not a qualified tester.

Let me walk you through some of the underlying logic of testing – the insider knowledge.

 

1. Core Competencies of an Outstanding Tester

1.1 The Three Core Competencies

• “Programming / Scripting / Automation, Communication & Expression, and Foundational Testing Theory” are recognized as the three core competencies, continuing to lead over other skills.
• Technical requirements such as database knowledge, performance testing, security testing, and big data algorithms have seen significant growth since 2020.

1.2 Why These Competencies Matter

These three core competencies are widely acknowledged and relatively stable. However, the analysis data shows that market demands for testers continuously evolve with emerging technologies.

The three core competencies remain essential and will consistently hold a central position.

1.3 The Evolution of Automation Testing

Since the days of QTP over a decade ago, automation testing has been a goal for testers.

Today, the landscape is filled with diverse automation technologies and frameworks. Market expectations of testers are higher than ever. Testers are now expected not only to write automated test cases, but also to develop and maintain automation framework platforms.

Pure black-box testers have either already upgraded their skills or are on that journey. Those relying entirely on black-box testing are becoming increasingly rare.

If you can’t write automated test cases or understand programming languages, getting your resume past the initial screening is probably a challenge.

1.4 The Risk of Over‑Focusing on Code

However, every coin has two sides. As testers become more proficient in coding, foundational testing skills risk being neglected. The professional expertise within the testing field gradually fades.

Just as a boat sailing against the current must forge ahead or be swept back:

The three core competencies should advance in parallel, without favoring one over the other.

Having participated in numerous recruitment interviews in my department, my observation is that many testers, despite years of experience, do not have a good command of test case design methods and strategies.

At least 60% of people don’t use any specific design methods for test cases, nor do they think about test analysis and design. Most are merely executors of functional tests, with little thought given to test design.

Few write test plans, and test cases are often just a breakdown of the PRD. In short, testers can all too easily become conveyors of the PRD.

As a veteran in the field, I still hope for the healthy development of the testing profession. I wish for testing professionalism to keep pace with the times, even as we acquire new skills.

After all, quality assurance is the very foundation of a tester’s role.

 

2. The Underlying Logic of Black‑Box Testing

2.1 What Is Black‑Box Testing?

It treats the program as a black box, examining whether the program functions correctly according to the PRD without considering its internal structure.

Specifically, it checks whether the program appropriately accepts input data and produces correct output.

This is the definition of black-box testing, and it is also its underlying logic.

Many people overlook definitions, but definitions often reveal fundamental truths.

2.2 Why You Should Always Go Back to the Definition

In our work, many people get accustomed to testing a certain type of system, only to switch to a new business domain and suddenly feel lost, assuming an adaptation period is always needed.

The principle remains the same: once you grasp the underlying logic of black-box testing, you can get up to speed quickly without an extended adjustment period.

Most of our testing is black-box. Therefore, regardless of the system type:

Our testing strategy is always to:

“Examine whether the program functions correctly according to the PRD, and whether it appropriately accepts input data and produces correct output.”

2.3 The PRD Is Your Anchor

Your testing basis is the PRD. You must know the PRD inside out, then analyze its inputs and outputs.

Covering these aspects will get you to about 80% – meaning you’ll be well on your way to successfully delivering the project.

2.4 A Critical Reminder

Finally, let me reiterate, as I’m concerned my point might not be clear – because everything above is common knowledge.

From day one of learning testing, everyone understands black-box testing, inputs, and outputs.

But truth often resides in simplicity. Remember its definition!

When you encounter a project and don’t know where to start testing:

Take that definition, read it three times carefully, and you will surely find the answer.

2.5 A Note on Reality

Pure black-box scenarios are actually rare in practice. Apart from understanding inputs and outputs, you must also grasp the intermediate processing logic. This will be even more helpful.

More importantly: study the PRD thoroughly. Analyze its content meticulously, leaving no paragraph or word unchecked.

PRDs and design documents often contain numerous loopholes waiting to be uncovered.

 

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

3.1 Input – A Broader Definition

Here, ‘input’ is not just simple input fields on a UI.

Anything that can trigger system execution qualifies as input.

Based on architectural layers, inputs can be categorized as follows.

3.1.1 UI Operations

Positive operations – single actions:

• Normal operations as specified (input fields, buttons, radio/checkboxes, dropdowns, etc.)
• Abnormal operations (invalid values, excessively long input, multiple rapid clicks – which can reveal duplicate submission, sluggish response, or even crashes)

Complex operations:

• Combination operations – system functions generally involve combinations; also business scenarios with simultaneous operations
• Parallel operations – concurrent operations on the same function or same data (e.g., two people modifying the same price simultaneously)

Reverse operations:

• Rollback – using browser or app back function
• Cancellation – abruptly cancelling a normal operation (e.g., after filling many fields, does cancel save or prompt?)
• Delete – deleting data via system functions

3.1.2 Service Layer Inputs (Most Easily Overlooked)

• Interface services – publicly exposed interfaces, highly prone to issues
• File uploads – triggering via files (Excel, XML) from FTP servers
• MQ messages – very common (e.g., at JD); may contain file paths or other data, making them highly flexible

Critical emphasis:

• For upstream interface inputs, analyze every field to understand all possible scenarios.
• For certain fields, trace back to the business ‘source’ to understand meaning, enumerated values, and potential outcomes.
• Due to historical reasons, source data may contain unexpected values.
• Input analysis is where you can apply Equivalence Partitioning.

3.1.3 Data Layer Inputs

• Data changes – monitoring new insertion, deletion, etc.
• Data field changes – monitoring status or combined field changes
• Cache data changes – not just DB changes
• Time changes – for scheduled tasks, time itself is an input

3.2 Output – Visible and Invisible

3.2.1 Visible Outputs

Common system feedback and user‑observable changes:

• Pop-ups, prompts, page jumps
• Data addition, modification, deletion
• Changes after interacting with images / videos, etc.

3.2.2 Invisible Outputs (Easily Overlooked, Often Problematic)

Invisible outputs include:

• Changes in the database
• Changes in cache
• Changes in system files
• Data sent to downstream interfaces

Why this matters:

While visible outputs help verify 90%+ of functionality, many fields are not displayed. Some are used only by downstream systems; others are reserved for future use.

These invisible parts frequently cause system anomalies and represent the biggest hidden risks.

Therefore, testing should not only be done from the user’s perspective, but also from the designer’s perspective, and more importantly, from the perspective of the entire product.

 

4. The Underlying Logic of Test Analysis and Design

Speaking of test analysis and design, I believe this is the most core competency of a tester.

The black-box testing and input‑output model discussed above are methods specific to functional testing. While functional testing accounts for roughly 80–90% of typical system testing, it is not the whole picture.

Moreover, it is just one phase and type of testing. To excel at testing, test analysis and design are indispensable.

4.1 The Question You Must Ask Yourself

Given a project, how do you approach testing it? How do you ensure quality?

Many interviewees answer: analyze requirements, write test cases, execute testing, issue a report.

That is merely the testing process – it outlines the sequence but does not guide a tester on how to test, how to perform test analysis, and certainly does not ensure system quality.

4.2 The 2W1H Method for Test Architects

You can use the 5W2H method for analysis. But as a test architect, you don’t need all of them.

2W + 1H is sufficient.

These three questions are the most important, yet often overlooked because they are replaced by experience.

When encountering a different system or business domain, people feel lost. This is where 2W1H analysis helps.

4.2.1 The Test Architect’s Three Questions (2W+1H)

Why – Why are we doing this project? What is its background?

• Only by knowing why can we understand what users truly want.

What – What do we need to test in this project? What is the scope?

• Only with a clear scope can we avoid missing things.

How – How do we test this project? What strategies and methods?

• Testing should have strategy and methodology.

4.2.2 The Test Lead’s Additional Questions

When – What is the expected completion timeline?

Who – What resources can be called upon?

4.2.3 Project Manager Considerations (Also for Test Leads)

Where – Is a centrally‑located, closed‑door effort needed? Should dev and test teams sit together?

• Testers must also consider: test environment, staging, production, Windows/Linux/iOS/Android, browser/version, etc.

How Much – What is the cost? How many people? What server resources?

4.3 The Core Takeaway

The underlying logic of test analysis and design is answering the three 2W1H questions effectively.

• Why + What guide test analysis (background + scope)
• How guides test design (strategy)

These are still methodologies. The detailed operational steps deserve their own article.

In the meantime, I encourage you to learn about the Heuristic Test Strategy Model (HTSM), which perfectly complements the 2W+1H approach.

 

5. Cultivating the Tester’s Inner Skills

As noted, soft skills like communication are considered one of the three core competencies for excellent testers, with over 90% agreement.

Here are my summary insights.

5.1 Proactive Communication

In the e‑commerce domain, speed and change are the norms. Some projects demand rapid launch. Due to time constraints, the PRD may have loopholes or overlooked logic.

What should testers do? Communicate.

• Communicate requirements with product managers
• Communicate design with developers
• Coordinate with other systems

Without communication, pitfalls are easily missed.

Communication must be proactive – reach out to product, development, and other test teams.

Treat yourself as the owner. The quality of the project will be safeguarded.

An employee who acts like the owner is the one the boss trusts most.

5.2 Have Your Own Standards

The fundamental basis for system testing is the requirement specification.

As testers, we are the last line of defense.

Testers must perform their own analysis, not simply follow the developer’s line of thought.

What developers tell you has already been processed and may deviate from the original requirements. This is precisely the value of testing.

Even if 99% of what they say is correct, it should only serve as reference material. You must analyze based on the requirements themselves.

5.3 Maintain a Skeptical Attitude Towards Everything

Requirements are the basis for testing, but they can also be wrong.

Testing is about questioning everything – every process, every detail.

When reading requirements:

• First, assume they are correct
• Once you have holistic understanding, start questioning:
  • Is the process complete?
  • Are there loopholes?
  • Does the function meet user needs?
  • Could abnormal operations cause problems?
  • Will users find this usable?
  • Does this feature truly solve the customer’s problem?

Use quality standards, test strategies, and experience to fuel your skepticism.

Think thrice for every feature.

5.4 Think from the Company’s and User’s Perspective

The larger the company, the more departments, the more complex the systems. Greater interdependence leads to higher failure probability.

More boundaries mean higher communication costs. If any details are missed, not considered, or assumed to be someone else’s responsibility, pitfalls emerge.

These are often discovered during integration testing, but they can severely impact schedule, causing rework and delays.

To uncover these pitfalls during testing, a lead tester is helpful. But:

The lead shouldn’t be just one person. All testers should act as the lead.

As the final quality gatekeepers:

• Don’t only see your assigned piece
• Don’t be confined to your department or team
• If you have a question about the overall system, raise it and find someone to resolve it

Testing requires seeing the big picture, not just the local view.

Think and test from the company’s position and the user’s perspective.