QA Improvement - Path to Success

Session 1

Wajid Hussain

Wajid Hussain
Agenda
1. Objective
2. Introduction
3. Client Expectation

Wajid Hussain
What is QA?
• Product should do the same as what is expected to do
• Meet the acceptance criteria
• Fulfills client requirements under description of a PBI
• How we can estimate the scope of testing?
• How do we know/see the impact?
• Where is the usage of a developed item.
• How to control the missing elements?
• Engage with clients in requirement meetings
• Knowledge?
• Try to cover client’s requirement before to start developing
• WHAT IS THE PROBLEM?
• WHY WE FACING THIS PROBLEM? AND IDENTIFY THE ROOT CAUSE?
• Time constraint for QA?
• Engagement of QA with PO.

Wajid Hussain
Client Expectations
1. Working Software
1. New Feature Should Work
2. Existing Features Should Work

2. Minimal Time to Perform UAT

3. No Surprises
4. No Bugs

Wajid Hussain
Execution: Package Delivery
1. Backlog Management
• Detail Oriented + DoD
2. Quality Assurance
• Processes
• Manual Testing: Write test cases
• Automation: Automate test cases
• CI/CD: Create pipeline from day 1
• Continuous Improvement (Feedback)
3. Production Support
Wajid Hussain
Target: ZERO bug should report on UAT?
- Ensure deployment on UAT
- Environment configuration in a QA document
- Use a mature deployment method to ensure successful deployment on UAT via CI/CD
- Monitor and control deployment on the QA environment
- DB schema/data
- Compare QA/UAT schema
- Compare configuration data on QA/UAT
- Web/App deployment
- Code deployment same QA/UAT

- Test execution against the scope

- Identify the scope of a PBI
- Find impact -> dependency of one item to another item
- List use cases of a PBI
- How to identify use case? Requirements (PBI, acceptance criteria)
- Product Knowledge -100%
- Challenges
- Developer enforces QA for restricted QA
- Information access restriction
- 90% (3)
- 70%-90% (1)
- 50% - 70% (2)
- < 50% (1)

Wajid Hussain
Test Cases???
1. What is? What will be the out with the given input. -> Acceptance criteria of a user story
1. Test Scenario: Single line
2. Test Cases: Detailed with multiple cases
1. Environment/Precondition
2. Input value
3. Output value/message
4. Where to check it
2. How to write?
3. Where to write?
4. How to manage?
5. How to ensure execution?
6. Test report
7. How to accept the reason for a reported bug and improvements
8. Difference between bug and observation
9. Manual testing techniques
Wajid Hussain
Challenges to writing Test Cases?
1. Time constraint
2. Didn’t plan on time
3. Unplanned items to test during a sprint
4. Tool is taking time to create test cases
5. Resource Shortage/Need Multiple resources
6. Not taking/defining action items after backlog refinement/grooming
7. Change in scope during sprint execution

Wajid Hussain
Challenges to writing Test Cases?
1. Time Constraint:
1. Raise the challenge with stakeholders during a sprint
2. QA should define time to fulfill their needs
3. QA input is required to plan a sprint to meet quality
2. QA should be a part of solutioning sessions
1. Shift left strategy
3. Didn’t plan on time
1. Need to execute all sprint events on a scheduled time
4. Unplanned items to test during a sprint
5. How to share an estimate of production defects?
1. Lifecycle of production defects
1. Production defect reported
2. Bug Triage – Investigate L1 – [Product Team – PO, PA]
1. Is this really a defect or not?
2. What is its severity?
3. RCA – Root Cause Analysis – [QA]
4. Plan its fix – [PO, QA, DEV], Final approval Customer
5. DEV
6. QA
7. Rollout – HotFix –
1. On Production Branch
2. Merge the current sprint branch for QA
6. Tool is taking time to create test cases
7. Resource Shortage
8. Test cases should be reviewed by someone else
9. Not taking/defining action items after backlog refinement/grooming
1. Participate in backlog grooming sessions and define use cases at end of the meeting
10. Change in scope during sprint execution
11. Need to spend time on the last deployment for which no dedicated time is allocated
1. Need to allocate time for it

Wajid Hussain
How to write a Test Case?
1. Step 1: Test Case ID
2. Step 2: Test Description
3. Step 3: Assumptions and Pre-Conditions
4. Step 4: Test Data
5. Step 5: Steps to be Executed
6. Step 6: Actual Result and Post-Conditions
7. Step 7: Pass/Fail

Wajid Hussain
How to write a Test Case? Challenges
1. Time constraint
1. Load
1. Resource shortage
2. Over commitment from QA
1. Better plan before commitment
3. Stretched sprint goals
2. Tool
1. Need to use the same tool in DPL

Wajid Hussain
How to write a Test Case?
1. Step 1: Test Case ID -Test cases should all bear unique IDs to represent them. In most cases, following a convention for this
naming ID help with organization, clarity, and understanding.
2. Step 2: Test Description - This description should detail what unit, feature, or function is being tested or what is being verified.
3. Step 3: Assumptions and Pre-Conditions - This entails any conditions to be met before test case execution. One example would be
requiring a valid Outlook account for login.
4. Step 4: Test Data - This relates to the variables and their values in the test case. In the example of an email login, it would be the
username and password for the account.
5. Step 5: Steps to be Executed - These should be easily repeatable steps as executed from the end user’s perspective. For instance, a
test case for logging into an email server might include these steps:
6. Step 6: Expected Result - This indicates the result expected after the test case step execution. Upon entering the right login
information, the expected result would be a successful login.
7. Step 7: Actual Result and Post-Conditions - As compared to the expected result, we can determine the status of the test case. In the
case of the email login, the user would either be successfully logged in or not. The post-condition is what happens as a result of the
step execution such as being redirected to the email inbox.
8. Step 8: Pass/Fail – PASS/FAIL
Wajid Hussain
Wajid Hussain
• Test Cases:
• Review PBI to create their test cases
• Ensure that Acceptance criteria should be defined for a PBI
• If acceptance criteria are not defined,
• Talk to PO to define it otherwise my test cases will miss the requirement/scope
• Ensure my test cases have covered all acceptance criteria
• Follow all 7 steps which we discussed earlier
• Attached/Link each test case to the relevant PBI
• Perform the test steps.
• Verify the test results as per the defined expected result
• If the test is passed:
• Mark the test case as passed.
• Stop the test.
• Add/update relevant information to the test case and PBI
• Process completed.
• If the test is failed:
• Mark the test case as failed.
• Add defect with steps to reproduce, support images, video, content, etc.
• Log the bug and assign the sprint and the team.
• Add/update relevant information to the test case and PBI
• Assign back the PBI to the developer
• Process completed.
• PBI will be assigned to PO for UAT approval.

Wajid Hussain
How to Identify the Number of Test Cases to be written?
Real Scenarios from the existing project?

Wajid Hussain
Different Types of Test Cases
Test cases can measure many different aspects of code. The steps involved may also be intended to induce a Fail result as
opposed to a positive expected result such as when a user inputs the wrong password on a login screen.

Some common test case examples would be the following:

Wajid Hussain
Performance Characterization – Breakpoint of our application(s)

A messaging system can be judged on its performance in four aspects—scalability, availability, latency, and throughput.
These factors are often at odds with each other, and the architect often needs to figure what one aspect to compromise to
improve the others:

• Scalability: This is how the system is able to handle increases in load without noticeable degradation of the other two
factors, latency or availability. Here, a load can mean things such as the number of topics, consumers, producers,
messages/sec, or average message size.

• Availability: In a distributed system, a variety of problems can occur at a unit level (servers, disks, networks, and so
on). The system's availability is a measure of how resilient the system is to these failures so that it is available to end
users.

• Latency: This is how much time it takes for a message to get to a consumer from a producer.

• Throughput: This is how many messages can be processed per second by the messaging system.

A classic tradeoff is between latency and throughput. To optimize throughput, we can batch messages and process them
together. But this has a very negative effect on latency.
Wajid Hussain
How to write a Test Case?
1. Step 1: Test Case ID
2. Step 2: Test Description
3. Step 3: Assumptions and Pre-Conditions
4. Step 4: Test Data
5. Step 5: Steps to be Executed
6. Step 6: Expected Result – Where to check it
7. Step 7: Actual Result and Post-Conditions
8. Step 8: Pass/Fail
Wajid Hussain
 Definition of Done
We as a scrum team need to ensure to comply the following definition of done (DoD) for each PBI

[ DEV ] Acceptance criteria met

[ DEV ] Unit tests passed (Pre-Req: Unit test created)
[ DEV ] Code reviewed and checked-in (Pre-Req: Code branch created; PR generated)

[ QA ] Acceptance criteria met

[ QA ] Regression tests passed (Pre-Req: Test cases created)
[ QA ] Functional tests passed (Pre-Req: Test cases created)
[ QA ] Non-functional tests passed (Pre-Req: Test cases created)
[ QA ] No showstopper bugs

[ PO ] Acceptance criteria met

[ PO ] No showstopper bugs
[ PO ] Accepted by PO (when PO doesn't mark it Done himself or herself)

Wajid Hussain
 QA Expectation
We as a scrum team need to ensure to comply the following definition of done (DoD) for each PBI

Wajid Hussain
Thank You

Wajid Hussain
Wajid Hussain