|
@@ -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.
|