• The Four Hundred
  • Subscribe
  • Media Kit
  • Contributors
  • About Us
  • Contact
Menu
  • The Four Hundred
  • Subscribe
  • Media Kit
  • Contributors
  • About Us
  • Contact
  • Newsflash: Developers Hate to Test Their Software

    June 21, 2010 Timothy Prickett Morgan

    There are some things that transcend platform differences. All computers wait at the same speed. All projects come in over budget and beyond their projected windows. Sometimes people change things for the sake of change and for no damned good other reason. And, according to a recent survey, application software developers hate to test their code.

    So why not do what the computers do best and automate the testing? Well, because programmers are artists as much as they are techies, and they all have their own ways of writing code and therefore their own methods for testing code. What’s an IT organization to do? First, they have to admit there is a problem and then seek help.

    A Silicon Valley firm called Electric Cloud sells cloud-based tools to help developers test their wares, and obviously needed a better sense of what companies were doing, or not doing, when it comes to testing applications. And so it commissioned Osterman Research to survey some big IT shops in North America who have at least 1,000 employees and at least 50 developers to get some insight.

    The researcher was able to get developers, testers, managers, and executives at 144 companies to spill the testing beans, and found that only 12 percent of those polled had completely automated their application testing regimens. Another 10 percent said that all of their testing was done manually. Here. In 2010. Some 46 percent of the software developers polled said they knew they did not have as much time to test their code as they knew they should (and no one in the news business has time to read what they write, or to think before they write, or to have someone else carefully edit and polish what they write, so I am not throwing stones here) and 36 reported that they don’t think their companies do enough pre-release testing of applications. Of those polled, 56 percent said that bugs found late in the development cycle almost always messed with product release dates; 44 percent of those talking to Osterman on behalf of Electric Cloud said their last big bug had an average cost of $250,000 in lost revenue and took 20 developer hours to correct.

    Now here’s the kicker: The developers who say they have enough time to test their applications before they are released report they spend half as much time–an average of 12 developer-hours–fixing bugs compared to those who feel they are coding by the seat of their pants, who reported they spend 25 developer-hours fixing the average bug.

    Looks like either way, you pay. Time does indeed equal money, as Einstein proved in his as-yet unpublished grand unified theory.

    RELATED STORIES

    ARCAD Opens ALM Suite a Little More

    MKS Adds Test Management to ALM Suite

    The Fallacy of Automated Testing, and an Original Solution

    Original Teams with Green Hat for SOA App Testing



                         Post this story to del.icio.us
                   Post this story to Digg
        Post this story to Slashdot

    Share this:

    • Share on Reddit (Opens in new window) Reddit
    • Share on Facebook (Opens in new window) Facebook
    • Share on LinkedIn (Opens in new window) LinkedIn
    • Share on X (Opens in new window) X
    • Email a link to a friend (Opens in new window) Email

    Tags: Tags: mtfh_rc, Volume 19, Number 23 -- June 21, 2010

    Sponsored by
    JAMS Software

    One Scheduler. IBM i, Windows, Linux, and More.

    IBM i teams trust JAMS to schedule and orchestrate jobs across every platform in their environment. Centralized visibility, cross-platform dependency management, and alerts that reach the right person before the business feels it.

    Fewer than 5% of IBM i shops run IBM i only. The rest are managing cross-platform dependencies — often without a clear picture of how they connect. JAMS draws that map, enforces those dependencies automatically, and gives your team a single place to monitor, manage, and recover when something goes wrong.

    If you are running hundreds of CL scripts and custom RPG processes, bring them as-is. JAMS runs them exactly as they do today — except now they are visible, monitored, and part of an orchestrated workflow instead of scattered across folders only one person knows about.

    No consumption-based pricing. No surprise bills when your workload spikes. You pay based on how many machines JAMS talks to — that’s it.

    Learn More → https://jamsscheduler.com/lp/ibm-i

    Share this:

    • Share on Reddit (Opens in new window) Reddit
    • Share on Facebook (Opens in new window) Facebook
    • Share on LinkedIn (Opens in new window) LinkedIn
    • Share on X (Opens in new window) X
    • Email a link to a friend (Opens in new window) Email

    IBM Chops Maintenance on a Whole Bunch of Old Stuff Original Launches Overarching Tool for Quality Management

    Leave a ReplyCancel reply

TFH Volume: 19 Issue: 23

This Issue Sponsored By

    Table of Contents

    • i/OS 7.1 Marks a Change in the JVM Guard
    • The AS/400 at 22: Yesterday and Forever
    • IBM Adds Power7 Boxes to Trade-In Deals
    • As I See It: Against All Currents
    • SaaS Surfs the Cash Conservation Wave
    • JDA Software’s i2 Unit Smacked with $246 Million Judgment
    • Another Indicator Says the IT Job Market Is Improving
    • Disk Array Sales Are Spinning Up, Says IDC
    • IBM Chops Maintenance on a Whole Bunch of Old Stuff
    • Newsflash: Developers Hate to Test Their Software

    Content archive

    • The Four Hundred
    • Four Hundred Stuff
    • Four Hundred Guru

    Recent Posts

    • IBM i PTF Guide, Volume 28, Number 28: A Crazy Number of Security Vulnerability Patches
    • Inside The Encryption Key Management Changes In IBM i 7.6
    • FalconStor Moved To The Blue Lagoon, And Is Poised For Growth Because Of It
    • Guru: Claude’s SQL Tip
    • Astera Makes Extracting Legacy Report Data an AI Specialty
    • IBM i PTF Guide, Volume 28, Number 27
    • Welcoming The New IBM i Chief Architect And Other New Top Brass
    • A Deep Dive Into That Power S1112 Entry Power11 Server
    • Guru: Beyond Three-Part Naming – Running SQL Across Remote IBM i Systems
    • How IBM Bolstered IBM i Resilience In The Summer Tech Refreshes

    Subscribe

    To get news from IT Jungle sent to your inbox every week, subscribe to our newsletter.

    Pages

    • About Us
    • Contact
    • Contributors
    • Four Hundred Monitor
    • IBM i PTF Guide
    • Media Kit
    • Subscribe

    Search

    Copyright © 2025 IT Jungle