Home

Welcome to the Ability wiki!

Please note that anything on this page is just my brainstorming. There’s not much beyond that at this point but it is coming along. I’ll have the page mockups uploaded as soon as I get some feedback from some outside sources.

While this will mostly be a placeholder for now (and the foreseeable future) I will try to keep this updated with my progress.

What’s the Point?

To describe the Abilities of your products.

1. Testability – through requirement reviews
2. Traceability – of requirements to requirements, tests to requirements, tests to quality risks
3. Maintainability – by showing you the impact of changing your requirements. This will show you what tests will need to be re-evaluated so you can assess the level of effort involved with reanalysis.
4. Releaseability (not a word, but so what) – By showing you unmitigated or unsatisfactorily (e.g. failed tests) mitigated risks.

Relationships between objects

Relationships between Quality Risks, Requirements, Test Procedures, Test Environments, and Test Executions, the objects at the center of Ability:

• Quality Risks are mitigated by test procedures when executed, by transferring the risk to another party, by having a contingency plan(s), or by explicitly ignoring the risk.
• Test procedures are mapped to the requirements they verify and the quality risks they mitigate.
• Test procedures are executed against specific releases.
• Test executions are tied to one or more test configurations/environments.
• Requirements at level N map to requirement (or requirements, I’m not sure…) at level N-1. (i.e. User Story (level 0), SRS (level 1), HLD (level 2), …)
• When a new release is created, all requirements and quality risks follow it until individual requirements or quality risks are “invalidated”.
• Test procedures take a certain amount of time to run.
  Possible Built-in Reports (others are likely, as well as custom reporting eventually)
• Residual Risk – associated with one or more test executions. This is the amount of unmitigated risk remaining. Test failures or quality risks for which there are no mitigating tests are the main factors in residual risk.
• Unverified Requirements – Requirements for which there are no test procedures.
• Release Readiness – Pulls in requirements and quality risks for that release which were verified/mitigated and those that weren’t. Note: Ability will make no judgment, it’s up to the users to determine whether or not they will be releasing given the current data.
• Test Status – for the current release. This takes all scheduled test executions for the current release and provides a report. Many of the measurements and metrics could come from Section 3.6 of the ISTQB CTAL Syllabus (pg. 39).