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.

Perform Cross Browser Compatibility Testing on Safari for Windows and all browser versions across Real Browsers and Operating Systems.

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.

Test your web and mobile apps on Android Emulator online. Ensure your apps are compatible across latest and legacy Android operating systems, devices, and browsers.

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

2. Use of linters

3. Static code analysers

• Programming errors

• Violations of common coding standards

• Syntax anomalies

• Security issues

• Static testing

Test your mobile websites and smartphone apps using our scalable on cloud mobile emulator online.

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.