Quality Assurance


When I got hired at CVS I was put in a unique position because they hadn’t had a QA Specialist before so I had to make it up and learn from the UX Leads who had some knowledge of Quality Assurance. My job was to make sure that the new sections of website that the UX Leads were designing got implemented correctly by the developers. So now for this Case Study I have broken down the Quality Assurance process into three main steps with several smaller steps within them, as you can see from my info graphic above. The first step in the QA process is to go over the projects wireframes, Visual Design Specs and HTML Prototypes and learn the projects visual look and functions. Then once I had done that I would go into the test environment for that particular project and start looking for any visual or functional defects. I had to have a eye for detail because defects could be anything form the font size being incorrect, the spacing off between elements on the page or something as small as a phone number being incorrect on a page. Also, during this phase I would look for test for defects in multiple devices (Desktop, Tablet, and Mobile) and also test in multiple browsers.


The next step in the QA ┬áprocess is to compare the defects I had found to the Visual Designs Specs, Wireframes, or Prototypes. First I would take a screenshot of the defect then take a screenshot from the VDS, Wires or Prototypes and go into Adobe Photoshop and point out the defect and annotating what should be done to correct the defect. Sometimes I would do this with Photoshop other times if requested by a Project Manager they might had wanted me to do so in a PDF or Word Doc, but the majority of the times I would do this in Photoshop. I would also at times use the Google Developers tools to check the code for proper pixel size and color hex codes. I would also use the Google Developer tools to make adjustments to the code to make suggestions to the developers to speed up the QA process. The point of doing this step of the QA process was to show the developers what the exact problem was with the test site before project went live. Usually there would four to five phases of any given project for the development by IT team after it was visually designed by the UX team. The development phases went as followed Build, Quality Acceptance, User Acceptance, Warranty and then the project went live on the current CVS site. I would do QA during the Quality and User phases pointing out most of the defects during the Quality phase and some during User phase while also doing pre-made test assigned to during the User phase. Sometimes defects would make it to the warranty phase which was the last phase to get any defects or functionality problems fixed, but most of the time it didn’t come to that. Because the developers wanted to make sure they fixed all the defects before this phase. If there was no defects or functionality problems during the beginning warranty phase then it would get approved and go live.

Log and Communicate

The next step in the Quality Assurance process was to take the screenshot of the defect I had annotated and Log it into Quality Control (QC) a software program that tracked the defects found by myself, developers and other testers assigned to a project during the QA and UAT Phases. Once I logged the defect into QC I would assign it to the Lead Developer and then they would later assign to one of the junior developers to fix it. When I logged in the defect I would attach the screenshot, give a detailed description of the defect and fill out other necessary fields, such as the severity of the defect. Defects would normally get fixed by the order they were logged in or by the severity of the defect, functional defects were usually ranked highest. QC was a great way to track the defect because it kept everyone involved with that defect accountable and QC generated an automatic email to me every time it was commented on the defect or if somebody changed its status from open to fixed or postponed.

Then once the defect was logged in the developers were notified due to me assigning it them. Now it was time to notify the UX Manager, UX Leads and Project Managers and tell them how many defects were found. Also at this point there was usually a daily Triage meeting that would have kicked off at the beginning of the project phase (QA, UAT) I would be in on these project meeting and I would usually be the only one representing the UX team. Sometimes our project manager would sit in on the meeting, but most of  the time it would only be me. So this is where we would discuss the defects look at them and determine when they would get fixed. From these meeting I would take the meeting points from the defects I had found and communicate what was happening with them to the UX Manager, UX Leads and Project Manager.

So once the defect was fixed by the developers they would change the status of the defect in QC and I would get a email notifying me that it was fixed and ready to be retested. I would then go and check the test site and see if it was addressed. If it was fixed I would go back into QC and close the defect if it wasn’t I would reopen the defect and the developer was notified. I would also send the developers an email to follow up on it and CC my project manager and UX Lead in the email notifying them and to make sure that the defect would be addressed. Lastly, I would meet with my UX Lead on the project to update them of what the status of the project was and If I needed them to interject if things were not getting addressed quickly enough. Usually the project manager would then make sure that things got squared at this point.