QA: The All-Stars of the Software Assembly Line

Like so many aspects of software development, quality assurance (QA) was “borrowed” from the world of manufacturing. It’s kind of uncanny how similar the process of a car coming together on an assembly line resembles the development of an app.

You might think of an assembly line as one long line, but in reality, the major components — the engine, the chassis, and the transmission — are built separately, and they come together in the body of the car on the production line.

Software is the same way. Major components are built independently and then integrated into one final thing. 

In this factory analogy, you might think of QA as an inspector on the factory floor, walking around with a clipboard, peeking over the workers’ shoulders to make sure they’re doing the work to the manufacturer’s standards and policies — all of which culminate in quality.

“Testing… Testing… 1 2 3”

QA is responsible for designing the tests and processes that ensure each component’s integrity and fulfill the bigger vision of the final product. 

Translating requirements

Apps start out as an idea — a thing to help a user do a thing. 

That idea gets fleshed out into an experience — how the user does that thing, and what that process looks and feels like. 

Then developers bring that experience to life through code. Even after all this time, it still seems magical to me. 

It’s a bit of an art to take the vision of an experience and boil that down into specific, concrete code functionalities, aka “technical requirements.” 

Think about it. If you have a design for a car, you don’t tell a manufacturer, “I need a chassis to fit this car” and show them a drawing of the car. You give them a schematic of the chassis itself with measurements and specifications. If they build the chassis to these specifications, it will do what it needs to do for this project.

Test planning & design

In our car analogy, it would be ridiculous to wait and perform QA after the entire vehicle has been assembled. Imagine cranking the key for the first time, and…. Nothing. 

It could be a thousand different things. You’d have to take the whole car apart to figure it out, then put it back together without causing anything else to break. Did I mention how much time this would take? A lot.

The major components of the vehicle undergo rigorous testing before they come together. Not just by physical measurement, but by their ability to withstand pressure or heat or wear and tear. Software is tested the same way. 

Once the technical requirements are finalized, QA decides and designs which tests will validate the app’s intended functionalities. That way, the developers can code components with the aim to pass the tests — which is way easier than coding to an abstract outcome.

Test execution

As developers code the app’s components, QA executes tests (or test cases) on those components. These tests are meant to resemble potential user behaviors and inputs. It’s more involved than it sounds.

Consider a simple login box. Does it respond appropriately if the user enters the correct credentials? What about the wrong credentials? What about old credentials? What about special characters? What if they enter the number 9999999999999999999999999999999999999999999? What if they’re using an OS version from five years ago? What if they switch to landscape mode mid-type? What if a thousand people attempt to log in at the same moment?

Tests have to account for all types of weird user behavior and environmental factors, not just the desired ones.

Defect reporting

If the code responds wrongly to a test case, the QA engineer must meticulously document the issue and report it back to the development team. The more detail and context they can give, the easier it will be for the developers to recreate the issue and go about remediating it.

Regression & end-to-end testing

Regression testing happens when new features are added to the product, or changes are made to the product. Regression tests re-test the existing functionalities to make sure additions and changes haven’t broken something that was already there.

Software is a tricky thing. Even changing the color or shape of a button may break something entirely unrelated. The only way to be mostly safe is to re-run the entire gamut of tests every time there’s an update. 

Of course, there’s testing to be done after all the components have been compiled as one app. For whatever reason, new problems can arise when components are working in conjunction with each other and passing data back and forth. End-to-end tests are designed to catch these defects.

Automation, AI, and All That Jazz

So, one challenge for QA is that testing is hard to scale. 

🦕 As the app evolves, the suite of tests that must be run with each update gets bigger and bigger.

🔧 Tests and test scripts (a rudimentary form of automated testing) must be updated to reflect the latest updates.

🌀 Test data used to perform tests must be generated from scratch or pulled from the environment and anonymized. 

AI-powered tools are emerging at the enterprise level that can reduce the test load by identifying which functions of the app will be affected by a change (which reduces the number of tests you need to run). These tools can come with “self-healing” capabilities, meaning basically that automated tests update themselves, so QA doesn’t have to maintain tests manually. 

Rather than replace QA — by the way, why is replacing people always the knee-jerk reaction anytime a new technology drops? — automation and AI promise to free QA teams from the manual tedium of their role, so they can turn more attention to the creative, strategic, human parts of software development.