Explain how this paradox is overcome in a real-world software development environment?

Here is the answer of this but this was not very clear to me. How do we reduce time for white box testing? I know black box testing can be faster, but how do we reduce time for white box testing? enter image description here

  • 1
    Can you cite your source of that screenshot? Where did it come from? It seems very opinionated on time completion of different testing techniques.
    – Lee Jensen
    Commented Oct 14, 2021 at 19:20
  • ecikai.com/2019/12/the-testing-time-for-software-cannot-be.html This is the only source I have seen. It seems to be taken from KR fowler's book. Can you share your own insights on it?
    – cuajiu
    Commented Oct 15, 2021 at 2:35
  • Ok. I wouldn't trust that website. Seems very sparse on information. Also, it indicates it's from a book on Electronic Circuit Design, which is not the same as software development. I applaud you for questioning this info. The answer below from PDHide is good and would be what I'd respond with.
    – Lee Jensen
    Commented Oct 15, 2021 at 14:59

2 Answers 2


Before you start the testing processes , you should understand the main principles of testing .


  1. Testing shows presence of defects
  2. Exhaustive testing is not possible
  3. Early testing
  4. Defect clustering
  5. Pesticide paradox
  6. Testing is context dependent
  7. Absence of errors fallacy

In this most importance once are the :

Exhaustive testing is not possible and Absence of errors fallacy:

you cannot test under percentage of the code flows. You should concentrate on the business needs than functionality when testing a product, this ensures that most important workflows are covered and tested . This ensures "Absence of error fallacy", meaning you dont release a product that have no required functionality.

Early Testing:

you need to ensure a "Testing pyramid" , shift left approach where you have early testing like unit tests , integration tests , system ect

Having proper unit tests , integration test etc shows what failed and that to quickly. So it facilitates faster feedback .

if there was just system tests then developer should waste time debugging , and retesting whether it was a UI bug or backend bug , which component failed etc. If you had proper unit test, then it fails suddenly and shows where the failure is so you can save the feedback and retesting time (time is money in business)

Testing is context dependent:

Each test strategy and approach depends on the budget , team, product , team size skills etc.

Now getting back to your question:

I know black box testing can be faster, but how do we reduce time for white box ?testing?

"white box" testing is about having knowledge about the internal structure of your application , this is just a added information that you get which you can use to write more interesting test use cases . It isn't slow or faster than black box, as its not testing process but about the understanding about the product.

White box testing is usually covered with "unit tests", here we don't see the entire code base but just code base of each component. A component may be a class , or function .

Here we just verifies that we achieve around 100% of branch and statement coverage. We fail the build if we don't achieve the required coverage. This ensures that all worst case, average and best case scenarios are tested for each component.

How do we reduce time for white box testing?

  1. Write more unit tests
  2. Have proper "SOLID" principle in your system architecture and implement unit test and coverage metrics.
  3. Automate
  4. Shift left , have early testing like static code analysis, unit tests etc

So The testing time for software cannot be too long,yet software needs to be to be thoroughly tested before it can be commercialized by achieving

  1. Automate testing activities
  2. Have coverage threshold for code and branch
  3. Have static code analye
  4. Early testing
  5. Cover all business requirements
  6. DevSecOps approach where you integrate security , performance etc to the left of your build pipeline
  7. "knowing" exhaustive testing is not possible but can create confidence on the product by having proper automation coverage for all business flows, regression phase ,security and performance

At the heart of testing is a simple fact: Testing only shows the presence of defects - it does not prove the absence of them.

Thus we typically adopt the multi-layer approach...

  • Static code analysis
  • Dynamic, white box ("unit") testing
  • Dynamic, black box ("system") testing

But how do we reduce time for white box testing?

  1. First and foremost, plan the testing campaign(s) - start early. Too often, testing is left until late, and there is insufficient time left.
  2. Secondly, unit test what needs to be unit tested, and then only re-do the unit testing when it needs to be redone.
  3. Thirdly, and linked to that, look to your modularity, so that "units" are self-contained... each function/procedure serving one function, thus allowing the unit test to be focussed.
  4. Finally, automate where it can help. Don't waste time automating the one-off tests, but do automate the repeated tests.
  5. Appropriate tools will help, not just in the testing, but in the associated measures: for example in showing the level of test coverage achieved.

Most of the time, effort spent in planning the testing is recovered multi-fold... but (as the cliché goes) failing to plan is planning to fail.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.