1. An overview on the processes to perform
Maintenance QA for Citi
2.
3. MRFs
– MRFs are triggered when either a partner or someone within the organization finds a discrepancy on the retail partner pages which
requires correction. It can also be created when the retail partner desires to implement new features or change the ones already in
production.
– There are three types of MRFs:
• The ones that are content only handled by CMS
• AMS (Approval Management System). This is for the Sears marketing page.
• IT which requires code change.
EMRFs
– These are very similar to the ones above with the exception on the implementation time. The “E” stands for emergency which changes the
dynamic and flow of the MRF as it needs to be implemented in the next possible release. As there are several people involved in this type of
request; the communication and coordination of all parties is vital to complete the task properly.
TRs
– A TR can be opened at any time, but usually they are open on implementation day or few days later when an issue is found. These are
categorized by severity.
4. Documentation, assets, and scheduling
– Once the document is created, it is send to the production support team who will start assemble the assets required (images, URLs, legal
sign off, translation, and screenshots) for its implementation.
– A meeting will be held to determine which would be the most available release to implement the MRF.
– Teams like CMS and IT will be engaged to start working on the changes requested.
– At this point the tester can start looking at the assets to analyze the request and secure test accounts, conditioning, or test data.
– Tester is also responsible to supply the VA team with accounts for their own testing.
5. 1st Round of testing
– The production support specialist would communicate to the tester when the MRF is ready for testing.
– Tester would verify the server to be used depending on the type of MRF ( UATxx, BAU, content dropbox and checkbox, or jvssdz0xx)
– If defects are found during this stage, the tester would send those to the CMS, IT or AMS person in charge to complete the fixes.
– Tester would also support VA testing in case they need orientation or extra test accounts.
2nd Round of testing
– Once defects are ready to retest, the tester will go ahead the revalidate and approved if that is the case.
– Screenshots are taking at all times reflecting the date to avoid any conflict.
6. Implementation
– Tester is responsible for defining which MRF can be PRVd. A list will be delivered prior to implementation weekend with the list of MRFs
– On implementation day, tester would verify in production once is advised by release managers.
– Tester will reply to the distribution list if the MRFs are approved or not. He/she will also send screenshots when an issue is found, and wait
for confirmation for retesting.
7. Deliverables
– Tester is responsible for taking screenshots during both UAT and PRV stages. Those should be uploaded to their respective folder within the
Maintenance SP.
– Power Point is the tool used to save the screenshots.
– Maintenance log should be updated regularly with the MRF’s status.
