Ensuring data integrity in SAP S/4HANA migrations: Best practices and strategies
Explore four best practices to ensure the success of SAP S/4HANA...
A rose by any other name would smell as sweet. So said Shakespeare’s Juliet, convincing herself that Romeo was a great guy, even if his business card had “Montague” on it. Her point is well taken. What matters are a thing’s inherent qualities, not what it’s called.
However, sometimes the opposite happens — two names that have different meanings merge together over time, making the differences between them fuzzy and unclear. When that happens, we lose perspective about what it means to be one thing or the other.
Take these two job titles: Test Engineer and QA Engineer. Is there a difference between them? Would you consider yourself (or the people you work with) to be one versus the other? Or are those two titles interchangeable?
In this post we’re going to discuss the difference between software testing and quality assurance. People often confuse these terms, but the roles are actually quite different. If you hold one of these jobs, you might want to put some thought into how you’d like people to perceive you — and maybe even how you perceive yourself.
A great place to start is a typical job description.
Here’s a snippet about an opening at Amazon for a QA Engineer:
The Amazon Cloud Drive Team is looking for a highly skilled Quality Assurance Engineer who is passionate about creating the absolute best customer experience for Amazon’s digital media customers. As a key member of the Cloud Drive team, you will have the unique opportunity to shape and build a brand new product based on Amazon Cloud Drive technology.
The job description goes on to describe how this individual will be “pushed to think first from the customer’s perspective” and ask questions like “What does the perfect solution look like?” This is common in QA jobs — as you look through similar job descriptions, you find that QA engineers are expected to make a meaningful impact on the customer experience.
Now let’s look at the role of a software test engineer, this time from Apple:
If you’re passionate about quality, we may have the job for you… You will join a dynamic team responsible for qualifying the latest iOS products with focus on the cellular telephony software. The successful candidate will complete both documented and ad hoc testing to ensure high quality releases.
Notice what’s not in this job description? There’s nothing about the customer experience, and very little about the overall product. According to this posting, the software tester’s job is much more focused on being a team player who examines the quality of the code. This person has a role to play, and is expected to play it.
Obviously these are only two job listings among thousands, but what you see here does in fact begin to reveal the key difference between being in QA and being in testing.
A software tester is charged with finding bugs before users do. They investigate and report on how well the software performs relative to its expectations. However, in QA, you are asked to ensure the quality of the software. It’s a looser, more ambiguous role — but that is intentional.
As a QA engineer, you step into the shoes of the user and are given the opportunity to tell your teammates, “Yes — this is a quality piece of software,” or “I’m sorry — the app did what it was supposed to do, but the experience stunk!” That’s a critical function on a software development team.
A QA engineer…
A software tester…
Lots of people share this perception of how these roles are different, and why a QA engineer has so much more opportunity to make an impact. Here are some great examples from around the Internet:
On a LinkedIn Discussion Group:
“QA and Testing both have to make software better, but QA enhances the quality via an improvement of development process and testing enhances it via finding bugs.”
From StackOverflow:
“A simple example: The quality assurance team decides that correctness is one of the primary quality attributes for all projects and defines the quality goal that the statement coverage of unit tests should be at least 80%. In each project, the software testing group is now responsible to reach that goal.”
From QATestLab:
“QA is more focused on managing the product life cycle and verifying that the software meets the defined quality standards or customer agreements… Testing, on the other hand, may keep an eye on the processes and often owns them, but is far more concerned with finding ways to break the software.”
Remember, your title and your job may not be aligned. Furthermore, neither your job nor your title defines you.
You may have been hired as a software tester — and perhaps that’s all that’s expected of you — but if you start thinking about your customers, and their experience, and how your product, your team, and your processes can be improved to make that experience better, you are already acting as a QA engineer.
Challenge the status quo, ask the next question, and continue to push the boundaries. If you do that, you’ll make a mark on not just the app, but the entire team.
This blog was originally published in 2014 and was refreshed in July 2021.
Explore four best practices to ensure the success of SAP S/4HANA...
Improve visibility and traceability across testing and CSV...
Compare code coverage and test coverage to understand which method...
Learn about the basics of modern application architectures and why...
Running a full regression test on a mature codebase can take hours....