Meanwhile back with Tom Kyte
September 30th, 2005 by Peter Scott
Eddie Awad asks: How come no one has mentioned "testing"?! A very important part of developing an application (any application) is to test it again and again until the tests produce the desired results.
Of course Eddie is right, but sadly, like good design, adequate testing often takes a backseat role to getting the job done. Reduced rigour in testing is, however, not always a deliberate ploy by the developers to cut corners, it can be that they just don't know how to test.
I expect the coders that work for me can unit test their work and to keep proper records of their tests - I even let the ISO auditor loose on them just keep them on their toes. I expect their test plans to cover both the expected and exception cases. I also expect that these guys to handle the type of regression testing we put in at deployment time to ensure old bugs don't come back. But I do not expect them to design complex testing plans - that goes down to expert test managers. Here I'm lucky in that I use one of the best freelance test managers in Europe - I've known her for years (we were at school together) and she is one scary lady. She can make both coders and customers quake at the rigour of her test plans. But we pay her to make sure the tests are fit for purpose and she delivers. She is well worth the cost of flying her in from Switzerland for a few weeks or months.
September 30th, 2005 at 9:58 pm
Pete,
One of my favourite past colleagues is a first class test manager - ex-IBMer - and they are a breed apart. I loved talking to him, seeing him work and learning from him.
These days he tends to talk in various quality-related buzz-words rather than testing, but he sounds like he’s still coming from the same place to me.
You’re right. These people are worth their weight in gold.
Cheers,
Doug
September 30th, 2005 at 10:11 pm
but sadly, like good design, adequate testing often takes a backseat role to getting the job done
For me, the job is not done until after adequate testing is done. I do understand, however, that sometimes the project deadline and schedule (mostly dictated by business needs) may force us (developers and development managers) to trim a little bit here and there, and sometimes, sadly, testing may be the victim.
…a deliberate ploy by the developers to cut corners, it can be that they just don’t know how to test.
Very often, where I work, test scenarios are created by the business users and not the developers. It is better for someone else to create test scenarios and test the application you have written than to test it yourself. In other words, let someone else test (and maybe review) your code. In this case, the “scary lady” may come in handy
September 30th, 2005 at 10:20 pm
Eddie,
“It is better for someone else to create test scenarios and test the application you have written than to test it yourself.”
Agreed. I think ’someone else’ can often bring several advantages (at least two, off the top of my head)
1) Because it’s not ‘their’ code, they don’t have an emotional stake in it, so they can be honest.
2) Because their entire focus is testing, it can be their passion, rather than a neccessary evil.
Cheers,
Doug
October 2nd, 2005 at 8:51 pm
For me, the job is not done until after adequate testing is done.
Indeed yes, Eddie.
One of the problems I see is where people do not code defensively - “what ever can go wrong will go wrong” holds true. Their code may work for that ‘perfect’ input, but what when the unexpected (but still possible) happens?
Doug: I am happy for coders to test their own work - it’s a fuzzy line between debugging and testing. But the version of code they want to put live is tested by someone else.
A couple of jobs ago, I had a GUI tester in my team - she had an uncanny knack of breaking anything she touched - if the program was Jill-proof it was good for market!
October 5th, 2005 at 9:57 pm
test scenarios are created by the business users
They should do acceptance testing, but not code testing, in my experience. (With the exception perhaps of trained business analysts) they only use common-to-their-experience values. Testing needs to be both the range of expected inputs and traps of out-of-bounds.
I’m on a project where the manager tells me the values will be already validated. Fortunately, a lot of the code I’m reusing from a similar process already has exceptions coded in, so I just change the exception handling to send root an email and don’t argue with him about it. I’ve found several situations that can bypass the validation, anyways. The big question is, do I go back to the similar process and fix some rare situtations I see it has missed?
October 5th, 2005 at 10:22 pm
The big question is, do I go back to the similar process and fix some rare situtations I see it has missed?
A hard call, Joel - How likely will it get one of these ‘rare’ cases, what is the impact of the problem if it occurs, how much effort to re-work the code to handle those errors. Looks like a piece if risk analysis is needed.
Never trust a person whos tells you that all the data is validated
I run DW systems that extensively use RELY constraints, but only because we trust no-one and validate all inputs ourselves.