Thoughts from a Thirsty Bear

A term that I still hear occasionally is "SDET", or "Software Development Engineer in Test". It is also known by a few other terms - Developer in Test, Test Automation Engineer and so on. Essentially it is a job role for a developer whose main responsibilities are to write automated tests and frameworks to check software. And it is a truly awful case of missing the point completely . It is a job title that indicates a fundamental systemic problem in an organisation. First, some history. Back in the Bad Old Days of the 1900s, we used to develop software using a linear waterfall style process, mostly due to a bizarre and tragic misunderstanding of a single academic paper (Royce, 1970). There was a lot of management thinking that modelled software development as a factory production line, and assumed that there were cost reductions from specialisms - someone creates a software design, someone builds that design, and someone tests what has been written. At the end, som...

  We all know tests need to be reliable (don't we?!). One of the worst things any test can do is give false results, whether consistently or intermittently. A test that passes when it should fail gives a false sense of security. A test that fails when everything is OK leads to wild goose chases trying to find the non-existent problem. This should be obvious. We call these false positive and false negative  results.  But just recently I have been thinking about  what is a false positive and a false negative?  It's obvious - until it isn't. So hopefully writing this down will clear it up in my mind, and some others. I'll add that this is my thinking right now after discussing the issue with several people - just make sure the definition inside your own company is consistent. Turns out, whether something is a positive or negative, false or otherwise, depends entirely on what signal is being detected . What is the 'positive' signal?  For testing, what is a tes...

Customer feedback. We all know we need it to make sure we are delivering the right thing. But sometimes we all have trouble engaging. The customer might be busy, or disinterested, or both. So here's a little tip that might just help. Like all the best stories, this happened a long time ago in a galaxy far, far away....  We were working on a web front end and associated backend system for a client. But we were suffering from the "disengaged  customer" anti pattern. The customer would not commit to a web front end design, and help us design the look and feel needed for the application. We provided a few options over a couple of iterations to try and start the design conversation, but none connected despite our efforts. So we threw in a " smelly sock ". Something so stinky it guaranteed to get folks going " Ewwww! Get that out of here!". I seem to remember we disabled all CSS formatting.... Sure enough, we got a reaction during the regular show-and-tell s...

Following a fairly public spat and veiled threats over trademarks by Oracle, the Hudson CI server has been renamed to Jenkins . OK, technically Jenkins is a branch of the Hudson code, so it's more like Hudkins or Jenson . Oracle (sorry, " the Java community ") will continue to develop the Hudson trunk, however the branch appears to have the blessing of the core Hudson Jenkins development team and the community (the vote to fork appears to have been virtually unanimous ). If it looks like a duck & quacks like a duck....then the parent might just start resembling a dodo . I'd like to wish the Jenkins team good luck. I've used Hudson to great effect many times, and look forward to the future improvements with the new project butler.

Something is happening in the Test First world. There appears to be growing use of " Behavioural Driven Design " (BDD). That is, the test names in test classes are becoming sentences describing what the class should do, eg testFailsForDuplicateCustomers() . In my opinion this trend is damaging the effectiveness of Test First Design in the field. Don't get me wrong - I think the fundamental idea behind BDD is sound. But I am finding that this kind of naming approach for unit tests is seriously detracting from the "code is the documentation" ideal. If you have a class with method " X ", you should expect a test method " testX " that defines the method's contract. If the method's contract is more complex, you might expect to see a set of methods like " testX_NullInput " etc. This approach documents the class pretty damned well in my experience. Now image the same class being tested by something like " testFailsIfC...

In my role as a software developer I have come across many strange attitudes to coding, but none so strange as the fear of changing code. A good example - I was working with a team trying to use XP techniques. I was hired as a XP developer to strengthen the team and get them over a busy patch - not as coach, but simply as someone who had developed Java code in an extreme agile environment. No problem there. The product we were working on required new functionality added to it. Since the current software structure did not easily accommodate the new stuff I mentioned in the stand-up that I would be restructuring the internals to make it fit more elegantly. This kind of refactoring is normal practice in any agile team, and is necessary to evolve the design with emerging requirements, keeping it coherent and stopping it from descending into a meaningless Ball Of Mud antipattern. I thought nothing of it. But one of the senior engineers threw his hands up in horror at the thought. "Yo...