The developer already tested it, so why do you need to test it too?

If you work in tech, you’ve probably heard this sentence a thousand times.

A developer writes the code, runs the checks, all the tests pass, and the feature works.

So why do companies still hire Quality Assurance (QA) engineers? Are we just here to double-check developers’ work, or is there a deeper purpose?

The short answer is: no.

The longer answer is that there’s a fundamental difference between writing code and creating a great customer experience. The value of QA lies in perspective, risk awareness, and understanding how people actually use a product.

The builder

To build a truly great product, you need two very different mindsets: the builder and the chaos maker.

A developer’s brain is wired for creation, logic, and structure. While QA starts the day with a finished product, a developer starts with a blank screen. Their job is to create something out of nothing and assemble the many moving parts of a complex system into something that works exactly as intended.

Developers are responsible for creating the magic. To build even a single feature, they have to master a labyrinth of tools, frameworks, databases, and configurations. They carry the responsibility of making sure the architecture is secure, the system can handle heavy load, and the new code integrates cleanly with millions of lines of existing logic. Their work is highly complex and demands deep understanding, precision, and sustained focus. They are the architects of the digital world.

Because their primary mission is building and stabilizing the system, their testing mindset naturally reflects that. When developers test their code, they are checking whether their blueprint holds up. They focus on the happy path, along with a few common scenarios, in a controlled environment, using standard data to confirm that the core functionality works as intended. Their attention is on making sure the foundation is solid.

Think of a developer as an architect and engineer combined. They design a beautiful, highly complex door, check that the handle turns smoothly, inspect the hinges, and confirm that it opens perfectly.

Now what? Aren’t developers already responsible for the whole thing?

The chaos maker

While developers are incredibly skilled at what they do, they cannot be expected to carry the entire burden of the user experience alone. That is where QA steps in – to relieve some of that pressure and help refine the product for the real world.

If a developer’s brain is wired for creation, a QA’s brain is wired for exploration and chaos. The goal is not to prove that the software works, but to discover what happens when the scenario is not perfect. We test unusual cases, unpredictable behavior, and the edge cases that real users may actually trigger. We test for the messy real world.

Because of this, QA goes far beyond engineering. The work calls for empathy, human psychology, and an eye for the emotional, reliability, and invisible factors that make customers want to use a product.

As a QA, I’m constantly stepping into the user’s shoes and asking myself a very different set of questions:

• Is this accessible and intuitive to use?
• What emotion does this product create for me – frustration or delight?
• Would I still enjoy using it tomorrow, or would it already be starting to annoy me?

What happens in the real world

To make this point come to life, let me share a personal experience.

I’ve seen that even a large team of skilled developers means every single scenario is not automatically covered. Tight deadlines, heavy workloads, and the sheer mental focus required to build complex architecture make it nearly impossible for any single perspective to catch everything. Once a feature is done with implementation, it’s QA’s turn to step in, look beyond the happy path, and hunt down every possible edge case.

The “blank space” API trap

For instance, when new feature was implemented, it was time to test it. My team and I ran automated tests for our Voice APIs.

During testing, I decided to try something slightly unusual: I sent a call using a sender name that contained a space. Immediately, the calls started failing. This turned out to be a critical issue. If a real client wanted to do something as simple and common as putting a space in their sender name (e.g., “Global Bank” instead of “GlobalBank”), their entire voice campaign would fail. We only discovered this flaw because we had an automated QA project specifically designed to stress-test the exact parameters our clients use daily, which even shows the importance of regression tests and their benefits before the release.

The edge case that shouldn’t break the system

Another instance happened while I was testing the delivery reports for our system. The documentation stated that the record limit field was limited to 1 to 1000. My QA brain asked, “What happens if a user accidentally types 0?” When I entered 0, the system crashed and returned a 500 Internal Server Error.

Technically, it was just a wrong number. But from a customer experience standpoint, this is a big deal. A 500 error tells the client, “Your servers are broken,” which causes panic, especially during real-time actions. It should have gracefully returned a 400 Bad Request, which politely tells the user, “Oops, your input was invalid, please try again.”

Logically, it makes no sense for a user to request 0 records. But it is our duty as QA to make sure that even when a user does something illogical, the system handles it elegantly instead of catching on fire.

The trapped user

The chaos isn’t always in the backend, either. Recently, while performing manual UI testing, I found a scenario where a user could fill out an entire complex form, only to find that the “Save” button remained permanently disabled because of a tiny edge-case conflict in the UI logic. Imagine the frustration of spending ten minutes typing out intricate details, only to be trapped at the finish line and unable to save the work.

All of these instances prove why additional testing is necessary. It is incredibly easy for crucial edge cases to slip through when a team’s primary focus is building complex core functionality. No one should set a limit to 0. A sender name shouldn’t break an API. But humans aren’t strictly logical, and neither is the real world. That is why QA exists.

QA and devs are two halves of the same brain

Ultimately, this story comes back to the same point: success. Despite our different approaches, both teams are chasing the same finish line. We come together, we collaborate, and we bring an idea to life in the best possible way.

Both developers and QA want the same thing: to deliver a product that is simple, easy to use, unique, and highly functional. We want to build something so reliable and intuitive that the end user does not even have to think about how it works under the hood – it just does.

Because my job involves finding edge cases, logging bugs, and occasionally breaking a developer’s hard work, it is easy for outsiders to assume that developers and QA are at war. But that is far from the truth. We are not enemies; we are an essential partnership. We are a continuous feedback loop where logic meets empathy.

Just like a human being cannot function with only half a brain, a truly great product cannot survive in the wild with only one mindset. It needs the builder’s solid foundation, and it needs the chaos maker’s reality check.

The developer brain ensures the software is built right. The QA brain ensures we’re building the right software for the customer. Together we create the product that customers love.

Before you go…

Next time someone asks, “The developer already tested it, why do you need to test it too?” you’ll know exactly what to say:

Code lives on servers, but customer experience lives in the real world, and QA is the bridge between the two.

The post QA Is What Happens When Software Meets Reality appeared first on ShiftMag.

“Building a successful software deployment process is akin to manufacturing a high-quality motorcycle,” explains Jose Javier Moya, a DevOps Ambassador at Amadeus IT Group, who spoke at the WeAreDevelopers World Congress.

Moya also highlighted how Git repositories act as blueprints, Jenkins automates consistency, and reconciliation agents ensure deployment integrity, drawing parallels between manufacturing and software processes.

This analogy not only underscores the complexity of modern software development but also provides a clear framework for understanding how these elements work together to ensure successful implementations.

Building the perfect motorcycle

Moya used a motorcycle analogy to highlight the need for detailed planning in software development.

Imagine your company as a motorcycle manufacturer. To build a motorcycle, you need more than just a basic idea. You need a detailed blueprint.

Moya explained that this blueprint includes specifics, such as the size of the tank and the type of tires. Similarly, deploying software requires more than a simple configuration file. It demands a comprehensive description of how the software should be built and operated.

The role of Git

Moya compared motorcycle blueprints to Git repositories.

In our motorcycle factory, the blueprint acts as a contract between the manufacturer and the buyer.

Similarly, a Git repository serves as the blueprint for software. It stores all necessary configuration files and documentation, ensuring that every aspect of the software deployment is well-documented and controlled. Just as a motorcycle blueprint covers every detail, Git repositories provide comprehensive details for software projects.

Use automation as your secret weapon

Then, he highlighted the crucial role of automation in software deployment.

Imagine if your motorcycle factory were fully automated. Once you receive a blueprint, the factory will automatically build the motorcycle according to the specified details.

Similarly, automation tools play a crucial role in software development. For instance, Jenkins and other tools act as gatekeepers. They check to ensure that all requirements are met before deployment. Using automation, developers can build and deploy software consistently and accurately.

Quality assurance is automation’s secret superpower

According to Moya, automation extends beyond just building and involves quality assurance.

Jenkins performs various checks, including static analysis, security scans, and operational checks.

These checks ensure the software is free from vulnerabilities, does not break existing functionality, and meets operational requirements. This rigorous scrutiny helps prevent issues in production, much like how rigorous testing ensures a motorcycle is safe and reliable before it hits the road.

What is the role of reconciliation agents?

Moya described how reconciliation agents like ArgoCD manage the deployment process.

After passing all the checks, the actual deployment is handled by reconciliation agents.

These tools continuously compare the desired state, as described in the Git repository, with the actual state of the deployment. They correct deviations, ensuring consistency between the intended and actual configurations, much like ensuring every motorcycle built matches the blueprint.

Let automation and reconciliation take the lead

Jose Javier Moya also discussed expanding these principles to cloud environments.

As software and infrastructure grow more complex, the principles of automation and reconciliation extend beyond traditional applications.

In cloud environments, tools like Terraform manage cloud resources using the same configuration principles, adapting these concepts to manage increasingly complex infrastructure and services.

Welcome to the new layers of complexity

Reflecting on the evolution of operations, Moya pointed out that managing systems used to be more straightforward with mainframes and a few servers.

Over time, as systems grew and became more complex, managing them manually became impractical.

Virtualization and cloud computing introduced new layers of complexity, which tools like Git, Jenkins, and ArgoCD now help manage effectively.

The post Build your software like a motorcycle appeared first on ShiftMag.

Not long ago application and API security relied solely on manual methods like knights guarding a castle.

Now, with Agile and DevOps leading the charge and orchestrated ephemeral infrastructure as our new arsenal, we’ve upgraded to a tech-savvy defense, ensuring efficiency and effectiveness like never before.

In this interview, we talk about it with Larry Maccherone, Dev[Sec]Ops Transformation Architect at Contrast Security.

There are almost no dedicated QA departments anymore

“Back in the early days of Agile, I used to advocate for cross-functional teams owning software products, including quality. After these talks, QA professionals would often express concern about their siloed roles, fearing changes if development teams took over quality responsibility, often commenting, “What you said sounds idealistic. It’ll never work at my organization. The developers will just put out crap.”

A decade later, there are almost no dedicated QA departments, and the ones that are left are more of a body shop with all of their people on semi-permanent ‘loan’ to specific dev teams.

Also, we have to remember that back then, developers didn’t do QA the way QA people did QA. “They tried to eliminate all manual testing and replace it with automated testing.”

The DevOps and cloud-native movements were similarly disruptive to traditional IT Ops and were also dominated by automation. Security is now well into a similar tradition which is also marked by more tools deeply integrated into the process.

Shifting the responsibility for security to dev teams

We also asked Larry about the challenges that the industry faces when considering application and API security as a siloed function.

“Siloed functions tend to result in local optimization rather than holistic systems thinking. In systems thinking (referred to as “flow” as the first of three “ways” of DevOps), you try to optimize for value delivery of the entire software development system”, Larry claims.

To get more concrete, Larry says that in a silo, security folks find the vulnerabilities, but they can’t fix them themselves. That leaves them in the position of essentially begging the developers to fix them.

“In this same siloed example, the development teams are measured on how many features they ship. Security is responsible for security. So, the local optimization is to ignore the requests from security to fix the vulnerabilities they found.”

On the other hand, if you shift responsibility for security to the development team, they can optimize for the best overall outcome. Sometimes that means, they can make tradeoffs. At times they might legitimately decide that the risk of not fixing a vulnerability is outweighed by the risk of missing a market opportunity. At other times, they will decide that the security vulnerability fix is the most valuable way to spend their limited resources.

Also, according to Maccherone, developers are prone to automate things, which makes them more efficient overall.

Developers just want their code to be merged

A particular practice that is now universally used by development teams is the pull/merge request. It is the very center of how development teams coordinate their work.

It’s the process of a developer’s morning work reaching the shared codebase by afternoon and ultimately going into production. Almost all automated quality and security checks can (and should) be run prior to the decision to merge that code.

The person clicking on the “merge” button is generally a teammate of the developer for that pull/merge request.

This pull/merge request reviewer, will look at the changes but will also be informed by the automated quality and security checks that were run prior to their review.
Developers are passionate about the code they wrote and want nothing more than for it to be merged. They will see any negative feedback from a security check and respond to it immediately.

Done this way, the vulnerability is often resolved on the same day that it was injected. At this point, the code is very familiar to the developer, so the cost of fixing is an order of magnitude lower, especially when you consider that there was no vulnerability inventory carrying costs.

The situation Larry described above is only possible if each pull/merge request has its own isolated infrastructure for the automated quality and security checks to run.

With traditional methods, having five developers on one team would require maintaining five separate test environments, costly and often idle. Yet, with container-based ephemeral infrastructure, a single developer’s request can spawn multiple workers to conduct quality and security checks simultaneously, completing tasks rapidly and freeing up resources for others.

Technology, practices, and culture

And what about a future Larry sees emerging for application and API security testing?

He emphasized that significant industry transformations, such as the DevOps movement, hinge on three key components: technology, practices, and culture.

In DevOps, ephemeral build and test infrastructure alongside cloud-native technologies represent the technological shifts, while adopting the pull/merge request signifies a change in practices. Culturally, the pivotal shift involves transferring operational responsibilities to the development team.

So, what is the coming revolutionary change for Application and API Security?

It follows the revolution pattern for DevOps, namely those three things – technology, practices, and culture, but it also builds upon the changes that DevOps has brought.

However, before we jump into it, we are going to take a little detour to one discipline that fundamentally changed along with the DevOps movement: performance testing.

Performance testing in production: cheaper, faster, and safer

“Performance testing was long considered a necessary evil. It was expensive and inaccurate, but without it, you ran the risk of having an outage or at least annoyed customers when your application appeared non-responsive.”

Creating a test environment similar to production was necessary, but the closer it mirrored reality, the higher the costs, potentially doubling production expenses.

Then, running extensive automated test scripts in the performance environment incurred high costs, but the real issue was their reliance on artificial traffic, which would lead to inaccurate predictions of real user performance.

“Because of these difficulties, many didn’t even bother with performance testing and took the risk of releasing without it,” Larry says.

Then came technology, practice, and cultural transformations that disrupted the performance testing landscape and avoided all the previous problems. Developers started doing performance testing in production.

The enabling technological change came in the form of application performance monitoring agents that were efficient enough to run in production. The practice change was canary deployments. The cultural shift was realizing that doing performance testing in production was cheaper, faster, and safer than doing it in pre-production when we previously believed you must trade these factors off against each other.

Test your API security in production too

At this point, you might be thinking, “What does this performance testing diversion have to do with the future of application and API security testing?”

Well, what if we can safely accomplish app and API security testing in production?

Doing so avoids the downsides of the current methods:

• SAST’s inaccuracy and long scan times
• DAST and IAST’s poor coverage
• SCA’s lack of context
• WAF’s ineffectiveness

“Like the performance testing of yesteryear, these downsides, along with the cost of licensing, rolling out, and maintaining all of these disparate tools, cause many to skip some or all of them and risk getting hacked. However, to achieve a revolution like this, we’ll need all three elements of the other revolutions: technology, practices, and culture,” Larry emphasizes.

The technological innovation we need is the same as the one we need for the performance testing revolution – agents that are safe and efficient enough to run in production. We’ve been making steady improvements to our IAST agent for years such that it’s an order of magnitude more efficient than it was a few years ago, but we recently beta-released new agents that take a fundamentally different approach when running in production environments, which have improved the efficiency by another order of magnitude.

The practice change is that we need those agents installed by engineering teams in production environments. The cultural transformation is similar to the performance testing one—the conviction that doing application and API security testing in production is cheaper, faster, and more secure than doing it in pre-production.

So, Larry believes we are on the cusp of a revolution in app and API security testing like the one that occurred for performance testing.

The post “Developers should own security. And test in production.” appeared first on ShiftMag.

Maybe you’ve heard that you should automate everything in software testing. Well, it’s not true!

At least, according to Filip Hric, who teaches developers about testing and testers about web developers. In this video, he explains why checking the quality, functionality, and performance of a software product or a feature is crucial and how to approach it.

Filip shares how he would explain testing to a non-engineering colleague, to a product owner or manager, and to a person deciding on a strategy. He also shares some tips on what to automate, what to do manually, and how to balance risks and quality in software development.

This video is a part of ShiftMag’s new video series, Engineer Explains.

We’ve asked experienced engineers to share how they would explain some basic and some less basic tech terminology to different job tech job titles or at three levels of experience – from junior developer to CTO.

This Engineer Explains video was created in partnership with WeAreDevelopers World Congress. Find the tickets here for the next one taking place in Berlin, 17th-19th July.

More:
How would you explain APIs, internal developer platforms, or software architecture at three levels of experience?

The post Engineer Explains: Software testing explained in 3 minutes at 3 levels of expertise appeared first on ShiftMag.

The idea of avoiding testing in production is being challenged lately, and one of the key arguments for it is that staging environments might not be worth it. We pay a lot to set up and maintain an as-close-to-production-as-possible environment, but it might not bring enough value for the cost. 

Using automated local tests to detect issues, delivering features cautiously through feature flags and a/b testing, and even simply having a few bugs slip through to production are mentioned as good enough alternatives not to have to invest in a staging environment.

However, thinking that a staging environment is unnecessary might stem from working on smaller-scale systems that can tolerate outages and issues or from working with a bad staging environment.

Working without staging environments 

Localized testing can only get us far when working on a complex system. We need to know that all the pieces fall into place to ensure that things keep working as expected. We don’t truly validate our code without booting up the many other (micro)services and doing proper end-to-end system testing.

Feature flags are a great solution, but they introduce some complexity, especially if they pile up and get left in the code for too long. Plus, they might get misconfigured if our feature touches on many parts of the system.

If we interact with plenty of third-party services, setting it all up from a local testing setup is difficult. Then, you have to consider the security concerns some clients might have. Ensuring secure access from one point is much easier than a whole network.

Bad staging environments 

A poorly designed staging environment doesn’t test our product in its real ecosystem, where it interacts with both our own services and any third-party systems it relies on. If the staging environment is designed that way, we might as well rely only on local testing.

It’s not much better when a staging environment only has simple emulations of other systems. If we simplify the results we expect to receive whenever we call another service, we lose a valuable chance to test compatibility and real-world interactions before we hit production.

Suppose we don’t automate testing of key business processes and only rely on developers to check the areas they impacted manually. In that case, we risk introducing breaking changes into our critical and high-traffic systems.

A bad staging environment only has bits of testing data present in it. If we don’t work with real production amounts of data, we can end up not realizing how our changes impact usability. If we only test loading a few entries, we can miss issues introduced when millions of entries need to be loaded.

Potential staging environment problems

Developers should not become more lenient and trust that their testing environment (and their testers, of course) would catch all errors. It would be truly impressive if we could create a staging environment so good that developers would trust it to that extent. A good staging environment shouldn’t mean developers can be less vigilant. 

Another issue could be developers queuing up for their turn to test things. Good use of separate instances and load balancers can ensure people don’t queue for too long and that other people can continue to use stable releases while someone tests their new changes.

Even with all this, a bug will make it to production one day. But, striving for perfection is not a good enough excuse to reject staging environments. We can’t create a perfect staging environment, but we should still aim for one as good as possible. 

Staging environments benefits

A good and appropriately used staging environment can save much more time and money than it takes to create and maintain.

The value of a good staging environment comes from:

• Being able to test any use case at any time without touching production
• Demonstrating functionality at any time, which can also serve product managers, designers, and clients alike.
• Having a playground that everyone can learn with. Developers can take in information much better if they can see existing code in reality.

What works for some doesn’t work for all, and products have different requirements and levels of responsibility. 

Sometimes, it’s better to keep it simple. Other times, keeping it simple could result in costly outages. And a good staging environment can prevent them.

The post Staging environments are costly. Bugs in production are costlier. appeared first on ShiftMag.