The most common complaint while Testing an application and reporting Defects for the defect tracker application was the cumbersome Process adopted in the Testing Process and how a custom process is the need for most App Testers.
The basic requirement in the Testing Process is to reduce the time taken from detection of a Defect to its closure . For instance, while testing a small application a tester might need to adopt a "New Defect" --> "Fixed" --> "Closed" process. Let's call this a "Simple flow through Defect scenario" and in most cases this should do .
Now if we consider a scenario where the teams are working across geographies/locations and it involves a large drawn process involving several sub processes. In this case, there are generally more steps involved such as an indication that Work is in progress and to refrain from testing , Uploads are awaited to fix the defect ,etc depending on the steps involved .
It is clear then , that there is no definite Testing Process which works across all applications/organisations.
Let us now consider how a Business Rule in Wolf PaaS allows us to implement a custom Testing Process.
Let us assume we already have an Entity Defect which has, among other fields ,two fields called Current Defect Status and Next Defect Status.
The Entity Defect basically contains all the information related to a single Defect such as its Severity, the Defects Description , the Application in which it was detected , etc.
Can an Entity called "Status Table" which contains two fields - "Present Status" and "Possible Status".
"Present Status" is analogous to the "Current Defect Status" and "Possible Status" to the "Next Defect Status" of Defect Entity or in other words,what next states of a Defect are possible based on its current state.
For Ex -
Consider a "Simple Flow through Defect Scenario-
The entire process is defined as-
- IF Present State = "New" then Possible State = "Fixed"
- IF Present State = "Fixed" then Possible State = "Closed"
Let us now consider a more complex process in which a "New" Defect can be dealt with in multiple ways . This can be defined as-
- IF Present State = "New" then Possible State = "Retest" OR
- IF Present State = "New" then Possible State = "Upload Awaited" OR
- IF Present State = "New" then Possible State = "Work In Progress" OR
- IF Present State = "New" then Possible State = "Deferred"
Similarly, we define in "Status Table" for each of the Present States what are the next Defect states possible.
Lets call this process as "Status Mapping" and it contains the crux of the Testing Process adopted.
Note- The entering of these values needs to be done via the corresponding Edit Screens related to the Entity.
Once we have completed this Mapping process we then proceed to the Business Rule portion which relates the fields in the "Status Table" Entity to the corresponding fields in the "Defect" entity.
The Business Rule in Wolf Platform as a Service is shown below -
The Business Rule provides the mapping between the "Present Status" --> "Current Defect Status" and "Possible Status" --> "Next Defect Status".
Hence, the entire custom Testing Process is implemented using the Business Rule.
An important advantage of this method of implementing a Business Process is that there is a level of abstraction between the Testing Process and the Defect Tracker Application.
Therefore, if the need arises to change the Testing process it can be done by changing the "Status Table" and the Defect Tracker remains largely unaffected.
Hence any change to the Testing Process, however big or small, does not effect the Defect Tracker application as a whole.
Business Rules are really the muscle of the Wolf Platform as a Service.
Check out the Defect Tracker at :Wolf Solution Gallery