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.

 

Avoiding too many user stories

…… 600 user stories in an application development backlog. All those user stories showed the team’s extensive due-diligence work in a complex project that involved a platform change. Unfortunately, having so many user stories was a sign of no consensus on goals
Avoiding too many user stories in software development

Yeah, I got a framework for that …

Do 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.

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.

The modern tester

I choose to healthily ignore the various various debates around the place of the tester, as it hasn’t changed that much. With every wave of new developers, comes along the same misplaced arrogance that they can do no wrong.  The chips have yet to leave the shoulders.  

Testing is boring? By same token, development is – testing is just missing the right over-excitable words and phrases, that wouldn’t drop like a stone, if you shouted them in a pub.

End-users as security testers

Increasingly security testing of web applications are left to the end-user to discover. The web is generally seen as an imperfect thing, so it is not surprising that most users do not expect a website that works well 100%. What I have seen on the best Agile and Lean projects, is this is omitted to much further down the cycle, if at all – but why? Yes, they are skilled testing areas (and hence higher cost to secure fully skilled resource), but there is a lot that can be done, with the right tools and approach.

Incremental Automation

Firstly, it is pervasive problem that too many people talking at length about Agile and testing that haven’t a clue what they are on about. The invasion of fashionable buzzwords to make the mundane sound more exciting, has become a tedious norm. There is much bandying about of “Lean” recently, with no consideration of the skills required to implement such projects. That’s an aside, but relevant also to automation. The word “automation” excites managers, as it implies efficiency.  What it also implies is a possible nightmare.