In preparation for a set of developer interviews I’ve been boning up on the “basics:” testing, objects, algorithms, etc. I approached testing with trepidation, as I (a) know what needs to go into it, and (b) know EXACTLY how little those needs are met in small development environments. And by small, I mean less than about 100 developers and testers.
Now I’m mostly irritated. There’s not a single thing new under the sun (yeah, I should have known that). For example, unit testing: lots of chatter about test harnesses, fake objects, parameter limits, etc. Sigh. Let’s roll back to the black & white days of FORTAN/360 (yes, that’s before FORTRAN 77). COBOL. PL1. I know, not much “objecting” going on there. But program files with sets of functions abounded even then, and functions relying on more primitive ones were more important then, in the world of memory cores and 1Mb “super” hard drives (yes, I know that age) than now, in the bloated reality of needing 4Gb just to make one’s commercial operating system happy to boot.
Here’s the ugly truth. Folks in this decade make up pretty names and “paradigms” that are literal plagarisms of the testing manuals of yore. And by literal I mean entire paragraphs pulled with some names changed. Test cases and corner cases, which are part of or sometimes synonymous with testing procedures from manuals of yore.
The net of all this, to give reason for this missive, is that companies hiring are looking for buzzwords, but what the technical managers need to be doing is listening to the words, not keywords, in describing a person’s experience. Because a rose by any other name still smells sweet.