A one pager on automated checks

I was asked to summarise the process for automated checks in an easily readable format for non techies to understand, so heres a little snippet of what I can share:

A pragmatic approach to automated testing is taken.  Automating only where we see the value.

Testing layers

There are multiple layers of automated checks:

  • Unit – Run on every check in.  Check individual units of code. When code is checked in these tests are run and if any fail are fixed.   
  • Integration – Run overnight. Check where Enactor talks to other systems, e.g the database.
  • UI – Run overnight.  Follow a user journey, simulating button clicks and typing as if it was a real user.  


Manual to Automated

Scenarios are creating using Behaviour Driven Development (BDD) format for every user story.  A scenario is worded in the Gherkin language.  e.g.Given When Then 

These are output as Cucumber feature files, which can then be automated using Selenium Webdriver, using Java code

Cucumber  https://en.wikipedia.org/wiki/Cucumber_(software)

Selenium webdriver http://www.seleniumhq.org/projects/webdriver/

BDD – https://en.wikipedia.org/wiki/Behavior-driven_development


Time vs scope vs quality + cake!

We all want it now.

We all want it all.

We all want it right.

But sometimes something has got to give.

In software development time is always of the essence.  Demand can be high and the pressure is on to cut corners to try and keep customers happy.

While talking to a developer the other day I described this cake analogy so here it is to share:


Baking a cake

A cake takes a certain amount of time to bake.

A cake takes a certain amount of ingredients to bake correctly.


If I don’t bake a cake for long enough, it is not a cake

If I miss some ingredients, there is a risk that it will not be a cake


But really I need to define what a cake MVP is to know how to sacrifice time, scrope or quality




Lean Tea Making

Every morning after the run around with a 2 year old I come into work and make a cup of tea and I‘ve had some ideas bubbling in my head about how I can apply this to lean principles.
Tea making is an activity that all of us partake in pretty often.  Its a social activity as well as a great way to make friends (see Dan Ashbys blog Why tea is a great tool for a tester).
It got me thinking about the different ways I made tea, based on what criteria I set for it.

  • Sometimes I want a cup of tea FAST.  I have work to get on with (and blogs to write).
  • Sometimes QUALITY is the most important.  I am making tea for others.  I want them to enjoy my tea and commend me on my tea making skills.
  • Sometimes the SCOPE of tea making might increase. I might have a mini meeting with someone while making the tea.
For speed I want the fastest cup of tea, with no waiting for the kettle to boil so I can get back to my desk and start my day.  My steps are:
  1.  Fill kettle
  2. Put it on boil
  3. Wash cup (optional)
  4. Put tea bag in
  5. While kettle is boiling grab a glass of water and take it to my desk
  6. Back to kitchen and tea bag in cup
  7. Add the milk (controversial I know but for speed this is the key!)
  8. By the time the milk has finished the kettle has finished
  9. Pour the water into the cup
  10. Let it brew quickly then squeeze the bag a lot to get strong tea flavour.
  11. Take bag out and all done within 90 seconds I have a cup of tea.
Quality is a bit different:
  • Brew time would be higher.
  • Milk will go in last, which impacts speed.
  • I might have a lot of cups to wash which will increase the time, also impacting speed.
  • I wouldn’t be running around the office sorting my water out, I would have to do that later.
Scope is different too:
  • If a discussion happens while I am making tea for myself, I will straight away increase the quality by brewing more.  Speed isn’t too much a factor in this situation.
  • No time here for water either, so it would happen later
Let me know about any other daily tasks you do that gets your brain bubbling like this.
Oops – almost forgot to drink my morning tea!

The Pheonix Project – My Favourite Quotes

Its not rocket science but if everyone in the world read this book we might be in a better place.

People are amazing, but we can only do so much at one time.

Some of my favourite quotes from the book:

 Unplanned work has another side effect. When you spend all your time firefighting, there’s little time or energy left for planning. When all you do is react, there’s not enough time to do the hard mental work of figuring out whether you can accept new work. So, more projects are crammed onto the plate, with fewer cycles available to each one, which means more bad multitasking, more escalations from poor code, which mean more shortcuts.

I dared myself to say this one for a project I was working on last week that we were desperately trying to fix up before a large deployment.   I said it,  the project got delayed.

 It’s not a good sign when they’re still attaching parts to the space shuttle at liftoff time.


Car Building Live – Kaizen, Testing and Good Changes

For the past couple of nights there has been a show on BBC called Car Building Live.  I’m not a car fan but to be guided through the process was fascinating.


They talked a lot about Kaizen.  Kaizen is the practice of continuous improvement, change for the better.  Making improvements is something I’m always looking into, in my work and personal life.  Why compromise and do things one way when we could do it better?

In the show they talked about Kaizen being a team effort.  Employees are encouraged to come up with 2 every month.  As they are the ones doing the work they will be able to come up with ideas for improvement.

My favourite example from the show was the Sticker Picker

Sticker Picker

Each car has 96 stickers.  The sticker picker shaved off 0.3 seconds per sticker.  Thats 28.8 seconds per car @1000 cars a day.   Works out at 8 hours a day which is one whole worker for a whole year.  Crazy.

Giving people time and the opportunity to make improvements has a really positive affect., however small they are.  It saves time and people feel like they actually make a difference.

Kaizen for testers

I thought about how this was quite similar to the dreaded regression testing.   2 weeks of a testers time to go through the core features of a product.  Of course there are many ways to solve this but a quick win is just to spread the load.  Get help testing, so testers don’t have to feel like the bottlenecks.   (I may have referred to this to my team as sharing the pain)

This then leads onto more people offering their Kaizens for testing!

“Lets automate this flow”,   “I could add a unit test for that”, or even “why are we even testing this, users don’t use this functionality?”

Its all good,  its all change

Final Thoughts

There is always room for improvement and you have to make time to do them.   There are a number of areas I know my testing can improve so I will share my Kaizens as I go.   My current Kaizen is about making testing reports more valuable.   I don’t believe that counting scripts of pass/fail and counting bugs gives a good indication on the quality of the product.   But thats another blog post….

Oh and I now really really want a mini!

To read more about Kaizens and Katas have a read of these

The Toyota Way

The Lean Six Sigma Pocket Book