{'fraction_non_alphanumeric': 0.026525198938992044, 'fraction_numerical': 0.0033156498673740055, 'mean_word_length': 5.084677419354839, 'pattern_counts': {'":': 0, '<': 0, '<?xml version=': 0, '>': 0, 'https://': 0, 'lorem ipsum': 0, 'www.': 0, 'xml': 0}, 'pii_count': 0, 'substrings_counts': 0, 'word_list_counts': {'cursed_substrings.json': 0, 'profanity_word_list.json': 0, 'sexual_word_list.json': 0, 'zh_pornsignals.json': 0}}
A software test documentation standard

Software testing (i.e. the process of analyzing the effectiveness and structure of a software item) has two major objectives:
 1) to identify the differences between existing and required conditions (i.e. to detect bugs) and
 2) to enable the risk of software failure to be accurately estimated.
 An assessment of risk entails the following steps:
 1) Determine the testing results. Which tests succeeded and which failed?
 2) Determine the scope and comprehensiveness of the testing process. What testing was done and what testing was not done?
 3) Estimate the risk of failure as a function of the test results, the comprehensiveness determination, and past experience with similar products and processes.
 While the risk function used by a developer and the one used by an acquirer may be different, both functions will require comprehensive data to estimate accurately. Risk assessment requires comprehensive test documentation.
 Such documentation records the plans, designs and results of the software testing process. This record makes testing tangible and permits the process to be managed, and evaluated. Comprehensive documentation enables effective communication, coordination and control. By providing visibility, test documentation enables evaluation of the software and the testing process itself. Evaluation might be made by a developer, an acquirer, a user, an auditor, or a participant in the legal system. Test documentation has many potential users.