Ever since the first piece of code was ever launched, testing was an integral way to make it work. It was rather straightforward — does it work? Yes or no. No? Fix.
But as the scale of the software and its functionality rose, developers had to spend more and more time testing different scenarios and cases — I presume to a point where testing took more time than actual code development. Thus, a less qualified position emerged: a code tester. That freed up some time for developers but also created quite a dull role in the software development process.
However, that was not enough, as testing a single change is one thing. Overall quality, scalability, and ease of maintenance, not to mention other aspects of future-proofing the application are another. Here’s where the quality assistance (QA) process is introduced. A QA engineer is no longer just a tester going through paths laid by new code, but also someone who actively seeks ongoing high quality of the entire process through several ways.
In this article, we’ll learn about quality assistance, its process, the culture around QA, and more. Let’s jump in!
Let’s start with the definition! Quality assistance, in software development, is a model where quality assurance, as a function of the business, is not seen as a separate activity, but rather as a shared responsibility of the whole team. Quality assistance is then that shared responsibility and focuses on coaching, mentoring and empowering developers to deliver high-quality software, rather than just testing and finding bugs.
In practice, however, selected team members are designated as quality assitance engineers (QA engineers), who lead or oversee the quality and testing aspects of software creation.
Quality assistance requires a particular set of skills, such as influencing, providing testing expertise, root cause analysis, automation, documentation, auditing, and training. QA engineers need to practice these skills to be effective and to gain the respect and trust of the developers and the rest of the team.
The main difference between a tester and a QA engineer is that the latter is involved in the whole development process — all the way back from the initial pitch from the product manager — so that they can ensure quality and flag any known risks from the get-go. Thus, the QA process has several stages:
QA professionals review the requirements of the product before starting work so that they can be clear on what needs to be done. This will allow them to understand the scope of the investment and what input will be required from them. With this, they can move to the next stage, the planning.
Before that, however, let’s pause a second to stress the importance of this stage. Its success will really mean a much lower potential for the feature to fail technically later down the line. It’s not about preventing any bug from happening, but instead creating a way to ensure the end-user will get the most polished and stable version of the proposed update.
Thus, there is a big responsibility on the product manager to clearly present the project and make the outcomes clear. That also puts pressure on the development team, as they need to correctly identify the technical details that will bring the discussed project alive. Only with that information can the QA engineer proceed with their work. This, of course, means that a single “introductory” meeting might simply not be enough and the team, PM, and a QA engineer will have to meet several times before right and solid conclusions can be drawn.
For this to work, there needs to be a strong culture and understanding that the QA engineer is not just a plain tester, but that their responsibilities (and competence) go way deeper. Assuming however that such recognition is present, the QA process can move to the next stage: planning.
After the QA engineers have understood the requirements, they can start developing a test strategy and plan deliverables. Sometimes, it will be as simple as only planning specific testing scenarios, but this can also mean taking into account extensive integration testing, updating (or building new) automated testing, as well as identifying external parties that may need to be involved (i.e., consumers of the API being updated).
With the planning done, QA engineers can create test cases and scenarios based on the requirements and the test strategy. Maybe they will be involved in the coding of the new feature directly to ensure all goes smoothly and they can take some of the edge off from the main developing party.
Once the code is ready for testing, QA engineers can execute their testing scenarios and check whether automated and integration tests run as expected. This is the part that historically the “testers” would perform.
In this phase, tests are documented for future evaluation. This is instrumental in two cases: when something goes wrong further down the line and the cause needs to be identified, or if a similar project will be run in the future. This way, a lot of the original work can be reused.
After all the defects are fixed and verified, testers close the testing cycle and evaluate the overall quality of the product
Of course, those stages are a little hypothetical. Each company and team can amend them to suit their needs and be either more relaxed or formalized. However, they should also follow a set of quite universal principles.
I did mention that in order to be effective, a QA engineer needs to work in an organization with a strong quality culture and understanding of the role. Thus, it is important to introduce and popularize several elements of the QA culture that include:
This is the overall framework and structure that defines all the policies, objectives, and responsibilities for quality assurance and control activities. It also includes the documentation, records, and manuals that support the quality system.
Learning this will be a great way to onboard any new member of the development team, including a product manager. This is also crucial to attribute responsibility — i.e. whether upkeeping users’ data privacy is a job for the QA engineer, product manager, or other dedicated privacy officer.
These are the specifications and criteria that establish the requirements and expectations for quality. While these benchmarks can be set based on external benchmarks, it’s also something that QA engineers can set and follow on their own. As long as they are transparent and actively used, they will help to elevate the product’s quality, not only by the QA professionals.
These are the measures and methods that help to evaluate and monitor the quality of software products and processes. They can include quantitative data, such as defect rates, test coverage, customer satisfaction, etc. They will be unique for each product and it might be a long and ongoing process to establish them in the first place. However, just like with the principle of quality assistance, this is always a long time investment.
This is the process of routine checking whether the product performs within the standards set, which also includes any external dependencies (i.e. APIs being used). This might feel redundant, but there is a possibility where following updates lead to a degrading quality which is not possible to spot on an update-to-update basis but becomes only apparent when testing against a benchmark from several months prior.
Of course, not many products will require that level of the highest quality, but for automated stock bots, for example, every millisecond counts and can mean a difference of millions of dollars.
This is a strategy of avoiding defects from occurring in the first place by following a systematic and structured approach to quality. It might not sound that special but is very important in terms of the right quality-focused company strategy.
With this, the stakeholders will need to understand that a product release will take more time, and advocating to sacrifice quality in favor of speed is not acceptable. Maybe it is, but then it can’t be proclaimed as a strategy. This way, the highest quality standards will be present on paper alone and will damage the morale and the actual product.
There is nothing wrong with the “breaking things fast” approach in startups as long as this is transparent.
Continuous improvement is the practice of constantly seeking ways to improve the processes and products that deliver quality. Here is where a QA engineer can truly leave their “simple tester job” roots and rise up to a true tech leader, maybe even as high as a director or quality VP position.
Let’s take a pause here to look at ways that continuous improvement can be achieved since I have identified this as a key opportunity for a QA engineer’s career growth. Those will include:
Now that I presented you with some theory, let me tell you about my personal experience with both a setup with testers and a setup with a QA engineer. Spoiler alert: I would never go through the tester route if I had the chance.
Without naming the company, I can tell you that the setup with testers baffles me to this day. Let me stress, this wasn’t personal in any way, I’m sure those testers did the best work they could. However, the process itself was pretty faulty.
Basically, the developers were expected to provide the “highest possible quality of the product” and testers were there only to do a final sanity check. However, given that those people worked in a different time zone and weren’t part of the team, we would often see them unable to complete a test overnight due to a minor missing detail or them not fully understanding what is expected.
Frankly, I’m not sure why we invested in having the tester sign off on any change if there was an expectation that the completed code shouldn’t require additional testing anyway. Well, if you have written anything in your life, not only code, you will know that much of the fine detail somehow is lost between the brain and typing fingers. At the same time, the brain refuses to notice the issues that the fingers introduced, unless there is some break between writing and a review. I never saw it as healthy or efficient to have a developer test their own code.
On the other end of the spectrum, there is Stepstone, a company I came back to after a three-year break. There, every team has at least a single QA engineer assigned basically following each of the principles listed above. It doesn’t fix all the problems in the tech world, but the overall quality of releases is always top-notch. Not to mention the fact that it’s easier for a product manager to understand where a project is in the development cycle if there is a testing plan crafted and its progress can be observed.
It’s especially encouraging when the QA engineers take up additional coding lessons in their free time to fix minor bugs in the product that would probably never have made it to any sprint. Surprisingly, having technical quality in mind since the day of the inception of any initiative doesn’t feel like increasing its complexity. Instead, I feel like its stability and confidence in the promises given are elevated, thus making the whole ordeal less stressful in the end.
While I hate to repeat myself, the final words of the previous chapter sum it up perfectly. You might think that introducing a QA process in your product will be challenging and will introduce a lot of additional overhead to any development project. That might even be true, but the quality and stability given back are really worth it.
You might be able to push on with only simple, dedicated testing on your product for months or even years on end. However, you will be working on borrowed time. One day, the quality of the project will collapse and without gigantic refactoring investment, it won’t be possible to release any new update for months, if not years on end! This is when you will recall this article and wished you invested in quality assistance when it was way simpler to embed the whole philosophy in your day-to-day operations and create a well-performing development process that results in products of top quality.
Thank you for reading and I’ll see you soon next time!
P.S. Thank you, Dawid Bastek, for being an inspiration for most of this text, and not to mention helping me make sure it’s factually correct.
Featured image source: IconScout
LogRocket identifies friction points in the user experience so you can make informed decisions about product and design changes that must happen to hit your goals.
With LogRocket, you can understand the scope of the issues affecting your product and prioritize the changes that need to be made. LogRocket simplifies workflows by allowing Engineering, Product, UX, and Design teams to work from the same data as you, eliminating any confusion about what needs to be done.
Get your teams on the same page — try LogRocket today.
A launch strategy builds anticipation, maximizes initial sales, and establishes a strong market presence early on.
Anish Chadda discusses the importance of having a “bias for action” — iterating quickly instead of focusing on creating a perfect prototype.
The dynamic system development method (DSDM) was first released in 1994 as a software development method to provide some discipline to RAD.
David Krell, VP of Product at Going, talks about the fallacy that PMs have to be in a position of authority to do vision-led work.
Learn more →
