Browse Source

Added AIM document

A more coherent manifest of what this project is about.
Alois Mahdal 9 years ago
parent
commit
f4f16d4e52
1 changed files with 60 additions and 0 deletions
  1. 60
    0
      AIM.md

+ 60
- 0
AIM.md View File

@@ -0,0 +1,60 @@
1
+AIM
2
+===
3
+
4
+Aims
5
+----
6
+
7
+*   to enable developers, project managers ad QA managers to create
8
+    a standardized infrastructure of testing documentation
9
+
10
+*   to provide tools to deliver that documentation to a wider spectrum of
11
+    testers, be it beta-testers, alpha testers or an outsourced testing team
12
+
13
+*   to allow for repoting of issues in a standard form, allowing reference
14
+    to particular piece of documentation, minimizing effort needed to
15
+    communicate context
16
+
17
+
18
+Background
19
+----------
20
+
21
+I have experience with a system of managing test cases and test documentation
22
+in a form of a filesystem tree filed up with a test procedure-per-file, each
23
+of them following a locally defined syntax.  Each of these files could be
24
+either used to generate HTML containing a table with testing steps, or imported
25
+to DevTest, a local test documentation and planning system.
26
+
27
+Each of these files represented a testing procedure valid for a particular
28
+version of the software and was subject to local VCS (subversion).
29
+
30
+However, the tree was huge, and due to constant development and even changing
31
+of requirements, the tree was getting old.  As a result, there were many cases
32
+when an incident report was raised against, say, version 1.2.3 of the SW, but
33
+the documentation was only relevant to version 1.1.0.
34
+
35
+Normally it is tester's responsibility to include in report the particular
36
+version of the documentation they were using to determine the oracle in the
37
+first place.  However, there are cases when this just doesn't happen.  Typical
38
+examples include of beta-testing, where many testers have only a little
39
+knowledge about how the system works and little experience to understand how
40
+important this is.
41
+
42
+
43
+HOW
44
+---
45
+
46
+Bring up a standard markup that
47
+
48
+*   can be used in raw form (as a text/plain)
49
+
50
+*   can be served to client in a more usable form like n HTML table
51
+    with active elements allowing for results, comments etc.
52
+
53
+*   supports meta-data about required environments, software versions,
54
+    pre-requisities, and documentation version, whic can be then easily used
55
+    in the report
56
+
57
+
58
+As a result, it sould be possible to serve test documentation in a consistent
59
+way, making it easy for inexperienced testers to catch up, at the same time
60
+lowering chances of excess confusion.