Documentation testing

Documentation testing is part of non-functional testing of a product. It may be a type of black box testing that ensures that documentation about how to use the system matches with what the system does, providing proof that system changes and improvement have been documented.[1]

Description

Documentation testing includes the plans, results, and testing of a system or system component. It includes test case specifications, test plans, test procedures, test reports, and test logs. It is about the testing of all the documents stating, defining, explaining and reporting or validating requirements, procedures followed and results. Documentation testing starts with the beginning of the very first software process to be most cost effective.[2] Documentation testing includes checking the spelling and grammar to review any ambiguity or inconsistency between what functionality it performs and what it is supposed to do.

Product documentation is a critical part of the final product.[2] Poor documentation can affect the product or company reputation.[3]

Documentation is about the testing of all the documents created prior and after the testing of software.[4] Any delay in the testing of the document will increase the cost.[5] Some common artifacts about software development and testing can be specified as test cases, test plans, requirements, and traceability matrices.

Key areas

Four key areas for testing a document include instructions, examples, messages, and samples. Instructions will be needed to step by step execute the test scenarios for looking errors or their omission. Further examples can be provided to elaborate the GUI components, syntax, commands and interfaces to show executed outputs or pin points. Inconsistencies also needed to be taken care of with errors as they can confuse the users and these ambiguities will cause much damage if the user of the system will be a novice user. Examples will be needed in case of any problem that occurs to the user, particularly novice users who may check the documentation for any confusion.

Documentation problems can be handled in formal ways just the same way as the coding problems.[6] Defect reporting tools and tracking tools are the common solutions for handling defects just like as they are handled in code.

gollark: I see.
gollark: What does `pop` actually do? I know it's something something stack, is it moving the result into `eax` or taking the stack to be at `eax` or what?
gollark: How exciting.
gollark: Apparently chicken scheme (HelloBoi likes this) handles stack overflows by just shunting the entire stack onto the heap in case of overflow, or something weird like that.
gollark: This is mandatory.

See also

References

This article is issued from Wikipedia. The text is licensed under Creative Commons - Attribution - Sharealike. Additional terms may apply for the media files.