Explore our latest thought leadership, ideas, and insights on the issues that are shaping the future of business and society.
Choose a partner with intimate knowledge of your industry and first-hand experience of defining its future.
Discover our portfolio – constantly evolving to keep pace with the ever-changing needs of our clients.
Become part of a diverse collective of free-thinkers, entrepreneurs and experts – and help us to make a difference.
See our latest news, and stories from across the business, and explore our archives.
We are a global leader in partnering with companies to transform and manage their business by harnessing the power of technology.
Our number one ranked think-tank
Explore our brands
Explore our technology partners
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?
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!
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:
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.
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.
You may accept all cookies, or choose to manage them individually. You can change your settings at any time by clicking Cookie Settings available in the footer of every page.