QA Transformation Journey

Dileep Marway - Oct 13 '22 - - Dev Community

In the following article, I will talk about a situation that many QA professionals have encountered and what I would recommend the approach should be to move forwards.

The problem statement

Imagine you are in a scenario where there are lots of incidents, delivery is slow and customers are not happy with the quality of your products.

What should you do?

As a Head of QA, and Test Manager in the past, I have had experience in these situations before. I will now take you on a journey of change… grab a nice drink and come on the journey with me.

Native Mobile app testing using LambdaTest’s online real device cloud and virtual testing platform of emulators and simulators.

Step 1: Investigate

The first step is to hold independent interviews with multiple team members to understand the problem at hand.

I would recommend asking open-ended questions like:

  • What is the reason in your view for the incidents and customer complaints?

  • How would you describe the culture?

  • If asking questions outside the QA team:

  • How would you describe the QA approach?

  • How do you collaborate with the QA team?

Once the inspector gadget phase is over, we must now digest the information. I would recommend independent chats or surveys with QA, product, engineering, delivery, and customers (if possible). These chats should not be biased in any way and it should be shared by the interviewee that chats are confidential, with no names or details being shared outwards.

Step 2: Data analysis

Based on the data gathered, this data should be analyzed to then decide where to focus your attention.

For example, in my experience data can be generally focused on the following:

  1. Cultural issues

  2. Lack of ‘Assurance’

  3. Poor product knowledge

  4. Lack of collaboration between Product, Engineering, and QA

Accelerate your release velocity with blazing fast automation testing on cloud.

Step 3: What to do?

The next aspect is to decide what to do. I will explain some examples of what I did for each scenario, with additional examples.

  1. Cultural issues

  2. Lack of assurance

  3. QA strategy — aligned to your technology strategy, what are you testing and why?

  4. Testing approach — what is your particular approach to testing on a particular project/squad?

  5. General overview on what you are testing and why? At least then you can then collaborate with engineering, product, and stakeholders to review gaps in your test cases.

  6. Poor product knowledge

  7. Get the product team to review and contribute to the test coverage in the test cases.

  8. Get the product team to review and contribute to the acceptance criteria on tickets.

  9. Meet regularly with the product team and ensure that product knowledge is shared/updated.

  10. Poor collaboration with Product and Engineering

Step 4 — How do we maintain success?

We should track whether our mitigating measures have made a difference or not. Going back to our problem statement, we wanted to see whether we can reduce customer incidents and also customer complaints.

I would recommend a full post-mortem review as learning when incidents take place and reviewing whether the incident amount is going down. If they are not, do another review independently to establish the root of the issues.

Tracking success can only be done if we start to track certain metrics.

Aspects that I have found useful to track:

  1. Escaped defects

  2. Customer complaints

  3. Test cases that have been added to your regression suite every sprint

  4. Unit test coverage

  5. Number of times a ticket is re-tested and defects found against it

In this article, we look at what is Regression testing, its importance and types, and how to perform it.

Conclusion

Quality assurance transformation is a journey piece, and by tracking QA metrics, step-wise improvements can be achieved.

Success cannot be maintained solely by QA, rather it is a collaborative effort with QA, Engineering, product, and the wider team.

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .