Let's start with stating that the majority of developers don’t fully test their own code, usually because they are backed up by QA testers. It's easier to allow QA testers to use their time to find defects rather than spending the time testing it themselves. Maybe they are too busy or the company prefers this method and to have their dev team churning out tasks. There’s also an arrogant aspect at play potentially, as some developers believe their work is without flaws but this could (and has) lead to serious problems that affect business.
With many dev teams testing their own work and not using QA testers, this topic inspires a heated debate from both sides. I’m going to cover both sides, and hopefully help you understand the strengths and weaknesses from both approaches.
Let's start with developer-based testing:
Most teams (I believe) do require its developers to run unit testing (at least) and many also require automated, integrated, code-based tests. The problem is that this does take time away from working on new features and code and we as developers are attracted to the next shiny thing to work on. Testing could be built-in if it covers the entire codebase but again this takes time away from new tasks.
In some ways these developers are correct in saying that testing can waste time, even if the testing process is automated. Testing can be seen to slow down the development and productivity.
Another reason testing is not done is purely because some developers don’t have an understanding of how the entire application works. Or they don’t believe mistakes exist in their code, arrogant I know but we’ve all met people like this, in some cases they are actual colleagues.
On the other side there are many developers who rigorously test their code using coded tests. A sense of pride in their work means they want to fully test their own work to ensure its defect free, or at least to ensure that any QA testers don’t find faults or defects in their code. Pride, is should be noted is seen as one of the sins of developers :)
Personally, I don't enjoy testing because i find it boring and repetitive. And i know many who think the same but we need to ensure that developer testing can be a productive part of your QA.
QA-based testing
On the QA side I have a lot of respect for QA tests because it takes balls to question a developer's work and deal with any defensiveness that can come back. There are some very good QA testers out there doing a great job but the best ones need to be confident when reporting bugs to the dev team.
They also tend to have much more knowledge of the application in its entirety with all its nuances, including regression history. I think they also help to ensure the developers are honest and hard working, because in some ways they are covering the work on a dev manager testing and providing oversight of the entire development process.
As their job is based on finding faults, QA testers push an application harder than a developer. A simple test and success will not be enough as they seek ways creatively to execute tests that may not occur to the developer. Proof is everything and bugs are not fixed unless proven, something many developers don’t go far enough when testing their own code.
Developers and QA testers should, of course, work in conjunction with each other. Code testing works well but a QA tester can run more human tests that are unexpected and ensure the application is more robust.
Another aspect of QA is the creative side, most of us see testing as boring repetitive work but from dealing with QA testers i’ve realised that creativity is an important part of the QA process. Based on their knowledge they can think of many different ways to test an application and compare to previous testing. Documentation created from testing is super useful for training and even in some cases for client usage.
So which is better?
The answer is neither, a combination of both approaches works best. With many Dev teams constantly and quickly releasing code there is a need for QA to play its part. I understand that speed to market is a crucial factor but stability is also key to success.
Another aspect i see is companies outsourcing their QA rather than having it run inhouse and together with the dev team. Several new businesses such as Global and Digivante are some of the companies where outsourcing QA or crowd testing is growing. I do understand the hole they fill in the space but is it a good move for companies to outsource QA testing?
Top comments (3)
Unit tests yes, integration tests no. Most places I’ve worked at we had a “QA Engineer” that wrote integration tests. It’s too time consuming like you said. Testing is a full time job.
I think devs should be responsible for unit and integration tests. If your company has QA engineers than they should do e2e testing, otherwise devs should also write a few e2e tests.
But the important part is that you have automated tests, don’t matter who wrote them 😉
Thanks for writing this and opening the discussion. I agree with you in that it should be a combination of both approaches. Too many times, I've felt like developers think of QA as a second class citizen. I've been refered to as "oh he's just QA..." as if we were beneath them. Ironic because it's often us "mere QA" folks who catch potential issues and make the company and product be the best it can be. It's also funny how a "mere QA person" at times can school a developer on how a lot of issues can be avoided with simple tests and caught earlier rather than later. I remember some things taught in some introductory computer science courses (at least the ones I took) was the concept of defensive coding. Yet that concept seemed foreign to a so-called senior level developer. The more issues we caught before release, the better everyone looks. QA are your colleagues and peers supporting you, the company, and the clients. Let's stop the arrogance.
From the developer standpoint, I would be one of the ones who write coded tests as I develop, and often think of test cases to watch out for as I go. This, in my opinion, while it can be sometimes boring and tedious, overall leads to higher quality and confidence that the build/code is good. That's not to say it's perfect. I am guilty of wanting to skip writing tests sometimes just as anyone else. It takes discipline, but results in better quality in the end. From what I've seen, a developer can be brilliant in what they create, but in the end, we are still human and sometimes a 3rd party perspective can lead to unexpected conditions that may negatively impact the project/application. I've not met a developer that was so brilliant that there was never a bug or any edge cases that weren't already considered and handled.
This is why we still need QA and developers working together and respecting what each other do, because we have a common goal to have a good release of quality software. Designing and developing software is as much a full time job as is good testing and QA. Some might even go so far as to say QA is often more difficult. The way I see it, each side has its own challenges. Let's all work together for the common good.