The value of developer testing before QA

Quality Assurance (QA) is a vital part of the site optimization process. Testing and refining code before launching it live can save merchants headaches and customer satisfaction by preventing mistakes and defects before the site goes live.

At LYONSCG, QA is a core portion of our implementation process. Before any code gets to QA, though, Commerce Implementation group management encourages developers to check their code. This saves the QA team’s time and expedites our launch processes. But, besides saving QA’s time, why else is this a valuable practice?

Assuring Quality Throughout the Process

The point of QA is to ensure accurate, up-to-spec code, not identify and solve every single issue within the code. If the quality of the code at QA or at launch does not meet client expectations, it is up to both QA and the developer to look at where the problems are. The problem might be with the developer’s buggy code, but it could just as well be, for example, a fragile third-party package or unclear or unstable set of requirements. Not every code issue that we find in QA is as simple as developer error!

What to Look For

To enable QA to not just find but understand the source of any errors, here is a prioritized list of what the developer should test before handing off their code to QA:

• The product still builds.
• The product still installs.
• The ‘smoke test’ passes, i.e. the parts of the product that essential to the most fundamental kinds of testing still work.
• The most positive obvious test cases (by whatever definition is available) all work. In other words, if you are just trying to use the product, it should work.
• The negative test cases (use cases) all work. In other words, if someone tries to break the product, they can’t.

When I get a build, I expect the code to be tested at a unit and manual test level to check over the basics. This means that when I enter some basic boundary value checks, the code doesn’t fall over. For example: if a field accepts 0-100, then it should undoubtedly handle values 101 and -1.

That’s a simple example. I think when people say that the developers should not test their own code, they are referring to the traditional testing phase, normally done by trained testers. That doesn’t mean that developers shouldn’t test at the unit level, though. I also encourage manual testing as well, even just to check that the code performs the basics and to check front end UI work.

A responsible developer should write unit tests, integration tests (if possible) and definitely manually test for basic functionality. The problem, though, is that testing code written by a developer might not turn out to be as effective as a second set of eyes. This is mainly due to the fact that developers are familiar with their own code and may have their own assumptions as to how it will work.

On the other hand, a professional tester does not have these preconceived assumptions and can often find defects a developer may not find. A good tester will also check edge cases, usability and a whole host of interesting areas beyond the scope of an individual developer.

If Developers Test Their Own Code, Is QA Necessary?

So, if developers should test their own code, do you actually need QA? Yes. It comes down to the specific skills and mindset of a good QA team.

Even the best developers in the world will write buggy code every now and again. The issue, as we mentioned earlier, is that they aren’t as good at actually finding these bugs. Even if developers test each other’s code, they don’t have the kind of software-breaking thinking and skills that solid QA teams do.

Further, developers are usually a touch more removed from the user experience, while QA is much closer to it, thus finding “insignificant” bugs that developers may ignore altogether, or worse, bugs in the software design – which is crucial for eCommerce sites. Obviously, this process works better with developers who enjoy critiquing their own code.

It is the tester’s primary responsibility to make sure each and every path is tested properly. Testers should ideally give importance to all possible details, to verify that the system is not breaking anywhere. This helps expedite the system-testing phase as all basic paths have been thoroughly vetted.

Additionally, as obvious as it sounds, I would encourage developers to clearly inform testers of all changes that they make to their code (no matter how small). There have been countless times when new features have been implemented, but because the relevant work items were never updated with specific enough details, I never knew that the new feature existed until I stumbled across it by accident during exploratory testing.

In conclusion, for any software project to be successful, there should be an independent testing team validating all aspects of the application. At the same time, developer code reviews can go a long way towards expediting these testing phases and delivering functional code that delights clients and customers.