Its a big Given ….

BDD is an enjoyable way to develop and test, but introduce business and that pesky client, it can rapidly change into stressful Waterscrum or (the even worse) Scrummerfall.  Transparency is an easy word to throw out there, but who wants it?  No-one wants to hear bad news and show and tells rapidly descend into a perception game, to pander to client expectations of how development process works.  As with any engineering, most are shocked to learn that engineering is very much an incremental learning process, involving regular mistakes and learning exercises.

The average client expectation is still of having a tangible product, and not to be drawn into the more painful side of development process. It’s a two steps forward, one step back style process. And with BDD, even more so, as the business side is defining a lot more than just high level user stories – they are defining expectations on more granular level.  And in natural language.  Why the last point is very valid is that developers inherently have problems visualising the natural language of requirements in terms of code.  When in fact a scenario line could be viewed as a chunk of functional code.

When reviewing user stories, where the eyes should immediately be drawn to are the “Given” statements.  These generally can appear innocuous, but can hide a whole host of requirements upon development and QA.  Usually used to specify location, authentication and test data.  Test data itself can be a hugely underestimated task, and usually the specifications are wrapped up the the Given statements. Also smart to analyse any example tables for assumptions. It may look like innocuous input/output data, but it may be referencing part of a system that are not built yet, or have existing caveats.

BDD gives Agile a sledgehammer edge, and all the better for it – as long as you stay on top of the process, and can manage the client concerns over their over-exposure to the process.

 

Yeah, I got a framework for that …

trepenationDo you remember when they loudly pronounced “vinyl was dead”? Be it records, testing or development framework, whenever something new comes along, there follows an army of doom-merchants. Either for the kick, or for profit, pronouncing something is dead is a easy way to get peoples’ attention. After all, what is better than something that’s past being kicked into touch, by something new. Maybe working out first if something new is better, or in fact, an over-hyped pile of crap. If you have worked in tech for 10 years, you will know what I mean when I say I literally wince in pain, when I hear someone’s warbling on about the latest framework product, that just blows away the competition. Even if the product wouldn’t even exist, if it wasn’t for it’s OAP predecessor (i.e. the language it was coded in).

I am reminded of time a professional colleague told me that as part of his learning of php, he built a user-friendly content management system from scratch and website templates for a client. It took him less than a month, and of course, he knows it inside and out.  I, on the other hand, chose the WordPress framework – and although implementation is quick, I still spend month of two configuring, adding plugins, refactoring plugins, etc.. Both are ways to get the job done effectively, but the smokescreen of frameworks is that they save time. They don’t. It’s two ways to do the same task. But the former provides you with something truly relevant, with no dead weight. Anyone who thinks otherwise is kidding themselves. I love WordPress, but fully aware that I also need to understand php even more than the products built on it.

Having said that, having been through the first painful few projects, I can now quickly build a customised CMS and templates very quickly using WP. I guess the point here is when you sell up to a framework, it really only shows value if you use it on future projects, not just a one-off.  One of the early mistakes I made was in the first flurry of excitement, I quickly bloated the code, as requirements necessitated plugins, some custom, some from the bewildering array of free and commercial plugins.  And many don’t manage to stay the distance, and languish through under-development, ultimately becoming incompatible with subsequent WP versions.

With development frameworks take your pick to learn, with enough fashionably named JavaScript frameworks to keep you busy in bluffing your way in IT for the rest of your life. But be wary – your career is on a knife-edge if you base it on products alone. And there is always a risk of spending too much time learning, and working with one framework. Nothing last forever, but a programming language is highly likely to outlive any product that is based on it. So feel pick Rails, Grails, Zend2, CakePHP, dotNET(?), Joomla (frameworks large and small) … not to mention the array of plugins and module they all have to extend the functionality.  But be conscious you are skipping across the surface of the tech, and what provides quicker routes, often come with more risk. If you are looking for a framework to use for your project, ask yourself why you are, before deciding.

At application level, I am wondering if there is any real valid excuse for using a framework. They don’t save time and they certainly don’t seem to save money in long-term. And there will always be compromise, sometimes at cost of client requirements. Start-ups can have valid excuse to use frameworks to accelerate initial development forward, but if you are looking something robust and future-proof, maybe you are better off with a “primitive” approach … a programming language takes a lot longer to die, than a framework.

Iterative and Incremental Development

Although evolutionary, iterative and incremental development (IID) in software is in the ascendance as the modern or agile approach to replace ad hoc or waterfall (sequential lifecycle) development, its practiced and published roots go back surprisingly far. At least as far back as the mid 1950s, as a contemporary alternative to the nascent waterfall model …
Iterative and Incremental Development:A Brief History

Every Agile consultant is standing on shoulders of giants. In fact, we all are.

BDD: Is there a difference between programmer and tester?

To automate, you have to code. And if you are automating an application, the logical way to think about it is developing an application to test an application. And to do that from scratch – every time – would be laborious, and unnecessary as there are many common web features. This kind of thinking has been around in software development for decades – to program with reuse in mind. Continue reading

It’s not like the good old QA days …

I am starting to think those of us who grumble about misuse of term “QA” (Quality Assurance) are maybe in the realms of grumpy old men/women. I now beginning to realise that yes, people use the term far too loosely without thinking it through. But more is expected of the tester these days, than simply testing – and those expectation do fall within the realm of Quality Assurance. Quality Assurance and Testing used to be distinct areas, though testing came under the overall remit of a QA manager, as it’s a quality gateway task. Continue reading