The document outlines the Agile QA process, emphasizing the importance of early QA involvement in requirements and active participation in daily scrums to ensure quality under tight deadlines. It details the collaboration between QA and development teams, including effective bug handling, root cause analysis, and the inclusion of test metrics in project reviews. The need for automation in builds and a focus on both exploratory and negative testing to enhance software quality is also highlighted.

1. Agile QA Process
-Ashish Agrawal

2. Problem Statement
• With agile model driving software development process and tough
customer deadlines keeping pressure on teams, how does the QA
team ensure quality.
• What model should QA and dev team follow to help each other in
quick resolution of issues
• How development engineers can assist QA team

3. Requirements
• Involve QA team early in the requirement process
• QA team to find gaps in requirements and prevents them from
becoming open issues
• QA team should participate in daily scrum and planning meeting and
raise queries early in the cycle
• Understand “testability” of requirements, How requirements can
change/evolve over time and create test plan

4. Release and deployment process
• At the start of the project, agree with dev team for the process and
schedule
• Dev team should Include release notes that contains info about new
features, bug fixes, known issues, and any special information that is
important to note for testers
• Builds with known blockers will not be accepted for testing
• Any servers to be deployed with the test builds will be under QA
control for the duration of testing
• Important to include unit test results as part of release notes

5. Bug handling process
• Regular f2f meeting with PM/Dev/QA team to discuss open issues
and decide on validity , priority and estimated completion time of
bugs.
• Everyone to update tickets they are assigned to, and be aware of
response times (as per test plan)
• Resolved tickets must include info about the fix, impacted area
• Blockers/showstoppers should be reported asap by QA team

6. Reporting
• QA to provide test metrics as per agreed in test plan (eg. per sprint,
release, etc.)
• QA to discuss with PM/Dev about what metrics are important to
report (eg. test coverage, pass/fail rates, compliance matrix, open vs.
closed, priority/severity, etc.)
• Project closing review, QA to provide overall testing picture (ie. stats,
summary of tested areas/features, etc.)

7. For development team
-Root Cause Analysis
• The objective of fixing bugs should not only be to resolve the current
bug but also making sure that no new bugs/breakages are introduced
• While moving a bug into resolved state, developer should fill and
publish root cause analysis and unit test document

8. Root cause analysis document
What is the reason for this bug/feature. Choose one.  New feature
 Incomplete Requirement
 Requirement change
 Design Flaw in architecture
 Code issue
 Missed in code review
 Reopen/breakage
Did you perform unit testing before committing fix for current issue
Mention what positive and negative unit test cases have been performed
before committing the code
Have you performed all validation? Correct and Incorrect input which user
can give and it should be handled gracefully with appropriate error message
Have you testing final changes on tablet (touch device) on both portrait and
landscape mode.
Have you verified after functionality which might be effected by your
change.
What the code reviewed before merging and by whom
How many review comments were given during code review
Did you check that no performance impact on the application after your
changes
Have you confirmed that your UI changes matches completely with required
UI. Icons, Color, Font, background etc
How many lines of code changes done to fix this issue/feature
What is the root cause and what fix is given to resolve the issue. explain briefly

9. What else…
• as needed, there should be one sprint devoted to bug burn-
down/stabilization
• if dev team can ‘guarantee’ that features are working correctly (ie.
basic happy flow), then QA team can devote more time to exploratory
and negative testing to root out the bugs
• have an automated build/deployment tool (eg. Jenkins) for console
builds. Everyone can see what/when/where a build has been
deployed

10. Thanks ….
Contact me: meetashish@gmail.com