BluePrint: Destructive Testing of Sahana Eden Modules

Introduction

Destructive testing means to test the response of the system to user errors for consistency. When the user performs invalid actions, the system should:

• respond with a proper error message or, where suitable, correct the user's mistake (if the user's intention is clear)
• prevent any unintended data loss or exposing of data for unauthorized access
• give information how the user can do it right (if the user's intention is clear)
• allow the user to resume the normal workflow, or if necessary, to return to the previous stage

The primary goal of the test is to find situations where the user can accidentally loose data or expose them for unauthorized access, or put the system into a state where it is impossible to resume the normal workflow. It is *not* the primary goal of the test to find bugs (=wrong response to right user action) but to confirm a proper error handling (=right response to wrong user action)

The test method is to intentionally perform everything that the user could do wrong, misunderstand or forget when performing a regular user task (e.g. input of invalid values or no values where values are required, clicking on UI elements that are not meant to be clicked on, or unintended navigation actions like clicking the "back" button, bookmarking invalid URLs, and so forth) and document the systems response to the error.

It is important that the test targets "regular user tasks", i.e. the intention of the user must be part of the expected workflow, just actioned the wrong way, and also that the user's mistake has an actual (not potential) consequence on the data integrity or workflow. That means, if the user puts in values in wrong syntax, and the system is able to still save the right values in the record, then that is not an inconsistency but tolerant behavior. If though the user puts in values in wrong syntax and the system saves a wrong value, then that's a bug. And of course, no user action should ever lead to a HTTP 500 "Internal Server Error" (whereas other error messages may be a proper response to the user's mistake).

Ideally, any error messages should:

• name the action that lead to the error
• explain the cause of the error
• explain the consequences of the error for the user action
• explicitly state the impact on data integrity, if any (e.g. "Record has not been deleted")
• where suitable, suggest what the user could do to
  • resolve the cause of the error (e.g. "Please contact the system administrator to ...")
  • mitigate the impact of the error (if necessary)
  • continue with the task the user was going to perform

This BluePrint shall document the procedures for a systematic destructive testing of a particular Eden module, with focus on "systematic", so that the testing covers as many possible user mistakes as possible, and in a way that the test cases can be easily reproduced for any Eden modules.

From this BluePrint, we want to be able to implement a standard testing procedure for Eden releases.

Typical User Mistakes and their Priorities

This section shall document any knowledge about typical user actions and mistakes, and their relative likelihood (=priority).

1. Accidentally at times numeric data gets filled in text fields

2. User should be warned if caps lock is ON

3. Field's like description should have a maximum length specified.sometimes if its not specified, the data gets truncated.

General Testing Method

Functionality Testing

1. Test the outgoing links from all the pages

2. To Check Import and export functionalities are working properly

3. Browser compatablity shoud be checked for various errors.

4. Test by pasting internal url directly into browser address bar without login. Internal pages should not open.

5. If you are logged in using username and password and browsing internal pages then try changing url options directly.

6. Any form when opened in a new tab should be successfully filled and submitted

7. Check if e-mail sending works properly.

Form Testing

1. Each form should have at least one required Field validator

2. The field like names should not allow one to enter numerical values or any space

3. Sorting functionality in forms should work properly.

4. Different filters should work properly

5. Start dates should never be greater than the end date.

6. Automatic in line tool-tip should appear on the left of the text box while its being filled

Examples of Test Cases

A good example of destructive testing is http://eden.sahanafoundation.org/ticket/1076 . This describes the systems response to an unintended user action (opening a popup link in a tab via right-click instead of left-click to open the popup) - and how it could go wrong (the user cannot resume the normal workflow).

File uploading

In the HRM module for importing files , when a user selects a file it starts uploading a file without making a prelimenary check of the file extension . If the file extension is wrong . Thus a lot of user , time and resource is wasted in uploading the file if a wrong extension file has been chosen by mistake because an error message occurs only after he clicks the submit button.So a client side check of the extension of file should be performed.

​http://demo.eden.sahanafoundation.org/eden/hrm/human_resource/create?group=staff , in this when one enters an organisation mane , if that doesn't already exist in the database, then it simply clears whatever has been entered by the user without showing an error message “This organisation does not exit.Please add it ”. This confuses the user.

Unable to send notifications ​http://demo.eden.sahanafoundation.org/eden/hrm/human_resource?group=staff Here when one tried to send a notification , one is unable to edit the recipient field and when the send button is clicked , an error message comes up “Please enter the reciepient”.

Start Date should be greater than the End date

No error is shown here in this form when one enters a start end later than than the end date ,which is logically incorrect. ​http://demo.eden.sahanafoundation.org/eden/hrm/person/6/human_resource?human_resource.id=1&xsltmode=volunteer

Requirement of Other option in Home drop down menu

It is possible that the one’s home country might not be available.So one should have an option of other

Important fields should have a required field validator

sector field should have a required field validator Practically a Name shouldn’t start with a number but its allowed in the sector field.

First Name

The first name would consist of a single word so no spaces should be permitted in this column.

View

When applying different filters, view should not change if all items are already being currently displayed as reported in the ticket http://eden.sahanafoundation.org/ticket/1062

At least one Required Field Validator should exist in a form

In adding a certificate ,the add certificate does not consist of a required field validator(​http://demo.eden.sahanafoundation.org/eden/hrm/course_certificate) .As a result blank entries get entered into the database.

References

None

---

BluePrints BluePrints