Software Engineering · Engineering management

Should developers be testing their own code?

Rohit Mittal Data Scientist at Popsugar

January 21st, 2015

There is a lot of debate as to what degree of testing developers should do for their own code. On the one hand it can waste their time, on the other hand it can waste other's time. Should they be responsible for testing their own code and if so, how do you keep them accountable?

Ted Rogers

January 21st, 2015

Developers should absolutely be testing.  Testing your software is one of the most important steps in doing software development.  Ideally, the developer would write unit tests to test their software as well as manual testing. 
As @David Matousek said automated testing is great but not always a luxury everybody has the time or resources to setup.  Your QA resource and/or Product Owner should also testing to make sure the features work like they are supposed to and find bugs the developer did not.
Also, as a company that is just starting out, it is likely the software developers are some of the busiest ones in the company, so may need additional testing help to get MVP's working as quickly as possible.

Lalit Sarna Business & Technology Leader

January 21st, 2015

QA's job is to stress test, basic fidelity should always be developers responsibility.  It is a no brainer on so many levels.

If a developer thinks that unit testing his code is a waste of time, it's best you give them a generous severance package and save your team.  Sorry if this sounds harsh. 

Regarding accountability :

Culture is the key . Peer pressure and transparency is about the only thing that sustains. 
All other methods of enforcement will eventually fail. 

Bad apples should not be tolerated. 1 B player is enough to spoil the entire team. 

People slip from time to time, and that is ok. Given them plenty of room to make mistakes  with clear feedback on how to improve and what you expect. 

If they are unable to improve, then help them find a place where they can thrive. 



 

Art Yerkes Computer Software Professional

January 21st, 2015

Developers likely shouldn't be coming up with integration scenarios and carrying out in situ testing of the final product.  They should be writing real units and real unit tests for their own code, as this is the principle way in which the code can be exercised before it gets to production.  Designing software for testability also makes isolating failures and making later changes much easier, so I wholeheartedly recommend the practice of designing for testability and writing tests.

If your developers are having trouble writing at least basic tests, then they probably aren't designing testable code.

Anonymous

January 21st, 2015


Until you are large enough to get very specialized & make a conscious choice to employ specialist QA people (which there are good arguments against, BTW) then the answer to your first question is: of COURSE developers should test their code. In what other field would you consider a job "done" if the delivered artifact didn't work?

To your second question, how to hold them accountable: if you find that you need to hold them accountable, fire them and hire someone else. A small business can't afford to employ people who don't take responsibility for their work and/or don't want to do a quality job.


Michael Barnathan

January 21st, 2015

Developers should absolutely be responsible for their own code, and that includes testing it. Not writing tests wastes more time than writing them in the long run for any nontrivial project. Especially if your alternative to a good automated test suite is more manual testing. As for how to keep them accountable, other developers. Testing should be part of the development culture, and budgeted for in product estimates. A dedicated QA team is a supplement for developer testing, not a replacement for it. You can use metrics such as code coverage, but I'd be wary of relying too much on them. I've seen lots of code "100% covered" by poorly written smoke tests that don't actually exercise any of the conditions they're supposedly checking. I've also seen tests become very pedantic ("check that the plus operator adds correctly") in an attempt to get full coverage.

David Matousek Director, Mobile Development Manager at John Hancock Financial Services

January 21st, 2015

First of all, testing code is NOT a waste of time no matter who is doing it.  Ideally, the developers should be doing some testing, but a using an automated test system is ideal.  Follow continuous delivery best practices.

In small startups, everyone should be using and testing the application as much as possible.

But the product owners and founders are responsible to ensure only quality products ship.  They should be testing!

Kerry Davis

January 21st, 2015

The question is a bit vague because there are many forms of testing. There are three basic forms of software testing.

  1. Unit testing where the code under test is a new feature add or bug fix (aka unit) of the entire body of code
  2. Integration testing where you want to make sure the new feature / bug fix plays well with other parts of the code
  3. Regression/Stress testing which ensures the code is not only backward compatible under different operating environments but can also function well under an extreme load or system delays.

Assuming your are talking about a single developer, where they are the only one on the project for the next release, then absolutely yes to all of the above. However, if you are referring to a team effort of an ongoing project expected to operate on many different operating environments (hardware and software and network conditions). Then it is quite possible that only Unit Testing (and maybe integration) is the most efficient course and a separate release testing team should be handling Regression, Stress and Integration testing.

Yvan Pearson

January 21st, 2015

Testing is not a waste of time. Finding bugs early is a lot cheaper to fix than fixing bugs in the field. Manually and/or automated testing should be mandatory, including unit testing or black box testing. Someone who believes testing isn't important shouldn't be writing software.

Anonymous

January 21st, 2015

Developers should absolutely be testing their own code, and repeatedly, to make sure bugs do not end up in production. But one of the key tenets of quality assurance is attention to detail; covering all the details can be a meticulous task that takes a lot of time. 

When bugs end up in production, it is likely that:
  1. Not enough time or resources is being allocated to the testing phase of the development cycle
  2. Code is being deployed to production without an automated safeguard such as unit/integration tests that should run before every deployment
  3. Lack of specification or understanding on expected behaviour
  4. Lack of stress/regression testing

Aldo Pahor .NET/SQL Developer at Barclays Capital

January 23rd, 2015

In every software engineering book, testers and developers are two very different roles and professions with very different mindset.


Developer: How can I build that?
Tester: How can I broke that?


This is because since the begining of time it was obeserved that the developer is not able to find all the bugs in his code.
If you think a bit it is obvious why. The builder will never ship a critical bug if he knows the bug exists.


With time, tools, practices and roles were introduced to improve the sw quality.


Of all, unit tests are the most misleading. With Unit Tests, Developer first write a test that fails than the smallest piece of code to fix it. It is a building - not a testing - process.They are tests meant to build small units of sw which addded up will lead to a complete sw. Their value is firstly for the developers, a safty net for future changes code as the tests will be rerun automatically (this is Continous Integreation) after every change in the code and show any break.


It is true that this improves the quality but assuming this will lead to bug free sw is a sign of immaturity.

Testers and QA are big cost, not everyone can afford it and is not always necessary, BUT NEVER EXPECT THAT DEVELOPER WILL FIND HIS OWN BUGS.