sugar-trail/AIM.md

AIM

Aims

• to enable developers, project managers ad QA managers to create a standardized infrastructure of testing documentation

• to provide tools to deliver that documentation to a wider spectrum of testers, be it beta-testers, alpha testers or an outsourced testing team

• to allow for repoting of issues in a standard form, allowing reference to particular piece of documentation, minimizing effort needed to communicate context

Background

I have experience with a system of managing test cases and test documentation in a form of a filesystem tree filed up with a test procedure-per-file, each of them following a locally defined syntax. Each of these files could be either used to generate HTML containing a table with testing steps, or imported to DevTest, a local test documentation and planning system.

Each of these files represented a testing procedure valid for a particular version of the software and was subject to local VCS (subversion).

However, the tree was huge, and due to constant development and even changing of requirements, the tree was getting old. As a result, there were many cases when an incident report was raised against, say, version 1.2.3 of the SW, but the documentation was only relevant to version 1.1.0.

Normally it is tester's responsibility to include in report the particular version of the documentation they were using to determine the oracle in the first place. However, there are cases when this just doesn't happen. Typical examples include of beta-testing, where many testers have only a little knowledge about how the system works and little experience to understand how important this is.

HOW

Bring up a standard markup that

• can be used in raw form (as a text/plain)

• can be served to client in a more usable form like n HTML table with active elements allowing for results, comments etc.

• supports meta-data about required environments, software versions, pre-requisities, and documentation version, whic can be then easily used in the report

As a result, it sould be possible to serve test documentation in a consistent way, making it easy for inexperienced testers to catch up, at the same time lowering chances of excess confusion.