imported>Curlyquote: More punctuation, rephrasing sentence

2025-12-17T23:56:43Z

More punctuation, rephrasing sentence

← Previous revision		Revision as of 23:56, 17 December 2025
Line 15:		Line 15:
	Software testing can be functional or non-functional in nature.		Software testing can be functional or non-functional in nature.

	Software testing is often dynamic in nature; running the software to verify actual output matches expected. It can also be static in nature; reviewing [[source code\|code]] and its associated [[documentation]].		Software testing is often [[dynamic testing\|dynamic]] in nature: running the software to verify actual output matches expected. It can also be [[static testing\|static]] in nature: reviewing [[source code\|code]] and its associated [[documentation]].

	Software testing is often used to answer the question: Does the software do what it is supposed to do and what it needs to do?		Software testing is often used to answer the question: Does the software do what it is supposed to do and what it needs to do?
Line 409:		Line 409:
	The contradiction is caused by the use of the concepts of requirements and specified requirements but with different meanings.		The contradiction is caused by the use of the concepts of requirements and specified requirements but with different meanings.

	In the case of IEEE standards, the specified requirements, mentioned in the definition of validation, are the set of problems, needs and wants of the stakeholders that the software must solve and satisfy. Such requirements are documented in a Software Requirements Specification (SRS). And, the products mentioned in the definition of verification, are the output artifacts of every phase of the software development process. These products are, in fact, specifications such as Architectural Design Specification, Detailed Design Specification, etc. The SRS is also a specification, but it cannot be verified (at least not in the sense used here, more on this subject below).		In the case of IEEE standards, the specified requirements, mentioned in the definition of validation, are the set of problems, needs and wants of the stakeholders that the software must solve and satisfy. Such requirements are documented in a Software Requirements Specification (SRS). And, the products mentioned in the definition of verification, are the output artifacts of every phase of the software development process. These products are, in fact, specifications such as Architectural Design Specification, Detailed Design Specification, etc. The SRS is also a specification, but it cannot be verified (at least not in the sense used here – more on this subject below).

	But, for the ISO 9000, the specified requirements are the set of specifications, as just mentioned above, that must be verified. A specification, as previously explained, is the product of a software development process phase that receives another specification as input. A specification is verified successfully when it correctly implements its input specification. All the specifications can be verified except the SRS because it is the first one (it can be validated, though). ~~Examples: The~~ Design Specification must implement the SRS; and, the Construction phase artifacts must implement the Design Specification.		But, for the ISO 9000, the specified requirements are the set of specifications, as just mentioned above, that must be verified. A specification, as previously explained, is the product of a software development process phase that receives another specification as input. A specification is verified successfully when it correctly implements its input specification. All the specifications can be verified except the SRS because it is the first one (it can be validated, though). An example scenario be that the Design Specification must implement the SRS, and the Construction phase artifacts must implement the Design Specification.

	So, when these words are defined in common terms, the apparent contradiction disappears.		So, when these words are defined in common terms, the apparent contradiction disappears.

imported>Qwertesque: /* Contract Testing */ Since it is a long article, I clarified that contractual acceptance testing is mentioned previously.

2025-11-15T13:54:15Z

Contract Testing: Since it is a long article, I clarified that contractual acceptance testing is mentioned previously.

Show changes

imported>Mathiastck: /* See also */

2025-06-20T16:51:36Z

imported>MrOllie: Reverted 1 edit by Leomars Liao (talk): Not an improvement

2025-05-27T11:32:07Z

Reverted 1 edit by Leomars Liao (talk): Not an improvement

Show changes

← Previous revision		Revision as of 16:51, 20 June 2025
Line 523:		Line 523:
	* {{Annotated link\|Data validation}}		* {{Annotated link\|Data validation}}
	* {{annotated link\|Cross-browser testing}}		* {{annotated link\|Cross-browser testing}}
	* [[Database testing]], testing of databases		* [[Database testing]] – testing of databases
	* {{annotated link\|Domain testing}}		* {{annotated link\|Domain testing}}
	* {{Annotated link\|Dynamic program analysis}}		* {{Annotated link\|Dynamic program analysis}}
Line 537:		Line 537:
	* {{Annotated link\|Trace table}}		* {{Annotated link\|Trace table}}
	* {{Annotated link\|Web testing}}		* {{Annotated link\|Web testing}}
			* [[SDET]] – Software Development Engineer in Test
	{{div col end}}		{{div col end}}

Software testing - Revision history

imported>Curlyquote: More punctuation, rephrasing sentence

imported>Qwertesque: /* Contract Testing */ Since it is a long article, I clarified that contractual acceptance testing is mentioned previously.

imported>Mathiastck: /* See also */

imported>MrOllie: Reverted 1 edit by Leomars Liao (talk): Not an improvement