Post #205,292
4/29/05 10:15:47 PM
|
Hey, maybe it'll work
And if not, like you said, M$ people have eternal positions.\r\nIn hell, but eternal.\r\n\r\nYou do realize, though, since you are QA, everything is your fault.
|
Post #205,293
4/29/05 10:36:15 PM
|
I've got this theory
We're a team. I'm trying to help make you look good. Unless you want to play Let's Discuss My Shortcomings In Public. As I won't be writing code, I expect to have much more ammunition than they do.
Oh, and even though everything will be my fault, somehow, "Well he should have noticed sooner how shitty my code was," doesn't sound like a really strong argument.
===
Purveyor of Doc Hope's [link|http://DocHope.com|fresh-baked dog biscuits and pet treats]. [link|http://DocHope.com|http://DocHope.com]
|
Post #205,301
4/29/05 11:45:21 PM
|
We'll see what really happens
I've got a great consulting gig.
Part of the work is doing marketing lists, merge/purges, stuff like that.
My end result is name, address files which get catalogs mailed to.
They are inhouse or out-of-house people, with a variety of selection criteria applied to the data to figure out who to pull.
I have a woman, along with her assistant, that spend a huge amount of time proofing what I pull.
Out of 40,000 names, they might pull 100, and work their way through the data, trying to see if I pulled the right stuff.
They will also look at the original data, and make sure it shows up correctly in my lists.
This is a huge amount of work.
Maybe 1 list out of 20 they find and issue worth asking me about, and 1 out of 40 they find a real problem, which might have me modify my selection code, or maybe reformat the inbound data differently.
Sometimes they find a mistake in a list that we have already mailed, since the effort might span months.
At that point it is HER fault, not mine. Not that fault really matters, though. If I can fix something yet to mail, I'll do it for free, no matter how many hours it takes. If it is already mailed, I MIGHT eat the cost. Have never gotten to that point, so I'm not sure.
In one case, I told my boss I was working way too many hours, and refused to take responsibility for any screwups. Sure enough, 2 weeks later we found a mistake that cost 20 hours to fix. I refused to eat the hours, and they accepted that they pushed too hard.
|
Post #205,326
4/30/05 2:16:09 PM
|
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
|
Post #205,335
4/30/05 2:58:00 PM
|
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.)
|
Post #205,343
4/30/05 3:11:59 PM
|
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]
|
Post #205,344
4/30/05 3:17:21 PM
|
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.
|
Post #205,775
5/3/05 6:41:18 PM
|
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
|
Post #205,345
4/30/05 3:21:29 PM
|
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!
|
Post #205,347
4/30/05 3:28:25 PM
|
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]
|
Post #205,348
4/30/05 3:34:49 PM
|
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!
|
Post #205,350
4/30/05 3:51:55 PM
|
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]
|
Post #205,351
4/30/05 3:57:23 PM
|
You worked for the Pentagon, right? _____________________;-j
|
Post #205,412
5/1/05 8:43:22 AM
|
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.
|
|
Post #205,349
4/30/05 3:44:40 PM
|
Heh. Ben didn't call me Pollyanna for nothing. :-)
|
Post #205,355
4/30/05 5:41:44 PM
|
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)
|
Post #205,362
4/30/05 6:13:06 PM
|
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]
|
Post #205,383
4/30/05 8:59:37 PM
|
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)
|
Post #205,384
4/30/05 9:01:37 PM
|
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-------------------------------------------------------------------
|
Post #207,061
5/12/05 7:27:53 AM
|
I think it's just the opposite
QAs have the best position in the universe. When they find a bug, it's their success. When they don't, it's programmer's fault for putting it i there in the first place. ice gig, to bad I can't do it worth a damn :)
------
179. I will not outsource core functions. -- [link|http://omega.med.yale.edu/~pcy5/misc/overlord2.htm|.]
|
Post #207,107
5/12/05 12:19:13 PM
|
That attitude may be WHY you can't do it very well
I've noticed that good QA people take it personally if they don't catch a bug, and therefore are very meticulous and methodical in searching for them.
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)
|
Post #207,413
5/14/05 3:37:30 PM
|
Well, it's been 2 years since I worked with good QA people
------
179. I will not outsource core functions. -- [link|http://omega.med.yale.edu/~pcy5/misc/overlord2.htm|.]
|
Post #207,062
5/12/05 7:30:08 AM
5/12/05 7:30:38 AM
|
Sorry, dupe
------
179. I will not outsource core functions. -- [link|http://omega.med.yale.edu/~pcy5/misc/overlord2.htm|.]
Edited by Arkadiy
May 12, 2005, 07:30:38 AM EDT
|