This article provides an overview of the roles and responsibilities of a Quality Assurance (QA) Analyst on a project, as well as their involvement in different phases of the project. It explains the mandatory and optional responsibilities of a QA Analyst, such as reporting and retesting bugs, functional testing, regression testing, and preparing testing strategies. The article also discusses the involvement of other project roles, including Project Managers, Solution Architects, Configuration Engineers, and Business Analysts. It outlines the expectations from QA Analysts in various project phases, including sales, handover, foundation sprint, preparation and setup, feature sprint, UAT, cutover, and stabilization.

Topics in this area include:

This is general info about what is QA responsibilities and what can be expected from QA Analyst during the project phases. Also other project roles responsibilities are mentioned here as they were discussed during Competence Leaders meeting.

Roles and responsibilities on the project

Note QA Analyst responsibilities can vary on different projects as sometimes we have lower allocation we would need to do everything we would like to. Therefore responsibilities for QA Analyst are divided into 2 sections - mandatory and optional.

Project phases and QA involvement

Here is an overview of what is expected from QA Analyst on the project. It is mainly focussed on different phases of the project, but please be sure expectations from QA Analyst is also connected with allocation on the project, as all QA work should be billable on the project:

Sales

• nothing is expected from you here to test

• occasionally experienced QA Analysts can be asked to answer some question from the customer - typically about our QA methodology, our tools or about some specific testing scenarios

Handover

• if you are part of handover meeting, your goal is just to listen and get the basic knowledge about the customer and his needs

Foundation Sprint

• During the kick-off meeting be there to listen and gain first information about the project, scope, customer needs, potential risks, customer’s experience in software testing, …

• In case you have an opportunity, check with the customer his view on UAT, and offer him help (test management, reporting bugs, preparing for UAT, tips and tricks are just few topics to discuss). If the customer is interested in some help but you don’t feel comfortable discussing the topic with him, ask your Competence Leader or Principal/Senior QA Analyst for help.

• In case the customer is interested, test automation discussion can start here, even a first Cypress demo can be organized to clarify benefits and answer all customer’s questions

Preparation and Setup

• Start collecting data for testing

• Start preparing test approach based on what you already know about the project - like which modules will be under development, which tools will be needed for testing and administration

• Continue checking UAT with the customer, at this moment it is more about checking the customer is slowly moving to the UAT - like he knows who will test them, which tools will be used, …

• Check if requirements and acceptance criteria are understandable and clear, otherwise clarify them with SA or the customer

• Make sure X-Ray is available and correctly configured for your project - ask your Competence Leader or let PM ask IT via Helpdesk ticket

Feature Sprint

• In case the project starts here for you, make sure X-Ray is available and correctly configured for your project - ask your Competence Leader or let PM ask IT via Helpdesk ticket

• Make sure “Test Plan” and “Test execution“ are prepared for the project. There should be one “Test Plan” for the whole project and one “Test execution“ for every Feature Sprint.

• Prepare test cases (Issue type = “Test“) for every user story, discuss what is unclear with SA, CE or with the customer. Note that everything must be documented in JIRA, you should not have any “secret“ testing files on your computer

  • what to test and what are expected results - the best approach is to use just Description field

  • any important information needed for testing

• Make sure your test cases are properly linked to the correct user stories, Test Plan and Test execution, so it is clear what is being tested on the project

• The functionality should be described as user stories in JIRA, in case something is missing in the description or you need to clarify something before you finalize your test cases, ask your CE or SA. The best way is to do it via Teams or on a project team meeting

• When the functionality is developed, test according to prepared test cases (typically on dev partition) and document the results (screens/videos, used data for testing, comments about testing, correct status of test case)

• In case you find an issue, document it properly in JIRA

  • describe the observed behavior and expected behavior in the user story comments. Attach screens/videos or other useful files and don’t forget the steps for reproduction.

  • assign the user story to CE who did the development

  • change the status of the user story to Rejected

  • when a complex issue was found by you or you already reported the same issue several times, discuss the situation with your PM and agree with him how to report it so it is fixed properly.

• In case there are no issues after testing and all tests passed, document it properly in JIRA

  • document what you tested in the test case - data you used, screens from your testing, any other info about your testing

  • mark the test cases as passed

  • change the status of the user story to “Accepted dev“

  • assign the user story to SA (or to somebody who will do the deployment to qa partition)

• After user stories are deployed to qa partition, retest the functionality briefly directly on qa partition - before the customer start testing

• After user stories are deployed to qa partition and checked by QA Analyst, customer should do his part of testing to check the user stories meet defined Acceptance Criteria and to formally accept the user stories before UAT phase. Note the customer is always testing just on qa partition during the project.

• You can be asked to prepare a functional demo for the customer

  • based on what was developed in the Feature Sprint

  • just functional demo is typically expected - not a business discussion

  • typically on qa partition

  • have data, workflows, dashboards, … prepared before you start the demo - in that case you will have more confidence and you will be sure the functionality works correctly

• you can be asked to help the customer with UAT preparation

  • demo of test management tool (X-Ray)

  • tips and recommendations for UAT

  • questions and demos of testing

  • templates for testing

  • note that a lot of documents are prepared in Confluence or on Sharepoint - if you need help, contact your Competence Leader 

UAT

• Before UAT - you can check with your PM and offer the customer help with UAT preparation, if the customer is interested in your help. Possible areas to share/discuss are:

  • preparing test cases for UAT - note they should be prepared based on E2E use cases and they should not just repeat testing from Feature Sprints

  • how to organize UAT (prioritization, reporting bugs, test sets, code freeze)

  • what is needed for UAT testers (training, access, testing knowledge, UAT expectations)

  • using test management tool (X-Ray) for UAT

  • templates or our test cases as examples of test documentation

• During UAT - the customer is responsible for testing during UAT, so typically our testing during UAT phase is focussed just on retesting fixes and helping to our project team:

  • regression testing to be sure a new issue was not introduced because of some code change

  • smoke test on qa partition after deployments

  • retesting of issues reported by the customer and sharing details with our CEs

  • in case the customer is using X-Ray for test management, you can help PM with checking the progress of UAT testing

  • in case the customer ordered a test automation package, the scope should be finalized here and the development should start

Cutover

• Typically QA Analysts are not involved in this phase

• In case the customer ordered a test automation package, the development should continue here and first tests should be handed over to the customer

Stabilization

• Typically there is nothing to be tested in this phase, only exception can be when Go-Live was agreed with some bugs. Those known bugs are then fixed during Stabilization and then they need to be retested.

• In case the customer ordered a test automation package, the development should be finalized here and tests should be handed over to the customer