The term “QA developers” sometimes sounds like a misnomer since experience has shown us that developers are not necessarily the best at doing QA.
Indeed, many businesses think they should have a team of QA developers when in essence, quality assurance and software development are two distinct areas. And although one supports the other, the main mistake is to think that developers can do as well at QA as they are at developing your software. But, of course, some companies, especially in their infancy, cannot afford a complete and structured QA team based on seasoned testers. So, we thought we’d provide our opinion on developer-led QA, what is wrong with that approach and what you should ideally look for if your main concern is to have the best performing software possible.
1. Why do businesses have QA developers?
Focus was on software development not testing
One of our key observations is that many businesses initially focus on developing their software with little to no regard for quality assurance and software testing. Then bugs, defects, or end-users feedback push these businesses to internally “hire” or create a team of QA developers. Unfortunately, although most have great expertise in developing the business’s software, they display serious flaws in proper quality assurance and software testing. For example, the software or app of these companies could be in a well-advanced stage but behind in test automation.
Software was not the primary focus of the business
One other reason could be that software is not the primary focus of the company initially. But then, as this software takes on a life of its own it forces the company to create a testing team made out of QA developers in urgency.
Business underestimates software testing
Imagine a company with an army of developers building a great app. They know the app inside out and are well advanced into development phase and are ready for release. Then they realise they lag behind in test automation, and that the quality of the software is getting hurt. This is a very recurrent issue we often see with businesses who underestimate the task and are faced with bottlenecks at some point in the software development stage.
Discover why having a quality assurance program is necessary for your business. And what exactly you should tell your bosses to convince them.
By Jim Florent
2. Key weaknesses of QA developers
In our previous post on | The 7 Best Reasons For Justifying A Quality Assurance Program In Your Business | we compared developers to racing car drivers and software testers to car engineers. While the developer’s focus is on creating the best features and code for the software, the job of the tester is to find problems and bugs and provide solutions to remedy these problems. You can, therefore, already sense the pitfall in having QA developers. For one, they might not be using the best testing tools (see below), but the fact that they have to carry out testing takes their focus away from developing their software.
Many developers lack visibility on the best tools to use to carry out certain testing functions. That’s because they are not experts in the testing fields and therefore do not necessarily keep abreast with new trends and tools. We see it all the time, with companies whose QA is developers led. When we audit the current state of the QA team members of these businesses, most organizations led by a QA developers mindset have low to mid-level expertise in automation or functional testing for example.
Best practices are lacking with QA developers
One key problem with developer-led QA is the lack of best practices that stem from not using the most effective software testing tools and not having clear visibility on targets, timing, steps, and checkpoints vs. targets.
Many customers who come to see us do not know how to implement a proper QA practice that would get them away from the QA developers mindset.
3. Must “NOT DO” in your QA
First mistake: Making QA the sole responsibility of developers
Many companies do not have testers inside their structure. So they tend to depend on their developers to do QA. However, developers are not trained to do testings. Therefore, they might or might not be good at testing their own codes. Still, one of the critical areas where developers have serious weaknesses is looking at the functionalities they are coding from an end-user’s point of view, which means integrating all of the software functions from that end-user’s point. Unfortunately, developers rarely have the knowledge of all the different functions of their software to be able to think about it that way.
On the other end of the spectrum, you should avoid making QA everyone’s responsibility.
Make QA everyone’s responsibility
This is another critical issue we observed in many organizations. Of course, managers want to have everyone involved in the QA process. But unfortunately, this approach is flawed because if nobody has direct accountability, then nothing gets done.
Fighting without prioritising
It’s essential to understand the mission and vision of the company first. Otherwise, the QA team will lose sight of their job’s purpose and will be trying to do everything. So prioritization is critical and tends to be led by the way end-users will interact with your software.
4. Must DO in your QA
Determine goals and concrete objectives
As an organization, you need to be clear about understanding your end goals as far as your QA and software testing is concerned. For example, do you want to improve the quality of your software, decrease defects in the field, improve cadence or increase test automation?
Understand your software
This second step in our 3-step approach is to work with the customer’s team to understand their current situation. From there, we access their software and do activities such as reporting on defects, examine test automation etc.
Develop implementation plan
The last 3-step approach is to develop an implementation plan based on your goals and priorities, knowledge of your software, and current situation to accomplish those objectives.
Clarify everybody’s role
For example, the organization could have developers responsible for the unit testing of their own code and the user acceptance team responsible for running the top scenarios that users would encounter and execute with the software. So different teams could be responsible for different parts of the QA function. Then the business could gather all this information together and used it as a group to make a decision on whether or not the software is ready to be released.
Jimmy Florent is a results-driven leader with more than 16 years of experience in traditional and digital sales & marketing for multinational corporations. He has successfully built and implemented global strategies within consumer durables, retail, and service industries for companies like Black&Decker, Sony, Wickes, Tivoli China. Jimmy is able to bring together different teams in complex matrix structures to achieve common goals. He’s successfully led teams in China, UK, France while operating on a global platform (EMEA, APAC, China).