12 Apr
2011
12 Apr
'11
9:25 a.m.
On 4/12/2011 12:04 PM, Chuck Guzis wrote:
I earned my programming stripes in the old corporate
world. Write up
a proposal; get approval to proceed (often entailed a lot of
lobbying); write up a design document; submit it for review; defend
your design; write up an implementation document; divide the work,
submit a test plan, code the tests, code the project code, submit
both for code review...
In fact, coding was a very small part of a new design. Politics was
far more important<snip>
This sounds fairly typical of the environments I've worked in for the
last five years.
You seem to indicate that this is overkill or unnecessary?
I'm currently bringing QA to a place which has never had it. There are
no requirements document. Without one, software development and the
internal customer aren't often on the same page. Development produces
something that "kind of" meets the expectation, but doesn't give them
fully what they want because this hasn't been spelled out. Feature creep
happens.
Much of the software framework was never designed --- and so there's no
design documents anywhere. Each developer handles each situation his
own way --- which almost never matches what the others have done. No
style guide = no consistency.
Without a requirements document, how will QA know when it's finished
testing? We use the requirements document as THE STANDARD. We test to
the standard. If the RD says it must do X, Y, and Z, we wrap test cases
around each feature, and ensure that X, Y, and Z work as designed.
Just wondering whether you think the process you listed above is prudent
and necessary or overkill? I get your point that actual coding is a
fraction of the process, but was interested in your input.
Thanks
Keith