From 2ef840647acadb489d54332f6a218dcf2e629ff9 Mon Sep 17 00:00:00 2001
From: tmanevik <tommy.manevik@combitech.se>
Date: Wed, 18 Nov 2015 18:24:10 +0100
Subject: Common Test: Editorial changes 1

Conflicts:
	lib/common_test/doc/src/ct_hooks_chapter.xml
	lib/common_test/doc/src/event_handler_chapter.xml
	lib/common_test/doc/src/run_test_chapter.xml
---
 lib/common_test/doc/src/why_test_chapter.xml | 43 ++++++++++++++--------------
 1 file changed, 21 insertions(+), 22 deletions(-)

(limited to 'lib/common_test/doc/src/why_test_chapter.xml')

diff --git a/lib/common_test/doc/src/why_test_chapter.xml b/lib/common_test/doc/src/why_test_chapter.xml
index 15eb1aaed4..ff6000628b 100644
--- a/lib/common_test/doc/src/why_test_chapter.xml
+++ b/lib/common_test/doc/src/why_test_chapter.xml
@@ -22,7 +22,7 @@
     
     </legalnotice>
 
-    <title>Some thoughts about testing</title>
+    <title>Some Thoughts about Testing</title>
     <prepared>Siri Hansen</prepared>
     <docno></docno>
     <date></date>
@@ -34,54 +34,53 @@
   <section>
     <title>Goals</title>
 
-    <p>It's not possible to prove that a program is correct by
+    <p>It is not possible to prove that a program is correct by
     testing. On the contrary, it has been formally proven that it is
     impossible to prove programs in general by testing. Theoretical
-    program proofs or plain examination of code may be viable options
-    for those that wish to certify that a program is correct. The test
+    program proofs or plain examination of code can be viable options
+    for those wishing to certify that a program is correct. The test
     server, as it is based on testing, cannot be used for
     certification. Its intended use is instead to (cost effectively)
     <em>find bugs</em>. A successful test suite is one that reveals a
-    bug. If a test suite results in Ok, then we know very little that
-    we didn't know before.</p>
+    bug. If a test suite results in OK, then we know very little that
+    we did not know before.</p>
 
   </section>
 
   <section>
-    <title>What to test?</title>
+    <title>What to Test</title>
 
     <p>
       There are many kinds of test suites. Some concentrate on
       calling every function or command (in the documented way) in 
       a certain interface.
-      Some other do the same, but uses all kinds of illegal
-      parameters, and verifies that the server stays alive and rejects
+      Some others do the same, but use all kinds of illegal
+      parameters, and verify that the server stays alive and rejects
       the requests with reasonable error codes. Some test suites
       simulate an application (typically consisting of a few modules of
-      an application), some try to do tricky requests in general, some
+      an application), some try to do tricky requests in general, and some
       test suites even test internal functions with help of special
-      load-modules on target.</p>
+      Load Modules on target.</p>
 
-    <p>Another interesting category of test suites are the ones that
-      check that fixed bugs don't reoccur. When a bugfix is introduced,
-      a test case that checks for that specific bug should be written
-      and submitted to the affected test suite(s).</p>
+    <p>Another interesting category of test suites is the one
+      checking that fixed bugs do not reoccur. When a bugfix is introduced,
+      a test case that checks for that specific bug is written
+      and submitted to the affected test suites.</p>
 
     <p>Aim for finding bugs. Write whatever test that has the highest
       probability of finding a bug, now or in the future. Concentrate
-      more on the critical parts. Bugs in critical subsystems are a lot
+      more on the critical parts. Bugs in critical subsystems are much
       more expensive than others.</p>
 
     <p>Aim for functionality testing rather than implementation
       details. Implementation details change quite often, and the test
-      suites should be long lived. Often implementation details differ
+      suites are to be long lived. Implementation details often differ
       on different platforms and versions. If implementation details
-      have to be tested, try to factor them out into separate test
-      cases. Later on these test cases may be rewritten, or just
-      skipped.</p>
+      must be tested, try to factor them out into separate test
+      cases. These test cases can later be rewritten or skipped.</p>
 
-    <p>Also, aim for testing everything once, no less, no more. It's
-      not effective having every test case fail just because one
+    <p>Also, aim for testing everything once, no less, no more. It is
+      not effective having every test case fail only because one
       function in the interface changed.</p>
 
   </section>
-- 
cgit v1.2.3