This article provides a set of do's and don'ts for quality assurance (QA) professionals working on software projects. It emphasizes the importance of clear communication, delivering test documentation, and understanding the purpose of their work. The article also covers the responsibilities of a QA Analyst, the use of test management tools, the benefits of test automation, bug reporting processes, and project communication.

Basic rules and regulations

These are basic rules we should always keep in mind when we are on the project:

• Always report your work. Deliver at least basic set of test documentation (test plan, test cases, bug reports and test report). It must be clear what we are doing on the project, that we have a clear test strategy at the beginning, what we tested and what were test results.

• Clear and active communication. A big part of our work is about communication - to our project team and to the client. If something is not clear to you, you need to explain something or you found some issue or risk, your responsibility is to communicate as soon as possible.

• Think about the purpose of your work. We are not on the project to create documents, bugs in Jira or report tasks to timesheets. Keep in mind we want to help our project team and the customer, everything that we do on the project should support this purpose.

• Beware of emails - please think about having a lot of project information in emails, maybe a better way is to copy them to Jira. In Jira, they will be visible to the whole project team, not just to recipients and they linked to the correct user story or correct task. Emails become quickly confused and they can be easily overlooked. So keep it simple and transparent and use Jira tasks instead.

Before the project

• Before you make your START, know the HISTORY and the TEAM:

When you start a project, always start by gathering below mentioned things, at the minimum:

1. Know the PCSS(read pieces ) of the project

   1. Know the PM - to understand the schedules and milestones.

   2. Know the CE - your counterpart in all that you want to achieve for the customer.

   3. Know the SA- the technical owner, who (probably)“defined” and “will define” how the customer’s requirements are going to be realised in our system

   4. Know the Customer Success Manager - the person who does firefighting(read handle all the flak from the customer) after the system goes live

2. Know which modules are present in the system ,if there is one existing already.(QC,PA,PB etc) – Helps in getting holistic view of the system and understanding inter-working of the system.

3. Know which are the partitions available for that customer and where is the testing expected to happen? – Helps in planning testing effort.

4. Know the link to project’s confluence page – contains all the documentation or links to documentation related to the project

5. Know if the basic data(products, PE tables and PP tables), in all the partitions, in sync with each other? That helps in testing in a “near-customer” environment.

6. Know logics used in the project. Where they are stored and get familiar with them. You might need to open them and search in them sometimes.

7. Know which jobs are used in the project how and when they are triggered (CF, CFS…).

8. Know how many partitions are used on the project, which data they contain, what are the differences between them, how often they are update and what are rules for using them. Know who uses which partition, how many people work simultaneously on one partition etc. It helps to keep the testing data ready for testing.

Scope of Responsibility

Here are basic instructions for QA Analyst and how the scope of their role in the project.

QA Analyst role

QA Analyst is a standard project role which should be part of every project team. The main responsibility of QA Analyst is to perform functional testing of the project (based on user stories and regression testing), document everything what was tested and help to the customer with testing during the Feature Sprints and UAT.

QA Analyst and project

QA Analyst work is a part of our standard project methodology, mostly based on Agile methodology. All project documentation is done in JIRA

QA Analyst responsibilities

• what we are doing during the project

  • functional testing based on user stories

  • documenting of testing - test cases, test results for testing based on user stories

  • communication with project team

  • helping to the customer with testing - more experienced QA Analyst can be asked to help

  • basic data import testing - checking selected amount of data to ensure that data was correctly imported

  • regression testing when enough development was done

  • test automation - note there must be enough allocation for this as test automation is always on top of standard work of QA Analyst

  • review of user stories and acceptance criteria - note there must be enough allocation at the beginning of the project

• what we are not doing on the project

  • testing of full data imports - we are doing basic checking, but we are not checking every item

  • performance testing - Kevin Gerard’s team can help with this

  • testing of all possible combination of parameters - typically it is not possible because of our allocation, so we are testing just examples to be sure functionality is working correctly

  • UAT testing - this is customer’s responsibility

  • Preparing of UAT test cases - UAT test cases should cover end to end processes and it should be created by the customer. We can however help the customer with test management, show him how to create test cases, report bugs, organize tests.

Test management

Main goal of test management is to document everything what was created by QA Analyst and make it visible for the project team and the customer. It is significantly improving the communication about testing on the project

• Tool used in Pricefx

  • X-Ray - standard part of all our Jira projects, however it needs a small configuration before it can be used. Therefore contact QA Competency leader before you start using it on a new project to make sure X-Ray is ready for you.

  • Issue types added by X-Ray

    • Test Plan - overview of test results of the whole project

    • Test Execution - overview of test results of the Feature Sprint

    • Test - means test case. Note there is a “Test case“ issue type in JIRA, don’t use it as it is not connected with X-Ray

    • Test set - can be used when more than one QA Analyst is working on the project

  • With correct usage all Tests are linked to the correct user stories so it is much more visible which user story was covered by which tests

  • Import and export from and to csv file is possible with some limitation - for details see the description of this functionality

  • The customer can use X-Ray for UAT and it is highly recommended

• Using test management tool is mandatory for all new project

• Bugs are typically not reported officially during Feature Sprints, only during UAT

• We are often recommending to the customer to use X-Ray for UAT - it brings more visibility to UAT preparation and progress and therefore it is significantly lowering the risk that a critical bug will be found at the end of UAT - this is a very important business reason why to use X-Ray on our project as it would be very hard to offer to a customer a tool which we are not using on the project

Test automation

• test automation is not mandatory for all projects, but is highly recommended especially for long term projects

• tool we are using for test automation is http://Cypress.io

• test automation should start when some development is finished and the application is stable enough

• note that test automation should be discussed with the customer as there should be some extra allocation for development of test automation scripts

• test automation should be especially considered in these cases:

  • the first phase of the implementation was completed, the second phase is beginning and we need to be sure nothing was damaged by the new development

  • in case we are repeating the same test over and over again

  • the customer needs to cover a set of use cases because of regular testing after upgrades to a newer release

  • the same test should be repeated with big data set

Reporting bugs

• during Feature Sprints

  • as there is a lot of development during Feature Sprints, typically we are not reporting official Bugs. There are several reasons for that:

    • All reported Bugs are visible in the project dashboard and seeing a lot of Bugs can make the project board quite messy and customer a bit nervous

    • Saving time - some Bugs can appear several times during Feature Sprints

    • When the customer starts reporting Bugs officially during UAT, it can be pretty hard to distinguish quickly which Bug was reported by Pricefx and which one by the customer, and therefore it can be hard to maintain project statisticcs.

  • in case the issue is found during testing, it should be described in Comment field of the user story, the status of the user story should be changed to Rejected and the user story should be assigned back to CE for fix. Don’t forget to add all relevant screenshots or other files, steps to reproduce the issue and expected results so it is clear what happened and what was expected.

  • in case the issue can be fixed quickly, talk to CE via Teams and if he is able to fix it in few minutes, there is no need to report it officially

  • In case there is a complex issue to report or there are a lot of Comments in the user story, the issue can be reported as Sub-tasks and assigned to the CE. In that case it is more clear for CE what it the incorrect behavior and what should be fixed or developed. When you create a Sub-task instead of comment, don’t forger to reject the user story and assign it back to the CE. Comments section should contain just link to the created Sub-task in this case.

• during UAT

  • Bugs should be reported by the customer to Jira - just bugs, not questions or tips for improvement

  • support from QA analyst is possible if the customer is not experienced enough in software testing

Testing environment

• testing environment is called “partitions“ on our projects

• typically there are three partitions:

  • dev - for development of new functionalities

  • qa - for testing by the customer to confirm the functionality is working correctly

  • prod - for production usage

• QA Analysts are often testing on dev (to check particular user stories) and qa (before the customer starts testing there to check the functionality was deployed correctly) during the project, we never test on prod

Project communication

• QA Analyst must communicate with other project roles - PM, SA, CE, IE

• In case of any problem on the project, PM should be the first person you should contact

• Ad hoc communication is typically done via Teams - calls or chats

• Small issues founded during testing can be checked directly with CE before they are officially reported - sometimes CE can fix them immediately and in that case there is no reason to report them to JIRA

• In case CE can’t fix the issue immediately, it must be reported to Jira - described in Comments, user story goes back to CE and to Rejected state - the reason is simply not to forget any founded issue

• QA should not communicate directly to the customer unless it is approved by PM - in case of any request from the customer, first contact your PM to let him know the situation

Project allocation

• allocation for all project roles is decided before the project kick-off

• the majority of QA Analyst allocation is typically during Feature Sprints and it is growing from first to the last Feature Sprint

• in case your allocation is not enough for your testing activities, contact your PM and discuss if it is possible to increase your allocation

• if the allocation can’t be increased and there is still not enough time for testing activities, discuss prioritization with your PM or SA