QA Automation Principles

I’ve seen automation fail and succeed through different engagements.  I’ve noticed some patterns and have created the following prerequisite Automation Principles.  Having these in place will as least minimise your risk of failure.

Failure patterns tend to be:

  1. Monolithic ‘one size fits all’ solutions – attempting to replicate a pattern that was successful elsewhere into a completely different environment
  2. Managers in charge of automation that aren’t technical enough, cannot understand the technology solutions in place and are being lead by engineers that tend to work in silos
  3. A pattern of working that doesn’t encourage Automation to be engaged as far left as possible – if you are throwing ‘over the fence’ to automation then this is strategy for failure.  This could be simply attempting to automate the manual test scripts or developing a solution and then letting  the automation team attempt to figure out how to automate
  4. A solution that hasn’t factored in the environment (People, process, politics, technology, skills) – a good manager will assess the agile environment and map an appropriate way forward.

With the advent of iterative cycles, incrementation development and frequent delivery – Continue reading

‘BDD’ or ‘BDD Syntax’?

I’m writing this article so individuals can see where they are on the BDD journey. Recognising where you are is important as it allows you to realise just how much further you can actually go.

I’ve been to another client site where I’ve been told they ‘are BDD’.  I’ve seen it many times, and although the intention is good there is a difference between ‘being BDD’ and ‘BDD syntax’.

Continue reading

Being BDD is HARD

Given – When – Then ….. Seems deceptively simple.  BDD was undoubtedly one of the most difficult approaches we had difficulty implementing.  For me it was key – it wasn’t about the syntax, BDD is about:

  1. Getting different disciplines talking and communicating using a common accessible language.  Pushing out the enemy – ambiguous statements and subjective interpretation.   Building the right thing, preventing wasted effort on development and testing of the wrong thing.
  2. Building quality and testing into the incoming stream of project requirements
  3. Embedding rigour and testing into the most important part of the process – Incoming Requirements

Continue reading

QA Bridging Theory – Plain English

How do we create a project approach that will ensure that the quality meets customer expectations? If we can figure out the mechanisms of this then we will be more likely to have success.

Note:  See  QA Bridging Theory for a birds eye view of the below.

This entry attempts to unpick at what those fundamental variables are and then attempts to provide the basis for a quantifiable formula for measuring the associated risk of achieving success.

Continue reading