August 4, 2014 at 12:11 pm
GoofyGuy (8/4/2014)
Matt Miller wrote:... depending on the type of process you're dealing with, it may not be physically possible to test every single permutation, so - yes in some cases you might not be able to completely dummy-proof or fail-proof some jobs.
Maybe not, but it's no excuse to bypass developing the appropriate test cases, either.
The time spent actually writing software should be almost vanishingly small, compared to the time expended on design up front and testing in back.
I never said that it was, but there's a difference between having appropriate test case coverage and accounting for every single possible failure. This is where the old "Perfect is the enemy of Good" adage comes into play. You account for enough failure scenarios to meet your performance and functional specifications (usually you exceed the expected spec by some acceptable amount), and perhaps you document the other failure modes or at least detect that your success condition has not been met. Still - some failures may occur, even in well thought-out ones.
----------------------------------------------------------------------------------
Your lack of planning does not constitute an emergency on my part...unless you're my manager...or a director and above...or a really loud-spoken end-user..All right - what was my emergency again?
August 4, 2014 at 12:22 pm
... there's a difference between having appropriate test case coverage and accounting for every single possible failure. This is where the old "Perfect is the enemy of Good" adage comes into play.
Absolutely, and I'm not disputing your opinion or the old adage.
I'm simply advocating taking software testing as far as it can reasonably be taken; all too frequently, testing isn't taken very far. Ditto for the thought put into software design.
It sounds as if we're saying the same thing and just talking past one another. In any event, I believe too much time is wasted in writing software, and in picking up the pieces when it fails - and not enough in up-front design and back-end testing.
Since we're bandying about old adages, here's a paraphrased one for you: if you love software and sausages, you shouldn't watch either being made.
August 4, 2014 at 2:16 pm
GoofyGuy (8/4/2014)
Since we're bandying about old adages, here's a paraphrased one for you: if you love software and sausages, you shouldn't watch either being made.
Agreed - and both go well with beer 😀
----------------------------------------------------------------------------------
Your lack of planning does not constitute an emergency on my part...unless you're my manager...or a director and above...or a really loud-spoken end-user..All right - what was my emergency again?
August 4, 2014 at 2:30 pm
Matt - true, beer and software go together surprising well, but can have some pretty bad after-effects! It's amazing how much 'brilliant' software I've put together with the help of a few brews (or several!), and how poorly the software and I performed the next morning.
March 5, 2018 at 7:20 am
GilaMonster - Thursday, July 31, 2014 6:32 AM....... Don't assume everything's OK. .....
This is great advice.
Design under the premise that something will fail, and that you want to be the first to know about it. Build out an audit/tracking/monitoring protocol early on.
Setup all your procedures and/or SSIS/ETL jobs to track activity. - how long did it take, - how many records were processed, etc, etc. These processes manage organizational data, so they potentially have both system based errors and problems and organizational data problems. we all know system type errors. A process may succeed, but still have a data problem. - the data set was incomplete, the data set had duplicates that were not tested, - I see this happen when a developer sets up an outer join, under the assumption that the join table will have a single record match, and then months later, the assumption proves invalid. And all of a sudden, values are too high.
The more you are prepared, the less you need it.
Viewing 5 posts - 16 through 19 (of 19 total)
You must be logged in to reply to this topic. Login to reply