Beefy Boxes and Bandwidth Generously Provided by pair Networks
go ahead... be a heretic

Re: Testing IS Development

by ack (Deacon)
on Mar 13, 2009 at 18:45 UTC ( #750496=note: print w/replies, xml ) Need Help??

in reply to Testing IS Development

Wow! Great post and a great thread from everyone! I have been in a bit of a challenge lately at work trying to help our leadership find better...but minimally intrusive...strategies for producing better systems (especially flight software systems).

We always produce a large, strategic suite of tests (we call them, somewhat conventionally, Baseline Functional Tests (BFTs)) that are developed once the code and hardware are produced and have been through module- or subsystem-level testing. In short, our tests always "follow" after our development.

The price seems to consistently be twofold: (1) we seem to find it hit-n-miss finding "big" errors and (2) we have to go back and make significant changes to our tests after we fix the errors.

This results in quite a bit or wasted time (in my opinion) and leaves our leadership wondering "did we find enough of the big errors?"

I have read a number of posts over the past couple of years here and had been somewhat swirling around the notion tha perhaps a more test-driven development approach would help. The comment that ...Initial code-writing took about twice as long as before. Overall development time was far less is actually at the heart of almost every discussion I've had around here on the matter: the fear that things will take so much longer. But your sub-comment on overall development time is at the heart of what I've been thinkking and your articulation of that point strengthens my resolve.

This post and subsequent thread has renewed my thinking and strengthened my resolve to move more aggressively in this direction to see what it brings.

Thanks to everyone for the great dialog; it really the Monks always do.

ack Albuquerque, NM

Replies are listed 'Best First'.
Re^2: Testing IS Development
by sundialsvc4 (Abbot) on Mar 18, 2009 at 22:40 UTC

    It was, to “lil” ol” me,” absolutely staggering what a (positive) difference it made.

    It really felt to me like I had just wandered into the hunting-fields for the very first time with a really good hunting dog. :-D

    “Wow! How'd all those pheasants get in here?!”

    The rigorous, early testing-process flushed out an unbelievable number of errors. But it also made the resulting code much more reliable.

    When we're in school, we're taught a lot about data structures, but we're really not taught about ... code structures! Animators and engineers know about the concept of “degrees of freedom,” but we neglect to teach software engineers that exactly the same concept applies to their work ... only “eversomuch more-so.”

    Any “unanticipated movement,” lurking anywhere in the moving-parts-laden structures that we universally build, has the potential to de-stabilize the whole thing, and to express its movement in any number of well-concealed indirect ways. Only by systematically ferreting out these “movements” early, under (admittedly artificial) conditions designed to minimize the number of moving-parts that might have been layered on top of them, can we ever hope to say ... with any degree of assurance ... that “even though I do not yet know what is causing this problem, I can say that it probably isn't this-or-that.” Otherwise we spend too much time trying to deduce where the problem(s) actually lie.

    Fixing them, once we find them, is usually trivial. But by then, the economic damage has already been done.

Log In?

What's my password?
Create A New User
Node Status?
node history
Node Type: note [id://750496]
and all is quiet...

How do I use this? | Other CB clients
Other Users?
Others meditating upon the Monastery: (7)
As of 2018-02-21 21:07 GMT
Find Nodes?
    Voting Booth?
    When it is dark outside I am happiest to see ...

    Results (288 votes). Check out past polls.