When we undertake static testing, what are the criteria we should apply to each artifact?
There are six basic criteria we recommend for static testing. These can be applied to any artifact subject to this level of testing, and provide an objective measurement of the quality of the artifact.
1. Correctness
‘Being free from error’. Is the requirement or design statement in scope for the project delivery, is it technically feasible, or relevant to the business objectives. Consider spelling and grammar as an indicator
of quality.
2. Testability
Can a tester devise test scenarios and scripts to cover all aspects of the requirement or design statement, and can the expected results be clearly defined? Is the requirement or statement ambiguous and therefore difficult to articulate as an expected result?
3. Clarity
Sounds a little obvious this one, but is the requirement or design statement clearly defined. Does it have an identified source and owner? Does it clearly prioritise the requirements? Has the section under question been documented to be deliberately vague or open to interpretation?
4. Completeness
Key words that always raise concerns for us include: may, might, or maybe. Also keep an eye out for sentences that end ‘etc’ or ‘i.e.’. Incomplete lists of values, or redirects to other documents, web links, or sites also raise concerns around artifact controls.
5. Consistency
Are all requirements presented in a consistent manner, in the correct template, with a unique id? Does the design comply with company and best practice standards? Has a priority been applied, along with an
owner of the requirement?
6. Traceability
Is the requirement or design statement in line with the scope of the deliverable, can design artifacts be traced to requirements. The benefit here will ensure there is no scope creep.
For more information read our blog Be agile & dynamic but don’t forget ‘static’ software testing
For a comprehensive list of tools then see this wikipedia article. We recommend an excellent tool by Kiuwan.
