QA Plan

Access Required
1. Jira - read/write
2. Figma - read only
3. API Access - read/execute only
4. DB Access - read only
Tools Required
1. Testing Lab
a. We need devices to perform device-browser combination testing
b. We can use either actual or virtual devices, for virtual we can opt for any provider such as browser stack
or virtual box.
2. Jira
a. Team management
b. Task management
c. Story Reading
d. Bugs life cycle management
e. Reporting - Sprint Reports, Bugs Reports etc
3. Google sheet
a. Test Scenarios management
b. Reporting - Test Scenarios execution, Coverage, Traceability etc
4. Communication
a. Skype
b. Slack
5. Performance Testing
a. Testing team can check the desired application pages manually with the provided loading time.
B.If required we can check the application using open source tools such as Lighthouse
(https://chrome.google.com /webstore/detail/lighthouse/blipmdconlkpinefehnmjammfjpmpbjk?hl=en) ,
GTMetrix tool (https://gtmetrix.com/ )etc and share the reports with the team
6. Accessibility Testing
a. Testing team can check the desired application pages, using an open source tool such as Google
Lighthouse , and AXE tool and share the report with team
7. API Testing
a. As discussed and agreed, QA team will not test API separately
b. The QA Team will still need API read-only access to perform manual checks.
8. DB Testing
a. As discussed and agreed, The QA team will not test DB separately.
b. QA Team will still need DB read-only access to perform manual checks.
Manual Testing Process

1. Requirement Understanding
a. Story Reading
b. Raising concerns, queries and assumptions
c. Write down Test Scenarios in google sheet
2. Stories:
a. We need a status “Ready for QA”, once a story is put in this status QA team will start testing
i. In case the story is not at all testable, bugs will be created and the story will be pushed back to “In
Progress” status with comments.
b. Entry Criteria :
Entry criteria are the criteria or requirements, which must be met before initiating a specific task or a process.
i. Unit Testing is completed by Dev Team
ii. All Dev Tasks are done
iii. Story Status is “Ready for QA”
iv. QA Team will do Sanity Check of developed Story, then decide to carry-on/stop testing
1. If testing has to stop, then QA Team has to perform below actions
a. Report bugs.
b. Add comments on Story mentioning the management and dev team regarding blocker.
c. Management can decide to move the Story back to “TODO” status
v. Once a story has passed the sanity check, QA Team will execute test cases for that, for e.g.
1. Positive flow
2. Negative flow
3. Showstopper
c. Exit Criteria :
Exit criteria are the criteria or requirements, which must be met before completing a specific task or a process.
i. Once All Test Cases are executed and all bugs are closed, QA Team can change the status of Story
from“Ready For QA” to “Done“
ii. Definition of Done
1. Stories will only be marked as done once
a. <number> percent test cases are passing
b. All reported bugs are closed
c. In case bugs are not fixed by dev team, written approval of manager will be needed
to push a story in Done
iii. Demo :- We will have a review meeting with client to discuss about production increment
 1. We wil upload demo video of each task on Jira
iv. Release Plan :- <It is not yet decided>, probably we can create a user manual and share with client, which can
demonstrates, how flow will work, stepwise snips, validations as well.
d. UAT - Client Feedback
i. After a story is given to client, Client can check that on UAT env, and can share their feedback
ii. Feedback will be created as a task and will be linked with appropriate story and epic
iii. Feedback task, will be put in backlog and team can decide when to work on it based on priority and
bandwidth.

Responsive web

1.View Ports 1920, 1440, 1024, 768.

2. Supported browsers

Sr.No Platform Browser Current-Version

Upto May 2021

1 Win 10 Chrome

2 Win 10 Firefox

3 Win 10

4 MacOS 11 Big Sur

5 MacOS 11 Big Sur