Testing Process
Testing Preparation
·Get the requirement document in place. It can be similar to the Release notes. But there should be one document for all the requests for that release which consists of new functions & JIRA items.
Comment: For developer, please create the JIRA ticket for any new requirement, the requirement can come from Email, Oral statement in meeting and so on
· For all the request get the GUI design aspects (if it’s a GUI change, get the sample GUI – which normally shared in Sharepoint->requirement->zipped file with different screen layouts).
Comment: During analysis, developer can first have the UI template and review them with QA, for example, QLS admin
· For all the request get the DB design aspects (This is missing so far. Every JIRA item has to have this. If it’s a new requirement from Ben, business let the schema, tables etc of the design be available from DEV.
Comment: Developer should comment the JIRA ticket for DB change when to "Development Complete" the ticket
· Based on the above, prepare the test cases & for traceability specify the JIRA ticket number or if its new request specify some reference for this & where the requirement is available.
Comment: For developer, please upload design document to Sharepoint
· Circulate an e-mail with test cases for every one’s review with a link to requirements, design
· If any question, clarification on test cases, Dev team will answer, comment & test case to be updated accordingly. & finalize the test case. Share it in Sharepoint & is version controlled.
QA Testing
After the QA environment is ready, the developer should do following:
1. Send out the email saying the QA deploment is finished with all JIRA items
2. Assign the JIRA tikets to QA and change the status to "Pending QA", the QA only tests the ticket which has been assigned
There are two cases when the application is released to QA environment:
Case 1: Complete development is done & released to QA.
· Circulate an e-mail saying QA release based on requirements/functions Tested, test result, issues (JIRA tickets).
· If there are fixes & retest done, circulate an e-mail saying Fix release for issues identified in QA, test results, further issues if any or if no issues, then say QA completed successfully with all the known issues listed, retested & marked as pass.
Case 2: Partial development is done (say 70 % & 30 DEV is still happening) & released to QA
· Maintaining a list for QA Release 1 functions from the requirement document, make a QA Release 1 with only those 70% requirements & when you complete the testing for these 70%, circulate an e-mail saying QA release1, requirements/functions ready for Test, test result, issues (JIRA tickets).
·Let’s say, next release they make with 20 % of the 30% pending requirements and some fixes for the QA release 1, then on completing testing on these, circulate the QA release 2 with list of requirements, functions tested, issues retested, test results.
And so on with QA release 3, 4, etc .
·If for some issues, DEV says, this will be addressed in future release, Let them comment the JIRA items accordingly.
So on the final QA release e-mail you will circulate the complete requirements tested, test results, issues (take a list from JIRA) which are fixed, postponed for future release and say QA Signoff : with what are pending items, which are postponed.
UAT Testing
·There cannot be any new requirement coming in at the beginning or during UAT testing. Only bug fixes are allowed.
·For any product/project release (be it SSA products or IR3 ) , let’s get the user/business signoff for “User acceptance Test”.
·After UAT testing is completed, circulate the complete test cases, test results, issue list, retest status & say UAT completed. If something is not tested, clearly indicate what is not tested & pending.
Production Verification:
· After the PROD deployment, when you complete the verification, send out an e-mail indicating what were checked in PROD and are they fine or not.