Your skill will accomplish what the force of many cannot |
|
PerlMonks |
comment on |
( [id://3333]=superdoc: print w/replies, xml ) | Need Help?? |
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... In reply to Re: Dealing with the QA guy ... (no, really)
by pg
|
|