During the early stages of a project when the scope has been agreed, the QA Engineer is included in project specific meetings. This is so the QA can get context of the project and have a deep understanding of the requirements, as well as the client needs. This is an important step as it personifies the Testing phase for the client, as they will have met the QA Engineer, it also gives the QA an insight into how each client functions along with their requirements.
The QA will also be able to ask question during the discovery session in order to gather requirements. These could be for such things as accessibility requirements and supported browsers and devices. We have a large amount of experience In the QA Team to be able to ask questions on requirements from the perspective of the Testing phase. This helps to reduce large problems being uncovered during this stage of the project.
Once the User Stories have been created by the Project Manager, they are reviewed by the QA Engineer. This is to ensure that the requirements from the previous meetings have been aligned with the Client’s expectations. This is also to ensure there are no conflicts within the User Stories, and that there is enough information in each to ensure it can be Developed, implemented and Tested properly.
After the User Stories have been verified, Test Cases will be created for each. Wattle currently use TestRail to create and manage Test Cases.
The Test Cases are manual scripts that run through the successful execution of the User Story. Any defects that are found during testing are opened in Jira as Bugs and are failed in TestRail. The Passes and Fails can be tracked in TestRail for the purpose of Test metrics.
The intention of Test Scripts is to focus the Testing effort, using the specifics of each User story as the Test Criteria, the intention is that these are exported from TestRail and given to the Client as a part of the UAT Process.
The Test Cases are all assigned an ID, which Is added to the ticket In devops. All the Test Cases are exported Into an Excel sheet and handed over to the client for UAT. This Excel sheet contains the IDs of each scripts, so each Jira ticket can be easily tested.
After the initial Development and the deployment to the Development site have been completed, Testing can begin. Testing starts with the Test Cases; each Test Case is run in TestRail with any defects found logged in Jira and that Test Case failed in TestRail. Any Bugs that are found are logged in Jira and linked to the original User Story for visibility and reference. The original User Story will be moved along to the QA Blocked in Jira, but the Linked Bug will be added to the TODO column. User Stories that are ready to be tested by the client will be moved to the UAT column. The Client will be informed when the Staging site is ready for Testing.
The first round of Testing is done using Chrome to establish a baseline for other browsers to be tested against. After the first round of testing has concluded, and all the Test Cases have results associated with them, then Cross-Browser testing can begin. Cross-Browser Testing is performed against the Browser Matrix that is agreed in the project initiation. BrowserStack is used to perform Browser Testing. BrowserStack is emulation software that imitates the behaviour of specific browser and Operating System configurations.
During this period of Browser Testing, Exploratory Testing is performed. This involves Testing the Website or Application without the guide of Test Cases to see how the product reacts in different scenarios relevant to the Website or Application.
After the fixes have been implemented from the first round of Testing and deployed to the Development site, these will be moved over to the Internal Testing column in Jira and retested. Any Bugs that have been raised that have been resolved will be moved to the Done column, any that require further Development work will be moved to the ToDo column. User Stories that have passed Testing will be moved to the UAT column to be verified by the client.
Accessibility Testing can also be performed if specified at project initiation and time allows for this in the project plan. The following Testing tools are used for Accessibility: