The old functional testing method (black-box) only checks whether the output is the same as what is expected for each set of inputs to a software product being tested after coding, and cannot be used to find the defects introduced into a software product in the requirement development phase and the design phase - it is why NIST (National Institute of Standards and Technology) concluded that “Briefly, experience in testing software and systems has shown that testing to high degrees of security and reliability is from a practical perspective not possible. Thus, one needs to build security, reliability, and other aspects into the system design itself and perform a security fault analysis on the implementation of the design.” (“Requiring Software Independence in VVSG 2007: STS Recommendations for the TGDC,” November 2006, http://vote.nist.gov/DraftWhitePaperOnSIinVVSG2007-20061120.pdf). ).
Differently, the innovated Transparent-box software testing method combines functional testing and structural testing together - to each set of inputs, it not only checks whether the output (if any, can be none!) is the same as what is expected, but also helps users to check whether the real software system (complete or incomplete) execution path covers the expected one specified in control flow, and automatically establishes bi-directional traceability through Time Tags automatically inserted into both software test case description and the code test coverage database to map them together, so that Transparent-box testing method can be used dynamically in the entire software development process (including the requirement development phase and the design phase where the work products (developed with NSE) are executable without a real output) to find functional defects, structural defects, and inconsistency defects.