My experiences in Shifting QA left

We have all heard the term ‘Shifting QA left’ in software testing – it is a term used by many senior stakeholders and while there are lots of ways of doing this, I will be sharing some ways which have worked well for me in the past.

Defects are cheaper when found earlier, there is evidence that defects are 100 times more expensive if they are not removed during the requirements phase.

Having walkthroughs of the requirements will help to uncover questions that can add true value when done early.

I loved seeing engineering, product, and QA professionals whiteboarding ideas and devising the customer value of an idea. Having alignment as early as possible in the process meant that we created true customer value.

Sometimes asking ‘why’ early on can make a massive difference. I have seen software fail where QA, engineering, and product are not aligned on the true customer value – ultimately this may mean that critical defects are released to clients. Not because there is no care, rather it is a misunderstanding of requirements.

Take an Apple wireless mouse, me being a customer, I would have been much happier if the team discussed this early and worked out that adding a charger port on the bottom of the mouse was a bad idea – especially when it cannot be used and charged at the same time, thus, making the device unusable when out of charge.

How can we shift QA left?

1. Ensuring that QA is everyone’s responsibility – I always use the statement that QA is owned by the whole squad (product, delivery, engineering and QA) – why is this? A shared output means that there is more care for the product being engineered.
2. Prevention rather than detection – how annoying is it when you have a QA person who feels their sole goal is to find enough defects so that a developer looks totally inadequate. This should not be the objective, rather QA and engineers should work together to prevent defects occurring – pushing better unit testing and understanding what the customer value is.
3. Automation is key – testing earlier is cheaper, and failing fast is the name of the game. Automating will make it easier to find defects early.
4. Engineers and QA contribute to unit, integration and acceptance tests – in my experience, pairing and working together on these key tests mean that team accountability for QA is shared.
5. Having the right culture – this for me is of utmost importance. A culture of teamwork, sharing accountability and owning the deliverable will ensure that the communication will automatically start early.

To find defects earlier you do not need to meet all of the above. From my experience small steps can help to get the team working towards the same goal.

The way that I pushed better collaboration between engineering and QA was to ensure that there was mutual respect on both sides, with each side learning from the other. What is key is to understand the skills from both sides would ultimately contribute to the same end goal, they are both cogs in ensuring the smooth delivery of software.

Getting early testing right

Failing fast is important and having the right mindset is key for this.

We have all seen the testing pyramid: https://martinfowler.com/articles/practical-test-pyramid.html

Summarising it— unit tests are more isolated and are faster to run, in contrast user interface (UI) tests are more integrated and are slower to run.

It has been found that small and fast unit tests are key to failing fast. Whereas acceptance tests are used to test end-to-end functionality of an application from a user perspective.

Aspects that can help us shift QA left:

1. Unit testing

Unit tests are specific functionality at a code level in isolation – they put quality at the forefront of everything that we do.

For me, QA can help engineers with this and it will help their engineering skills for automation also.

2. Use of linters

Linting involves checking source code for programmatic as well as stylistic errors.

I have found it to be helpful in finding common and uncommon mistakes that are made during coding.

For example:

const test = 'Testing Dileep'; console.log(`Test statement: ${test}`); const test = 'Another test.';

1 2 3

const test = 'Testing Dileep'; console.log(`Test statement: ${test}`); const test = 'Another test.';

We are declaring test twice, with the correct linter settings and configuration, instead of getting caught later as an error when the code runs, you will immediately get an error through your linter running in the background

3. Static code analysers

This is when we check code without executing it. It looks for issues like:

• Programming errors
• Violations of common coding standards
• Syntax anomalies
• Security issues

Engineers should keep testability in mind when coding. This will work wonders for the quality of your product.

4. Static testing

Static testing is a set of questions or a checklist to perform the requirement design verification and validation. It helps to understand the business value of something and it will help QA to write their test cases.

Summary

Shift left QA is not a process change, rather it is a mindset and cultural shift for an organization.

The key reason why you should do it?

It lowers the cost of testing and development, and it also increases efficiency of releases and the quality output.

For me, what is most important is getting the team working in unison, where engineering, QA, delivery and product are aligned on the value of what they are looking to achieve. It generally means that they will push processes to shift left.