Re: Getting Others to Accept Testing
- From: "H. S. Lahman" <h.lahman@xxxxxxxxxxx>
- Date: Wed, 18 Apr 2007 15:48:32 GMT
Responding to Siggimoo...
I'm curious to know what sort of problems people have run into with
regard to getting others to accept responsible testing practices. My
company has encountered numerous issues in this regard, leading us to
believe that many people just really don't care about quality. It
seems that a lot of people feel it's okay to just put something live
and hope it doesn't break, or to have end-users test something before
they've actually checked it out themselves. Now I will admit that our
scientific background may have trained us to be more thorough than the
average developer, but I would consider skipping over integration
testing and jumping right into end-user acceptance testing to be
irresponsible and even dangerous in some cases.
Alas, this is actually typical of most software shops that are not process-oriented (i.e., that don't have defined development processes and an infrastructure for ongoing process improvement). Unfortunately changing that view is primarily a problem of changing the fundamental culture of the shop. So if you are in such a shop you basically have two choices...
Choice 1. Find another job in a shop that is sophisticated enough to understand notions like using testing to monitor the development process rather than to directly improve product reliability.
Choice 2. Get a cape and go into Crusader mode to try to change the way the shop does things. Be prepared to spend years beating your head against walls. Been there; done that.
<apocryphal anecdote about skipping testing>
Where I worked before retiring we had a bug fix. It was a one-line change but it required a hardware setup that would take half a day to complete. This was in the final release cycle and there was considerable time pressure. We held a meeting between Engineering and QA at the project manager level and decided that Engineering would skip the test so only QA would cover it.
As it happened that one-line, what-could-possibly-go-wrong fix was incorrect. Of course Murphy's Law came into play and somehow QA did not run the test. The result was that the Division VP spent half an hour on the phone with an irate customer CEO after the release because that fix was one of the critical things the customer wanted done.
Fortunately that company was enlightened about process and the VP did not start looking for heads to lop off. Instead the process improvement infrastructure kicked in to make sure the problem would not recur. Part of that activity was recognizing what the root cause really was. It wasn't Engineering making a bad fix or QA skipping the test. It was violating the process rule that said that both Engineering and QA should test independently when a critical bug fix was on the line.
One can't simple say Don't Do That because that would make processes too rigid; there must be a mechanism for dealing with exceptions. So the process fix that they came up with was to make that sort of critical process override highly visible. In particular, the manager who would feel the pain if things when wrong (i.e., the Division VP) would have to approve the process variance in the future.
</apocryphal anecdote about skipping testing>
*************
There is nothing wrong with me that could
not be cured by a capful of Drano.
H. S. Lahman
hsl@xxxxxxxxxxxxxxxxx
Pathfinder Solutions
http://www.pathfindermda.com
blog: http://pathfinderpeople.blogs.com/hslahman
"Model-Based Translation: The Next Step in Agile Development". Email
info@xxxxxxxxxxxxxxxxx for your copy.
Pathfinder is hiring: http://www.pathfindermda.com/about_us/careers_pos3.php.
(888)OOA-PATH
.
- References:
- Getting Others to Accept Testing
- From: siggimoo
- Getting Others to Accept Testing
- Prev by Date: Mercury QTP 9.X and XPath Queries
- Next by Date: Re: Getting Others to Accept Testing
- Previous by thread: Re: Getting Others to Accept Testing
- Next by thread: Re: Getting Others to Accept Testing
- Index(es):
Relevant Pages
|
Loading
