Tuesday, 19 November 2013

Johnny Mnemonic - ICEOVERMAD

Fairly early in my testing journey, I attended (and interacted with) the Rapid Software Testing course, showing me the power of consciously introducing mnemonics into your testing (and life) toolset.

After this initial experience I noted that even in the most linear of environments where the testing process was seemingly restrictive these techniques could be leveraged. On even further reflection I realised we are all using mnemonics to complete certain testing tasks in a subconscious manner and not acknowledging their fallibility.

So 3 years on, having used a number of the mnemonics created by others I thought I would give it a try. I picked something I have worked on a great deal recently, creating test approaches for and executing testing of Application Programming Interfaces (API’s), henceforth referred to as, ‘the service.’

So, without further ado, I can now reveal:


Integration – How will consumers integrate with the service? When will consumers integrate with the service? Is it intended to be rendered on a browser? Output into a file and then consumed?

Consumers - Who will be consuming the service? Is the end user a human or a machine? What problem does the service solve for each consumer?

Endpoints – What form does the endpoint take and how is it reached? Is it a single endpoint, multiple endpoints or routed through a load balancer. What level of security is applied?

Operations – What business functions does the service perform? Can they be mapped to current functions performed via a user interface for example? Are the operations descriptively named and readable for both human and machine? Do the operations handle sensitive data?

Volume - Will the service be used at high volume concurrently or sparingly with single high value requests? Are the single transaction sizes an issue? How will API sessions be managed? Is the target architecture clustered?

Error Handling – How will the service handle server side errors? How will the service handle client side errors? Are errors informative and/or verbose? If database connectivity is lost is that handled?

RESTful – does the service have the characteristics of a RESTful service? Is this desirable in context? http://en.wikipedia.org/wiki/Representational_state_transfer

Modularity – How are the components of the service distributed? How do they interact? Can they exist on their own? Can they fail over to one another?

Authentication – how do users authenticate within the service? What permissions are applicable and how does that change the operation of the service? What levels of security are used? Is data sent or received encrypted?

Definitions – What defines the inputs and outputs to the service? Is a WSDL, WADL, XSD, XSLT or Other used? What limits does this impose on the service? Which HTTP methods are used and for what purpose?

While I was creating this, it felt like I could have added a great deal more to the mnemonic but to be effective (and memorable) I have focussed on (what I believe to be) the key areas. So, please feel free to give this a try. Amend, enhance and critique as you see fit.

Friday, 1 November 2013

Sometimes you know how but you can't say how.....

I was once asked to create a ‘Sprint Diary’ for how to be an ‘agile tester.’ That’s right, on the first day do this, on day two say this, on day three create that. Now, I can understand why they (vagueness to protect the guilty/innocent) wanted this ‘guide.’ I meet many testers who feel discomfort in the agile world who want to know which way to turn. 

They didn’t like my answer. I said:

‘I might be able to show you but I can’t tell you.’

Why ever not they said. I said:

‘The skill and understanding is in the moment, when decisions are made.’

When is this moment they asked. I replied:

‘To be honest I don’t know. And I might not know at the time.’

Honesty does cause a great deal of consternation. Much grumbling ensued.

So after pondering on this exchange, my reflections led me to these (personal) principles:

  • Strive for optionality. In a world where factors that cannot be finalised or nailed down are constantly hounded for a state they are incapable of, be the person who retains their options. Leave doors open for people, systems, tools and techniques. Who knows when you might need an extra option in a squeeze?
  • My old buddy context. Often neglected, but always waiting to be found. Ask just the right question, dig a little deeper, and ask someone you might not usually ask. When someone on the team asks ‘what is the context of this issue?’ it always brings a little smile to my face, as it usually leads to an epiphany.
  • Timing is crucial. You always hear phrases like ‘just enough, just in time’ and ‘last responsible moment’ in agile discourse. Can you honestly think of a teaching strategy to find the ‘last responsible moment’ to make a decision? It is ethereal, one moment you can taste it, the next it’s gone. And there’s a very good chance you’ll get it wrong. A lot.

I’ve been on agile training courses but I have never proceeded thinking that it would teach me to be ‘more agile.’ To approach without recognising the fallibility of such endeavours is understating the importance of the tacit knowledge required.

Of the three principles above how many do you think can be taught and to what extent? I don’t have the right answer. As an industry we chase tacit knowledge tirelessly, trying to encapsulate in training courses and the like, I chose to go back to (my) first principles.