Here’s the secret: in the context of the workplace, you can’t trust a word that comes out of a programmer’s mouth. Programmers lie all the time. Programmers lie like it’s their job. But it’s not their fault, it’s just part of the process of building software on a team. Lies like, “my code doesn’t have any bugs” and, “I actually built what I was asked” are two notorious lies that programmers tell all the time. The QA team is like a private detective. It treats programmers like the untrustworthy people they are. Wowsers!

How the Quality Assurance (QA) Team Works In Software Companies

Most large and medium-sized companies have a QA team, whose job it is to verify that the programmers who are building the product didn’t break anything. Some small companies and startups don’t have a dedicated team responsible for this, though. Developers are a rambunctious group, so sometimes the tester’s job is like herding cats.

The world distrusts developers – so in most cases, developers aren’t allowed to make code changes “live” or impact real users until the QA team gives their code a stamp of approval and says with confidence, “the developers did their job and didn’t mess anything up.”

When the manager wants to know if code changes are ready to be exposed to users, they don’t ask the developers. They ask the QA team, because the QA team is the gateway that all code changes need to go through.

Manual Testing

When developers tell you they made changes, the most straightforward way to verify that things work is for people to see it with their own eyes.

While simple in theory, this brings up a bit of a Catch-22. If a QA engineer needs to see something working with their own eyes before the change is “live,” how can they? If a feature isn’t live on the Internet yet, how could they possibly see with their own eyes that the feature works?

A Staging Environment

To get around this concept, basically all companies (whether they have a QA team or not) use what they call a staging environment, which is a copy of their real site (with different code running on it). Staging is a place, live on the Internet, that most people just happen to not know about. In a nutshell, there will be two versions of the application live on the Internet: one is accessed by real users, and the other has experimental code that may or may not work.

If the staging environment breaks, it really doesn’t matter since it’s the experimental codebase, and the real place on the Internet will still be up and running.
It’s common to have the URL be a little different for both places. For example, Groupon has http://groupon.com go to their main production website. But the URL, http://staging.groupon.com goes to their experimental (staging) version that nobody knows about (until now!).

As a user of the site, you probably don’t know about the experimental version or have any reason to care if it’s broken or not. Sometimes, access to staging is limited only to people who work at the company (like Groupon, where you have to give credentials to get there). Other times, you just use the fact that nobody outside the company knows the URL, so it’s Security by Obscurity (although that’s a bit of a dirty phrase in the programming world).

How the QA Process Works

So if a developer indicates they added a feature, a member of the QA team will quickly validate the feature has been added and is working on the staging environment.

Many times there is a disconnect between what the developer thought they were being asked to do, and what they actually were asked to do. The QA team acts as an unbiased third party who can make sure the developer didn’t build the wrong thing.

The team will also perform what’s known as a smoke test before any deploys. A smoke test quickly tests that the key features of the app are functional. These tests usually don’t include some of the more obscure features, but can give developers a good feeling that the most important features of the application are functional.

Some of the tests that are performed are put on a checklist, and testers will go through them feature by feature to check that each specific feature works. This list could look like the following:

• The root page looks okay
• Login works
• You can buy a product on the platform

And a member of the QA team will go bullet by bullet and double-check that each feature works.

Automated Testing

More and more, the people performing these tests are finding that running through specific scenarios manually is a repetitive and boring task. Instead of reliving the same thing over and over again like Bill Murray in Groundhog Day, they’ll write quick programs that will automatically run through the steps they manually did.

This means, instead of spending 3+ hours pointing and clicking manually, the QA team can just run a program they maintain to automatically do all the grunt work.

The teams of testers might write the automated tests using a different programming language than the web application itself. For example, your application might be written in Java due to technical details, but the testing team might prefer to code the tests using Ruby or Python.

Most Teams Use a Hybrid Approach

When a tester is testing a new feature, they’ll usually first manually test the feature and verify that it’s working as specified. From there, if it does work, the tester will convert their series of clicks and typing into a program to automatically do what they manually did the first time.

Test Driven Development

There’s a fancy buzzword that many of the best teams use, called “Test Driven Development” (or TDD for short). The developers (not the QA team) who practice TDD will build features and also write an automated test at the same time that makes sure their code works.

Using TDD keeps the code safe and provides a quick feedback loop for developers. You don’t need to ask someone else to run tests on your code, you can just do it as you build the feature out. Surprisingly enough, most companies that practice TDD have external QA developers write their own separate test code as well. This might seem redundant. If the developers are writing automated tests, why have a separate QA tester write a test as well? It seems like both teams are doing the same thing.

While the two tasks might seem identical, each team has a slightly different outcome they’re shooting for, so having two groups of tests actually makes sense.

QA Teams Are Responsible For Keeping the Site From Breaking

It’s the QA team that signs off and says, “this code is good.” This means they’re responsible for detecting when things are broken. Given this responsibility, the QA team will act like the worst user a platform has. They’ll do all sorts of stuff the developer probably never thought of. It’s their job to uncover this stuff before a user does.

Really, a QA Engineer’s job is pretty simple:

• Say the code is good and ready to be shipped, or
• Point out defects in the code

A bad engineer could just always say “thumbs up” all the time and do basically no work. If they’re working with a solid dev team, they might get by doing this for a while. But after a lot of stuff slips through the cracks, they will get fired.

It’s the QA member who signs off on a feature who gets the blame for the problems. Not the developer who actually wrote the code that broke the platform.

Developers are responsible for building features (and usually a lot of them)

Companies have teams of salesmen who are busy selling features for their product (sometimes that aren’t built yet).

“You need salesforce integration? Cool, we can build that. Our developers are rockstars, that will be gravy for them. It’ll be built in a couple weeks, why don’t you pay us now?”

Companies have design and user experience teams who understand how real users on the platform interact with it.

“Oh my god. Almost half of our users don’t even see this button, which is the only button we want users to click.”

Customer service is constantly dealing with customers who are having troubles.

“Oh, you’re trying to pay and it’s broken? Let me talk to the developers and see what’s going on here.”

And developers usually build out features that allow customer service, account managers, and other non-technical team members to change the state of users’ accounts.

“The admin dashboard is basically impossible to use. I need to click around for 2 hours to achieve a simple task.”

And all these people will tell the developers that their problem is top priority. It’s the product managers who turn this never-ending influx of stuff developers need to do into an organized list – but it’s not an easy job.

With an insane amount of work to do, being able to move quickly is pretty important.

But, the fact of the matter is, developers who navigate codebases with 10,000 lines or more of code usually don’t fully understand the intricacies of what every single line in the application is doing. That’s what TDD fixes.

If a developer doesn’t understand the entire product – it’s incredibly easy to make a change in one place that breaks something someplace else that they have no knowledge about. These automated tests give developers a pretty good feeling that their code is working and that they didn’t break a totally unrelated feature that they didn’t know about before they hand the code off to the QA department.

If you as a developer don’t have a test suite that you can rely on at all, you can probably expect to get a lot of problems sent back to you from the QA team.

Tests the development team write are designed to catch 90% of the most common problems that could come up to prevent back-and-forth with QA. The tests the QA team writes are more like the Castle Black that keeps the application safe from the white walkers.

The QA Team Is Important!

Engineers who are experts in writing automated tests are in high demand. The job is very similar to being a web developer, and starting a career writing automated tests, and later transitioning to becoming a web developer is a common career path.

I highly suggest people looking to break into web development to consider applying for positions as a QA Engineer. Internally switching to the development team from the QA Team happens all the time, and if you follow this path, you’re competing with a lot less folks. The hiring process for a web developer who is currently a QA team member is generally easier too; in many cases, there will be no interview. The dev team already knows you. They already trust you.

Automated testers are experts at using certain tools. A common tool that automated testers use is selenium, which connects to a web browser and you control it with code instead of a mouse and keyboard. Taking the time to code out the interaction generally takes longer than it would take to manually do the pointing and clicking. But the amount of time it saves you in the future is enormous.

So although the developers are building the features of the application, it’s the QA team that makes sure the application actually works. If you’re struggling to find a job as a web developer, I highly suggest looking for a role as a QA Engineer. Heck, I recommend doing so even if you haven’t applied to a single position yet.
While developers are heads-down and spend more time coding, QA Engineers will have a more balanced breakdown. QA Engineers:

• Usually get more email
• Usually go to more meetings
• Probably spend around 10-40% of their day coding, and 10-40% of their day doing manual testing

If you’re searching for positions on a job board, the titles of the role are QA Engineer, Software Engineer in Test, Quality Assurance Engineer, and QA Automation Engineer.  Having a background in software QA grants you a tremendous amount of respect from developers as well.

But thank heavens for the QA Team. As a software engineer, they’ll help you keep your saving grace in a world where everyone needs their feature coded by yesterday!

If you liked this post, join our conversation about why going far is done better together.