4 Values and 12 Principles of Agile

Fields in a bug report

Fields of a bug report

1. Bug ID

2. Bug description and what happens

2. Steps to replicate

3. Where the bug is noticed ( module, page etc.)

4. Severity of the bug

5. Screenshot

6. Bug raised by (Tester).

Process to create test scripts...

• Get a thorough understanding of the application under test -- either through documentation, or from BA/ product owner or the team. 
• After an understanding of the application and the requirements, identify the scenarios/ risk areas which then give an idea of what to test. 
• Once the scenarios are clear, decide on the test cases and test data.
• Write the test scripts
• Get these reviewed
• Executive the test scripts, report bugs.
• Work with Dev team to close the bugs.
• Report on the bugs and closure.

Mortgage Process

Test Process Improvement (TPI)

TPI is owned by Sogeti.

My insurance claims

• Medical Insurance Purchase
• Research insurance options
• Cost benefit analysis based on monthly 
• Apply for insurance online; submit relevant documentation
• Call customer and confirm.
• Review for completeness of documentation, if not request correction. 
• Check eligibility, policy details, benefits, etc. approve / reject application.
• Communicate to customer - send welcome package.
• Arrange for and deduct monthly insurance. 
• Medical Insurance Claim - cashless
• Get docs from doc.
• Submit claim online; submit documentation.
• Review claim and documentation; request further details if required.
• Based on claim type, disease, and the claim amount, initiate cashless.
• If not inform customer of lack of cashless and how to initiate reimbursement with bills.

TMMI

The Testing Maturity Model (TMM) was based on the Capability Maturity Model, and first produced by the Illinois Institute of Technology. [Wikipedia]

Insurance Claim Lifecycle

AirBnB Workflow

Hotel Reservation System - Workflow

WINIT - Web Application Process, Testing

Web Applications -- ASP.NET ; for a couple of Desktop Apps, C# and VB.NET was used.
================================================================

Lakeplace --- booking reservations for small motels near lakes
AAXA ---- Cargo transportation & logistics
Fine Tuxedos -- online Tuxedos sale
Etc.

1. Client interactions / comms -- requirements gathering.
2. Define workflows / business logic
3. Wireframes [sketching, dreamweaver / frontpage, photoshop]
4. Style guide ---
5. Front End design -- ASP.NET, PHP, SQL (Own 3 tier architecture that dev were supposed to follow).
6. Backend Dev
7. Paypal integration
8. UI and Functional Testing
9. Client review every couple of days.

-- No formal test strategies.
-- No formal test planning either
-- Manual testing
-- Write test cases based on workflows
-- Test, raise bugs, get them closed by dev, report bugs
-- Test paypal integration

Paypal Integration Testing...

1. Get details of dummy credit card
2. Checkout button --> Paypal --> Paypal gateway processing --> Back to your website
3. Check for session expiry, session ends.
4. Check what happens if Payment Gateway stops responding.
5. Check for data going to the backend.
6. What happens upon successful transaction -- database, messages, etc.
7. Check receipts are generated and sent to customer email account

Agile Conflict Resolution

Conflict resolution

==============

Telstra

--------

W was a product owner for one of my teams in Media. I noticed that he was increasingly getting himself excused from user story refinement sessions, beginning to withdraw. This was also the time when there were interactions with the senior management in media around team restructuring (feature teams). 

One fine morning W summoned me to his 20th floor office. The moment he saw me, he turned red faced. The moment we went into a meeting room, he blasted me off. For the next 15 minutes he vented his ire. He seemed to harbour a fear that his job is on threat. And that I as an Agile Coach / Scrum Master was conniving with the senior management to throw him out. 

There was a context to this. Telstra was going thru a gigantic transformation exercise. Age old team structures were being taken down to reorganise people into meaningful cross-functional teams. 

I patiently heard W. Apologised to him if there was any misunderstanding. And now that he was at ease after letting himself out, I started putting forward the background of what was happening. 

1. What are your concerns / fear?

2. In your opinion how could we have approached this?

3. Is there a better approach you think could assuage you and other people?

4. Let's agree to a way of communication going forward. I want to be honest with you, and expect the similar honesty from you. 

It was then W came out with the fact that he was caring for a dying mum, and his emotions were getting mixed with the uncertainty times in the office.

After the matter was resolved, an hour later I receive an email where W officially apologised for his behaviour.

Common Agile Metrics

• Lead Time
• Cycle Time
• Sprint Burndown - tells us how much value has been delivered.
• Sprint Velocity
• No. of deployments to prod
• Average time to prod.

DoR and DoD in TxS...

DOR in TxS
==========

1. User stories written in As a < type of user >, I want < some goal > so that < some reason >.
2. Acceptance Criteria written, and in BDD format - Given, When, Then.
3. User stories approved by PO.
4. User stories prioritised by PO.

DoD in TxS
==========

1. Development is complete.
2. Pega unit is complete
3. Code reviewed.
4. Relevant comments and attachments made.
5. Dev QA complete
6. ZSIT / IT complete
7. System Testing complete
8. UAT complete (based on TC provided by business).
9. No open Sev 1/ Sev 2 bugs.
10. US approved by PO.

Agile lifecycle in TxS
==================

1. Discovery workshops to clarify scope.
2. High level Pega estimates by Pega team (Pega Design Council) - Epic level (in terms of both T Shirt sizes and man days).
3. User story mapping and Release planning sessions.
4. Sprint Planning.
5. Daily standups, Refinement sessions (Every wednesday), Sprint Review (Fri 3pm to 4pm), Retro (4pm to 5pm).
6. Scrum of Scrums [TxR Upstream and downstream] daily 9:45am, standups daily 10:15am to 10:30am.
7. Release Train Scrum of Scrums every Tuesday 2:30pm to 3:00pm.

For Agile Release Train [ART]
======================

o Establish and embed SAFe framework to manage scope, delivery, quality and resources.
o Employ Scrum at team level to reinvigorate team, bring about trust & empathy, transparency and clarity of purpose.
o Coordinate activities in preparation for PI Planning – Backlog with epics, features, stories.
o Coordinate in-PI-planning, dependency management and presentation.
o Plan and coordinate Sprint 0 activities such as initiation, elaboration, architecture, etc.
o Coordinate customer journey mapping and User Story Mapping
o Help team in defining MVP, Release plan, sprints, etc.
o Facilitate sprint planning, daily stand ups, Sprint Review and retrospective.
o Managing program board, dependency management with stakeholders.
o Stakeholder communication, management reporting, etc.
o Manage team conflicts, challenges; escalate where necessary.

Personalised Rates Workflow

Root Cause Analysis ( RCA )

RCA comprises the techniques and tools to uncover the underlying causes of problems. 

• Most common is 5-Whys?
• When you have a vast amount of data:
• Do a 80-20 Pareto chart to identify the 20% causing the defects.
• Do a 5-Why on the 20% based on the defect categories.
• Fish Bone / Ishikawa Diagrams

* Images may be subjected to copyrights. I don't hold the rights.

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

V Model - Classical Lifecycle

• Requirements Analysis -- Business requirements document or business requirements specification
• System Design -- Systems requirements specifications / functional specification
• Architecture Design -- High level design
• Module Design - Low-level design

Shift Left (Courtesy BMC)

Shift left is a software testing approach where software testing is performed (moved or shifted) to the left / earlier in the Life-cycle. This basically is "Test Early and Test Often".

• In the Traditional Model, requirements and design happen to the left, and testing of those requirements to the right. As the project progresses, the testing effort increases. 
• Consequently later the defects are found, the costlier it becomes to fix those bugs

• In Shift Left, testing is performed during early stages by engaging early in the project lifecycle. 

JavaScript Object Hierarchy - CERN European Particle Physics Laboratory

TXR Test Planning & Execution

7 Principles of Software Testing...

Leadership coaching skills --

As a coach, you should be:

Tools for retrospectives

1. Confluence
2. Funretro.io
3. Mural
4. 
   

Who kickstarts Agile Transformation defines it's success!

Usually the Executive 

Coaching vs. Consulting... Mikhail Stepanov

Prioritising Requirements

• Kano Model
• Priority Matrix

Moscow Model

Pega Case and Case Types

Pega Case

Pega Case Type

Case Lifecycle Design Model

The Iron Triangle

Agile Project Management -- when Agile projects are constrained by all the three parameters -- Cost, Time and Scope. 

Sayings about Culture...

• Culture is what happens when you are not looking.
• When you see something that is below standard and do nothing, then you have set a new standard.

Dimensions of Trust - Seapointcenter.com

SAFe Requirements Model... (Source: SAFe Agile Portal)

Sample Epic, feature and US

Campaign management -- Epic
==========================

Features
========
1. Set up campaign
2. Run campaign
3. Gather campaign stats

User stories under set up
======================

Create campaign specific to MDA brand
Review and publish MDA brand campaign requests

============================================================
============================================================

Create ZS pega sales portal [EPIC]
=============================

Features
========
1. Create base portal
2. Portal delta (set of additional features)

Stories under base portal
=========================

1. Set up base portal from Quantum

Stories under Portal delta
==========================

2. Ability to select MDA fin options for trade-in details
3. ZS provision to capture 3rd party supplier details
4. Update TSS field reference

Lean startup - Image (Dave Landis)