IWETHEY v. 0.3.0 | TODO
1,095 registered users | 0 active users | 0 LpH | Statistics
Login | Create New User
IWETHEY Banner

Welcome to IWETHEY!

New Argument strength
"Well he should have noticed sooner how shitty my code was," doesn't sound like a really strong argument.


Developers can't test their own code. While you are writing code, your code is conditioning you to a particular behavior pattern. You know exactly the path of behavior you are expecting, you code for it, and in turn the code behaves properly when used just this way which rewards you and so that's the only way you interact with the program.

You might think of a couple error scenarios and nail them. But it is a well known phenomenon that most developer tested code won't last 60 seconds in the hands of a typical user.

This is why you can't test anything for very long either, you will become trained by the software to behave the way the software expects after just a little while. So you need to swap modules around your team so none of them get too familiar with what they are testing.

Because familiarity breeds bugs.



"Whenever you find you are on the side of the majority, it is time to pause and reflect"   --Mark Twain

"The significant problems we face cannot be solved at the same level of thinking we were at when we created them."   --Albert Einstein

"This is still a dangerous world. It's a world of madmen and uncertainty and potential mental losses."   --George W. Bush
New Isn't that statement too strong?
I thought "unit tests" were supposed to address this issue.

If you're talking about GUI testing, I agree. But then our friend Mr. Ubernostrum might argue that that's still too strong (i.e. that with proper guidelines, a lot of UI issues go away).

I think that it's clear that separate testing is required, but that good development practices with good tools should allow developers to test their own code with good results.

Am I mistaken?

Cheers,
Scott.
(Who's not a developer.)
New You're both right
Good procedures should make it possible for a developer to mostly test his own code. But you could spend days figuring out every possible date format and develop a way to test for it, and you wouldn't think someone would enter "the day after Bob's birthday" for the delivery date.

The point about familiarity is also very true. We just hired two QA people at my soon-to-be-former job. After I reviewed a new spec, I would submit it to them. I knew that, having been to so many of the planning meetings, I knew what they really meant. I needed a second set of eyes to tell me if that's what they really said.
===

Purveyor of Doc Hope's [link|http://DocHope.com|fresh-baked dog biscuits and pet treats].
[link|http://DocHope.com|http://DocHope.com]
New Not entirely mistaken
Developers do unit test, but for the problems that they forsee. There are a lot of corner cases and variants on a theme that might not occur to the developer. Those are what system test is supposed to find. Unit test mainly picks up the mainstream faults. I know that system test has found problems with my stuff doing things that I never imagined.
New Well...that true, if
..they write the test after they write a given function. If they write the test before they write the function, the module tends to work properly for the input that conforms to the expected cases, and tends to fail (gracefully) for everything else...which is sort of what you'd expect from a properly written module.

And one tends to hope that input of the form, "the day before Bob's birthday," is not in the set of expected cases....
jb4
shrub\ufffdbish (Am., from shrub + rubbish, after the derisive name for America's 43 president; 2003) n. 1. a form of nonsensical political doubletalk wherein the speaker attempts to defend the indefensible by lying, obfuscation, or otherwise misstating the facts; GIBBERISH. 2. any of a collection of utterances from America's putative 43rd president. cf. BULLSHIT

New Developers. Testing. Same sentence.
Heehee!

I find your faith in humanity touching, AScott :-)

"Yeah, I've tested $CODE_MODULE"

"So why doesn't it compile?"

^^ Actual overheard conversation at work.


Peter
[link|http://www.ubuntulinux.org|Ubuntu Linux]
[link|http://www.kuro5hin.org|There is no K5 Cabal]
[link|http://guildenstern.dyndns.org|Home]
Use P2P for legitimate purposes!
New Actual conversation *had* at work
"Okay, it's ready to stage."

But I just saw you modify the file and commit it.

"It was only a minor change."

You didn't even check for syntax errors.

[checks for syntax errors]

"See? It's fine."

[sigh]
===

Purveyor of Doc Hope's [link|http://DocHope.com|fresh-baked dog biscuits and pet treats].
[link|http://DocHope.com|http://DocHope.com]
New Preach it, brother.


Peter
[link|http://www.ubuntulinux.org|Ubuntu Linux]
[link|http://www.kuro5hin.org|There is no K5 Cabal]
[link|http://guildenstern.dyndns.org|Home]
Use P2P for legitimate purposes!
New While I'm on the topic
Another conversation I had at work recently involved rushing code out the door. We've done much too much of it. But we're facing two goals: get it done now, and get it done right. If you delay it long enough to do sufficient testing, you know you'll catch shit for not having it done fast. If you rush it out the door, you might catch shit at some future time for it being wrong.

Eventually, you have to learn that once you've rushed it out the door, the customer can dissect it at their leisure. And when they do eventually find that bug -- and they will -- it won't help to tell them they didn't give you enough time. They'll ask why you didn't tell them you needed more time.

I've tried asking, "Do you want it now, or do you want it right?" That doesn't seem to help either. Oh, and the reason we keep rushing reports out the door? Our customer has a reporting department that is larger than our entire IT department. They have all the same data we do. But they say that it will take at least four weeks from the initial request to produce a finished report. So when they want a report for a meeting that starts in two hours, they call us and tell us to shit some numbers, fast, and they'd better be right.
===

Purveyor of Doc Hope's [link|http://DocHope.com|fresh-baked dog biscuits and pet treats].
[link|http://DocHope.com|http://DocHope.com]
New You worked for the Pentagon, right? _____________________;-j
New I have to deal with that all the time >:-P
Especially from the developers in Bombay.
[link|http://www.runningworks.com|
]
Imric's Tips for Living
  • Paranoia Is a Survival Trait
  • Pessimists are never disappointed - but sometimes, if they are very lucky, they can be pleasantly surprised...
  • Even though everyone is out to get you, it doesn't matter unless you let them win.


Nothing is as simple as it seems in the beginning,
As hopeless as it seems in the middle,
Or as finished as it seems in the end.
 
 
New Heh. Ben didn't call me Pollyanna for nothing. :-)
New You are, indeed, mistaken
Developers usually have a lot emotionally vested in their code. This makes them the absolute last person that you want to have testing code.

The best person to test code is someone who actively wants to find problems.

Cheers,
Ben
I have come to believe that idealism without discipline is a quick road to disaster, while discipline without idealism is pointless. -- Aaron Ward (my brother)
New That's *one* of the people you want testing
People who want to find errors will tend to look for the type of things programmers don't like worrying about, like validating all user input. Tedious be necessary. But a good programmer will eventually learn that it has to be done, if for no other reason than that the tester will catch it.

The ones you want are the "random strangeness" people. The ones who will do something completely unanticipated. The things that even an experienced tester would never imagine someone would try to do. The ones who are so thick they will continue to do things you've told them not to do. In other words, a user.

Which leads to another actual conversation I had, just last week.

There is a customer account configuration module. One of the options in it is a checkbox marked "Inactive". If this box is checked, the customer can still log on to the extranet to track the status of their live orders, but they can not place any new orders. Internal usres also can not place new orders for the customer on the intranet.

We have a request from accounting to add an option for "Do Not Invoice". This was driven from an incident where there was a legal action with one of our soon-to-be former customers. The billing person contacted all the field offices and told them they had 30 days to process any outstanding invoicing and submit it. A final bill would be submitted, and the customer would be inactivated. Thirty days later, the bill is submitted, and the customer is inactivated. Then a user notices an unreleased invoice and releases it. Billing catches it, but wants a way to prevent this problem.

So far it seems strightforward, yes? Well I asked a simple question. If we can't invoice the customer, we probably don't want to take any new orders for them. So should I automatically inactivate the customer if "Do Not Invoice" is checked?

No, says billing. Because their practice is to give 30 days notice before inactivating a customer. They want to give the field offices time to release invoicing before inactivation. I pointed out that "Inactive" never prevented invoicing, and no one has suggested that it should. So they can mark an account "Inactive", thus preventing new orders, as soon as we decide we're cutting them off. Then 30 days later we can mark the account "Do Not Invoice". No, says billing again. They have to give them time to release the invoices before inactivating the account.

I tried (again) to point out that "Inactive" does not mean that you can't release invoices. It only means don't place new orders. "But if they're inactive, we shouldn't place orders or do the work or bill them or anything!" Wait, now you're talking about halting Vendor Assignment on existing open orders. In other words, don't assign anyone to do the work on open orders if the customer account is inactivated. That's an operational question completely outside the billing person's area of authority or responsibility.

After 1/2-hour on the phone, I just could not get through to her that "Inactive" only only only ONLY means do not place new orders. It has NO FUCKING EFFECT WHATSOEVER ON PROCESSING OPEN ORDERS OR RELEASING INVOICING!

...

So we're going to add a checkbox for "Do Not Invoice". And the next time this happens, the billing person will call all the service centers and tell them that they have 30 days to release any pending invoices for the customer. Then she will go into the customer maintenance module, and check the "Inactive" and "Do Not Invoice" checkboxes.
===

Purveyor of Doc Hope's [link|http://DocHope.com|fresh-baked dog biscuits and pet treats].
[link|http://DocHope.com|http://DocHope.com]
New I'm reminded of an old story
There was a QA person whose first test was to load the program, take both fists, and pound the keyboard. Almost inevitably, the program would crash. The developer would inevitably have a look of utter horror and would say, Nobody would really do that! The response? You don't have a two year old, do you?

Cheers,
Ben
I have come to believe that idealism without discipline is a quick road to disaster, while discipline without idealism is pointless. -- Aaron Ward (my brother)
New Bwahahahaaa
for a while, I had to keep my servers in a quasi public area. I always loved it when my son would get in the room and push the reset button so he could see the lights on the front of the box flash:)
--\n-------------------------------------------------------------------\n* Jack Troughton                            jake at consultron.ca *\n* [link|http://consultron.ca|http://consultron.ca]                   [link|irc://irc.ecomstation.ca|irc://irc.ecomstation.ca] *\n* Kingston Ontario Canada               [link|news://news.consultron.ca|news://news.consultron.ca] *\n-------------------------------------------------------------------
     $whore++ - (drewk) - (31)
         Hey, maybe it'll work - (broomberg) - (22)
             I've got this theory - (drewk) - (17)
                 We'll see what really happens - (broomberg)
                 Argument strength - (tuberculosis) - (15)
                     Isn't that statement too strong? - (Another Scott) - (14)
                         You're both right - (drewk)
                         Not entirely mistaken - (hnick) - (1)
                             Well...that true, if - (jb4)
                         Developers. Testing. Same sentence. - (pwhysall) - (6)
                             Actual conversation *had* at work - (drewk) - (4)
                                 Preach it, brother. -NT - (pwhysall) - (2)
                                     While I'm on the topic - (drewk) - (1)
                                         You worked for the Pentagon, right? _____________________;-j -NT - (Another Scott)
                                 I have to deal with that all the time >:-P - (imric)
                             Heh. Ben didn't call me Pollyanna for nothing. :-) -NT - (Another Scott)
                         You are, indeed, mistaken - (ben_tilly) - (3)
                             That's *one* of the people you want testing - (drewk) - (2)
                                 I'm reminded of an old story - (ben_tilly) - (1)
                                     Bwahahahaaa - (jake123)
             I think it's just the opposite - (Arkadiy) - (2)
                 That attitude may be WHY you can't do it very well - (ben_tilly) - (1)
                     Well, it's been 2 years since I worked with good QA people -NT - (Arkadiy)
             Sorry, dupe -NT - (Arkadiy)
         It seems to just roll off your tongue... - (folkert)
         Sounds like a nice challenge. Congrats! -NT - (Another Scott)
         On a deal like that - (tuberculosis)
         So where do we line up... - (ben_tilly) - (3)
             Can't happen - (drewk) - (2)
                 Here's what I think you're expecting... - (ben_tilly) - (1)
                     Heh, good point - (drewk)
         Confession is good for the soul. :) - (a6l6e6x)

Maybe this is what seafood will do in a thousand years.
114 ms