I think this is one of the things that quite often gets neglected, especially in the start of new projects.
When QAing, it’s one of the first things I think about. Mainly because as the project gets busier, you don’t want to be spending time on the busy maintenance work. This means that if you know things are drastically going to change where you would have to change things like test cases and such until they nail it down, it really doesn’t make sense in writing test cases at that moment in time.
Would it make sense to make sure that the intention and functionality of the feature be tested and retested manually first and explored before hand? so that the feature can then be nailed down and a test case be written?
Because it takes a number of revisions from draft to actually get things working write, from spec to actual engineered functionality. Anyone could starting from the spec/development can testify to that… so why spend extra time on stuff that will then need maintenance?
This is from experience, not some book. If you want text book to further explain why the cost is high, is the old graph of finding bugs faster in the development process will make the bug cost less. This is what I’m advocating.
Sometimes people don’t make sense to me in where they want to spend their time. I mean, they can claim they have more experience, but what they do seem to indicate otherwise.
Filed under: Uncategorized 
