Doing QA with a Developer Mindset

Ahmed Hammad // May 17, 2022


Automation lets us do things faster and more reliably than if we did them manually.  This in turn lets us do more, thus making us more productive.  Software Quality Assurance is no different.  If you're a QA, then you're likely using automation for your testing.

Automated Tests are software and thus they're subject to the forces that act on software: 

  • They will run under varying circumstances. 
  • They will get changed. 

Developers deal with these forces daily and have adopted a mindset toward software to minimize the disruption caused by them.  This mindset focuses on writing code with high degrees of the following: 

  • Robustness 
  • Maintainability 
  • Reusability 

Let's talk about each of these properties in turn: 


The Developer Mindset:

You can never know the exact context in which code is run, so code needs to be resilient enough to run under a wide range of environments and conditions. For instance, a program that works with files must run even if some key files are missing.

How this Relates to QA:

End to End Tests control the UI, but the UI can change.  Thus, the tests should still run under a wide range of variations in the UI.  For instance, a test that uses a div should still run even if the position of the div changes on the page. 

Putting it into Practice:

Locate your elements using things that are not dependent on the look and feel of your page.  For instance, instead of using a selector that picks up an item by its layout (e.g.: :nth-child(1) > pre), use data-testid.  If the elements don't have data-testid, ask the developers to add them or add them yourself if you're empowered to do so.  Write your assertions in a way that they're less dependent on the UI as well.  Give yourself enough wiggle room so that when the UI changes, your test is still likely to run. 


The Developer Mindset:

Code gets modified, so it's essential that modification is quick and reliable.  Making changes in multiple places in the code takes more time and risks missing a change, which can lead to hard-to-find bugs.  Likewise, a change in one place shouldn't cause apparently unrelated code to break elsewhere.

How this Relates to QA:

Since the application changes, your tests will need to change as well.  You should be able to update tests quickly and painlessly and add new tests with relatively little effort.  You should never find yourself in a situation where you move a test and it fails, or changes in one test break another test

Putting it into Practice:

  1. Make your tests readable through the use of meaningful names, code abstractions (e.g.: functions), and good formatting.  If you can understand what your tests are doing, you're less likely to do something to break them.  
  2. Avoid duplication in your code.  If you need to repeat some sequence of actions for a test, then put them in their own abstraction (e.g.: function) and call that.  This way, when you need to change those actions, you can do so in one place rather than many.  
  3. Don't have your tests assume a certain state (like that which would hold upon completion of a prior test).  Make establishing that state part of your setup process.  This ensures that if you re-arrange your tests, they will still run successfully. 


The Developer Mindset:

There's a lot of potential repetition in the code of any project, so we need to abstract them under meaningful names, so we can easily call them when needed.

How this Relates to QA:

Your tests will have repeated actions or assertions that you can reuse.  For instance, filling out forms, or sequences of assertions required to check a particular condition.

Putting it into Practice:

Find where you're repeating sequences of actions and make them reusable.  For instance, if you find yourself filling out forms in your tests, create a function to fill out forms and call that instead. If you design this function correctly, then careful use of parameters can allow you to reuse it to fill out different kinds of forms.

A Final Developer Mindset: Refactoring

You don't always get it right the first time.  Maybe you're still learning about the project or didn't have time to do things the way you wanted.  Whatever the case, you might be looking at tests that could be better. 

Fortunately, developers deal with this too, and they're used to making changes solely for the sake of improving the quality of their code.  This is called Refactoring. Refactoring is changing the design of code without changing the behavior.  The goal is to end up with more maintainable code. 

Entire books have been written on refactoring, and I recommend you do some research on this.  But there's one key principle of refactoring that I can offer right here. 

Work in tiny steps

Tiny steps make it easy to isolate where you might have made an error and rollback.  And while working in tiny steps might make you antsy, each step contributes a measurable improvement to test quality.  As the saying goes, a journey of a thousand miles begins with a single step. 

So, if you're unhappy with your tests, but feel daunted by the changes required to improve them, just think of the smallest improvement you can make and do that. Test it, check it in. Now find another small one and do that.  Rinse, lather, repeat.  Soon you'll find that daunting task wasn't so daunting after all.  In fact, it's done. 

Concluding Notes

Writing tests that are robust and easy to maintain will ensure that they are run often and built upon.  This is essential for a successful automated testing strategy.  This in turn will make you a more effective QA and a greater asset to your team.  

Ensuring that you have good quality tests means adopting time-tested strategies from developers who have been dealing with these same problems for decades.  Your QA mindset is essential to your job, but to really leverage your automated tests requires thinking like a developer.  At least some of the time. 

Most Recent Thoughts

How can we help on your next project?

Let's Talk

Like what you see?

Join Us