I thought it worth repeating the wisdom I spotted there:

"That's what the Test Track at Velim is for"....methinks that modern managers, project managers and beancounters need reminding of this.

My experience lately is that when folk of their ilk hear 'apply all the edge cases', what they hear is 'blahhhhh blahhhhh blahhhhhh un-necessary time and cost' and promptly chop those 'edge-ish' bits out of the test and/or approvals plan.
I'm lucky enough to have had a diverse and very enjoyable career testing things for a living, in an organisation where you were *expected* to try and break the thing you were working on (within sensible limits).... the rational being that if it went wrong in-service, it would be seriously inconvenient for users, if not downright Goddamn dangerous (Think national-scale 'phone infrastructure - no 112/911 service=big problems!).

We were well paid to have a negative attitude towards 'Product Whatwever' in those days - actually a realistic attitude from a Systems point of view - which was endorsed by the C-Suite as necessary for product quality. The attitude was that if Joe Public doesn't have an issue then we've done the job right.

Most of the time, we would end up fixing an issue, even the 'Very Low Probability, Medium Impact' ones on the (proven!) assumption that if Mr. Sod can stuff it up, he will.

With this modern 'continuous delivery' way of working, I find the 'edge' cases get ignored as a fix is seen as 'only a software update away' - no matter that the poor sap trying to use the thing has to wait weeks/months/forever for a fix.
Nobody wants to take the time and trouble to create a robust product any more, and it's hard to take pride in your work (About 50% of my output at the moment is crap, because 'timescales' and workload).

The world is increasingly run/managed by people who have absolutely no idea of the technicalities and complexity of modern systems.

Here endeth this rant.

Add Comment