Beefy Boxes and Bandwidth Generously Provided by pair Networks
laziness, impatience, and hubris

Re: Dealing with the QA guy ... (no, really)

by pg (Canon)
on Sep 27, 2005 at 04:43 UTC ( #495268=note: print w/replies, xml ) Need Help??

in reply to Dealing with the QA guy ... (no, really)

So true.

Just add a little bit, sort of coming in sideways. During last half year, I ran into the same issue several times. The issues are with the requirements. According to the procedure we have, once the requirements is documented, we don't go back to it until the user acceptance testing. When we do unit testing, we test against program spec, not the requirements; when we do system testing, we test against the design, not the requirements. There were several times, we got bad requirements, then there come the "good" design based on the "bad" requirements, as well as the "good" program spec based on the "good" design (that is based on the bad requirements). Then you do coding and unit testing, which go well, as everything meets the spec. System testing is also fine, as everything meets the design.

All those effort are wasted... when it comes to user testing, user don't really test against what is documented, they test against their interpretation of the requirements (or to be more precise: the document didn't really express the true user requirements. When the IT side and the user side agreed upon the document, they thought that they understood the words in the same way, but they didn't.)

Human communication... the single problem that we can never get rid of...

  • Comment on Re: Dealing with the QA guy ... (no, really)

Replies are listed 'Best First'.
Re^2: Dealing with the QA guy ... (no, really)
by xdg (Monsignor) on Sep 27, 2005 at 10:13 UTC
    According to the procedure we have, once the requirements is documented, we don't go back to it until the user acceptance testing.

    I believe this is one of the potential stumbling blocks in software development that agile and iterative methodologies attempt to address. By keeping customers close to the developers, developers can short-cut the wasted-effort cycle when requirements are vague. By developing in short timeboxes, the amount of drift to user acceptance testing is minimized.

    The Extreme Perl website expresses the problem reasonably well. Heavy, plan-driven methodologies are optimizing to minimize implementation risk, whereas agile methodologies are optimizing to minimize requirements risk -- which many would agree from experience is often both more likely and of higher overall impact.


    Code written by xdg and posted on PerlMonks is public domain. It is provided as is with no warranties, express or implied, of any kind. Posted code may not have been tested. Use of posted code is at your own risk.

Re^2: Dealing with the QA guy ... (no, really)
by prad_intel (Monk) on Sep 27, 2005 at 06:11 UTC
    Hi All,

    I as a representative of QA/Testing community would agree with the above discussion. I am not a Tester by profession but by virtue.

    As mentioned above , I do ad-hoc testing and it has been succesful most of the times giving an error/crash/hang.

    Once my manager was so impressed that he asked me to write cases that are beyond what the spec or test plan tells

    Well coming to the case of Whats happening with Anonymous monk and his QA guy... I do agree there are some morons in every profession...

    Well infact in my previous work place I being a tester did challenge the IIT guys that I would find a crash before the release and so did I and the quality thus improved.

    If you want to tame the QA guy write or learn "how to write solid code" , do some good unit testing , ensure he has not much to do.

    Moreover as you jotted your problem here , write a perl script which will test your code ;-) Regards


Log In?

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

How do I use this? | Other CB clients
Other Users?
Others scrutinizing the Monastery: (4)
As of 2018-04-25 17:35 GMT
Find Nodes?
    Voting Booth?