“Program testing can detect the presence of bugs, but not their absence.” – Edsgar Dijkstra

The testing of any software finds bugs, and requires bug reports to be filed. Most fresher-testers and computer science graduates are unaware of the ins and outs of this activity. The question is not simply that of getting the info across, but it involves a technique wherein you have to be farsighted and think of not only the maintenance engineer, but also of the immediate sets of regression testing that will follow.

Hence it is important that bug reports are systematic and complete and as thorough as possible.

Fact: The summary line of the bug should contain as much primary, relevant information as possible.

Sample: “When data is sent, there is an error message.” Correction: “When a … message is sent from the EA STA, the CSG responds with the message: …”.

Fact: The keywords field is very important for searching for bugs belonging to a particular category. Most newcomers are unaware of how this field is useful, nor what to put in it. ‘Keywords’ refers to the important words in the Summary line or the body of the bug report, which indicate which module caused the error, what type of error it was, what testing phase it occurred in, etc.

Example: The Summary line says: “On Warp Windows, while browsing for a destination folder, the new folder created using the ‘New Folder’ button cannot be used.” (This is a current error!) The body explains that one needs to come out of the browser and re-enter it to select the New Folder created earlier. This is an easy work-around, so the bug is of low severity(SEV4) and is also of low priority (PRIO3).

In this case, the keywords field will contain:

Keywords: Phase4, SEV4, PRI3, Warp Windows, Destination, folder, browsing, new folder.

Use: Now, when one asks any of the following questions (search criteria) our bug will be selected:

• Give all bugs related to the destination field.
• Are there any bugs filed for the ‘New Folder’ option? (Bugs found to satisfy this query can be searched to see if a duplicate bug is being filed. Preventing Duplicate bugs is a very important use of the keywords field.)
• Are there any bugs filed for Warp Windows?
• How many new bugs were filed in the Final Phase (Phase4) of the project? (this query is during post mortem, or for statistics-gathering)
• …. And so on.

You will notice that for each of these queries there is an entry in the keywords field which is useful.

Fact: In the body of the bug report, the fresher bug reporter plunges into the problem, without any metadata-details.

Sample: “When I entered the command:…., the response was……”. Correction: In the bug details section, first enter:

• Build Version: Warp Linux 1.1
• Environment: VM running Windows 8, SP1.
• Test case id: WL-434 OR none(It was ad-hoc testing)
• ……

Finally, the STR (Steps to Reproduce):

1. Perform the setup steps( setup # A)
2. Enter the command….

Got the response…

Fact: The STRs (Steps to Reproduce) should be written in imperative form, present tense (do this, do that) and should not be vague (should not contain words like inspect and verify).

Sample: The STR Section…

1. The Setup was done.
2. I inspected the front panel… to verify….
3. I verified that the output contained…

Correction: The STR Section…

1. Do the Setup # A (Test Case # WL-STP-001).
2. Check the front panel….and note the color of the lights….
3. Check that output contains…

Fact: The test cases and the bug reports should be tightly coupled together. Every non-trivial bug should result in a new test case (in the appropriate sub-section) if there is no existing test case for it. Every test case should have the bug number entered in its body. Every bug details section should contain the test case number. This doubly-linked operation is very useful in regression and maintenance testing.

Fact: Instead of explicitly typing STRs, one can more easily and usefully paste the output of terminal sessions, especially in the case of Linux.

The Linux script (1) user command has been provided for this purpose.

A sample linux session is shown below:

$ export PS1=”$ ”

$ script

Script started, file is typescript

$ warp_protect add -d sda2 -f /tmp/bkp

Error 0xabc: unknown system error

$

$ exit

Script done, file is typescript

$ cat typescript >err01. output

Now, the file err01. output contains all the error details printed on the terminal above.  (Note! To exit from script (1), you have to type Ctl+D – which got printed as exit above)