Wednesday, November 27, 2019

Defect Triage

Defect Triage is process of determining the priority of a defect based on their severity. Severity is raised by the software tester. A decision on priority is made collectively in conjunction with the Product Owner. 

1. Is this a valid bug?
2. Is this bug reproduceable?
3. Is this bug worth to fix in the present sprint / can it be deferred?
4. If it has to be fixed, then When? 


Defect resolution in TXS, sample user story

  • Acceptance Criteria was written for each user story in the BDD format (Given - When - Then).
  • Testers wrote Functional tests based on the acceptance criteria. 
  • Developers wrote code for US, unit-tested the code, uploaded the artifacts in Pega.
  • Testers ran the functional tests, logged defects / findings.
  • Testers ran Defect Triage. 
  • Defects categorised, prioritised and the fixed. 
  • Defects re-tested and closed.
Sample User story with Acceptance Criteria.

Business Scenario

Toyota customers will get Toyota personalised interest rates Online for New Vehicles they are interested to finance which can be used by contacting toyota dealerships for Quote/Application processing. 

Description

As a Digital Marketing Manager

I want online guests to fill an online TXR form which will collect their personal information
so that TXS can offer them personalised rate based on their credit score / risk based price rate.

Acceptance Criteria #1- Create TXR Case

Given a request to obtain customer TXR is recieved 
When BOOMI triggers request TXR service call
Then Create a TXR case which is associated to customer record
AND all the information associated to TXR request should be recorded
AND Expiry of TXR case should be same as Credit score validity 

Acceptance Criteria #2- TXR case_Error Handling

Given a request to obtain customer TXR is recieved 
When TXR case creation failed 
Then Error message should be sent to BOOMI about transaction failure 

Technical Details

1. Create Case Type 
2. Create Case Fields and skeleton 
3. Create Case stages 
4. Define case Status (Open, Resolved - Expried (When credit score is expired))

Data from TXR online forms and additional details will flow from 
T-Bone--> BOOMI--> Pega

First Name
Last Name
DOB
DL#
Address  with Sensis SA1 value
Contact details (email, telephone)
Marital status
Residential ownership
Co-applicant Y/N
Consent to obtain credit score
Vehicle Details
Dealer ID
GUID

(Above is not the entire list of fields and there are more fields expected as part of Create TXR service call) 
- Complete list of fields from TXR call are covered as part of US-2783

Dependency 

Awaiting sample request XML from BOOMI

1. Field Mapping across systems ( T-Bone -> BOOMI -> Pega)
2. Request authentication 

Assumption/Facts

* All field validations to be implemented at T-Bone end (pega validations list to be provided) 
* TXR requests are applicable only for individual borrower types 

Defect severity and priority

  • Priority of a bug is the urgency of need to fix the bug.
  • Severity of a bug is the impact it has on the system
Severity
--------
S1 - Critical: Defect affects critical functionality / data. No workaround.
S2 - Major: Defect affects major functionality / data. Has workaround, but is difficult / complicated.
S3 - Minor: Defect affects minor functionality / non critical.
S4- Low: Does not affect functionality or data. No need for a workaround.
S5 - Cosmetic: Defect affects only the look & feed, but not the functionality.

Priority
---------
P1 -- High: Defect must be fixed ASAP.
P2 -- Medium: Defect can wait until the next build / release.
P3 -- Low: Defect can be deferred until a more serious defect is fixed. 

Airbus - HP Quality Centre 9.2 Central Administration


Software Bug Lifecycle

In TxS, the lifecycle was simple:

1. New
2. Open
3. Assign
4. Fix
5. Reassign
6. Resolved-Closed



If we already have automation, what's the need for Agents?

“Automation” and “agent” sound similar — but they solve very different classes of problems. Automation = Fixed Instruction → Fixed Outcome ...