Big News: FounderDating is joining OneVest to build the largest community for entrepreneurs. Details here
Latest Notifications
You have no recent recommendations.
Name
Title
 
MiniBio
FOLLOW
Title
 Followers
FOLLOW TOPIC

Question goes here

1,300 Followers

  • Name
    Entrepreneur
  • Name
    Entrepreneur
  • Name
    Entrepreneur
  • Name
    Entrepreneur
  • Name
    Entrepreneur
  • Name
    Entrepreneur
  • Name
    Entrepreneur
  • Name
    Entrepreneur

Should developers be testing their own code?

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?

21 Replies

David Matousek
1
0
David Matousek Entrepreneur
Director, Mobile Development Manager at John Hancock Financial Services
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!
Art Yerkes
2
0
Art Yerkes Entrepreneur
Computer Software Professional
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.
Robert Gezelter
0
1
Robert Gezelter Entrepreneur
Principal, Robert Gezelter Software Consultant
It depends upon the level of testing and the organization. QA testing in a large organization is an specialized activity. Ordinary debugging is generally a task for which the individual developer is responsible. Where the dividing line rests depends on a variety of factors. In many cases the goal should be for the developer (or team) to have eliminated all errors, with QA verifying that requirements are indeed met. How well individuals and teams meet this goal can be a different matter.
Yvan Pearson
1
0
Yvan Pearson Entrepreneur
Embedded Software Engineer at NK Labs, LLC
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.
Ted Rogers
4
0
Ted Rogers Entrepreneur
Mobile Architect + Developer
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.
2
1
X
Entrepreneur

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.


Kerry Davis
1
0
Kerry Davis Entrepreneur
CEO / Founder at AirBridgeLabs
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.
Michael Barnathan
1
0
Michael Barnathan Entrepreneur • Advisor
Co-Founder of The Mountaintop Program, Google Alum
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.
Edward Robertshaw
1
2
Started TinyCall
Unless you want to have bugs in production EVERYONE should be testing and understand the product at some level. Hunt down the key causes of your bugs (rushed development, lack of automated tests, poor spec, etc) and find ways to resolve them.

FIRE any programmer who can't or wont test their code and strive for zero defects in production. In addition have a QA process to ensure the bugs that get missed by developers don't make it to production. Make sure any bug that makes it into production is analyzed and that you write automated test to ensure bugs you fix never come back.

Go slow if you want to go fast in the long run.
Mark Dostie
0
0
Mark Dostie Entrepreneur • Advisor
CTO of Artificial Intelligence Dev
Developers doing unit testing is a must and in fact in my organizations we often rotate developers into the Integration and Test side so they can see the results of poor unit testing and failures in interface contract implementations. In my experience it makes them much better developers. QA of course is layered on top of this and helps ensure the unit tests are providing coverage and boundary testing. In more pure Agile development the tests are actually developed first (and fail since there is no code) and the developer has to develop to validate the tests before it can exit unit testing.
Join FounderDating to participate in the discussion
Nothing gets posted to LinkedIn and your information will not be shared.

Just a few more details please.

DO: Start a discussion, share a resource, or ask a question related to entrepreneurship.
DON'T: Post about prohibited topics such as recruiting, cofounder wanted, check out my product
or feedback on the FD site (you can send this to us directly info@founderdating.com).
See the Community Code of Conduct for more details.

Title

Give your question or discussion topic a great title, make it catchy and succinct.

Details

Make sure what you're about to say is specific and relevant - you'll get better responses.

Topics

Tag your discussion so you get more relevant responses.

Question goes here

1,300 Followers

  • Name
    Details
  • Name
    Details
  • Name
    Details
  • Name
    Details
  • Name
    Details
  • Name
    Details
  • Name
    Details
  • Name
    Details
Know someone who should answer this question? Enter their email below
Stay current and follow these discussion topics?