Functional testing: Numbers vs Coverage


Functional test automation.  It’s not entirely about the numbers, but rather the value and coverage of the test you create.

Push left. Cover more in unit/integration tests and less on the UI. Try not to look at this as it takes away from you as a tester’ but rather enhances your ability, exposure and experience.

Its difficult to decide which tests to push left you say?

Yes, I can definitely agree with that. I was hard for me too.

I’ve learnt that this difficulty comes strong at first but when this is a practice we bake into our planning sessions, this becomes easier with time. Communication is the most important influence here. The results of which will lend to a “Team Test Approach” or “Quality mindful team”.




Are you BDDing?


There are many ways in which we can scribe out a feature file. In my experience with teams of various experience, businesses of different maturity and a variety of complexity of applications I have learned there is no 1 way to get this right.

Here are 7 things to remember:

  • Don’t just use the tool but use the tool well. Stick to the reasons why we use a ‘Given’, ‘When’ and ‘Then’
  • Remove test data setup from your scenarios. If you need to ready your env for test, treat it as a separate concern.
  • Tags, tag everything. This is a great way to ensure we run specific tests and deliver faster feedback when you are faced with a time sensitive roll-out.
  • A short scenario is a good scenario.
  • You scenario’s aren’t cast in stone. Revise and revisit.
  • Maturing your BDD is really important. Its living documentation and is ultimately a reflection on our understanding of the application and our drive for high quality applications.
  • Share it with your team. Make your team quality conscious. Have them revise it at regular intervals…make it a thing.

Building a Test Automation Framework


Spent a wet weekend indoors and decided to spin up a testing framework.  Here is my top 11.

What’s in it?

Java 8 Maven Spring Application.   + Cucumber + Selenium + Restful API Test Automation Framework + Postgres + Spring JPA.   This setup included :

  • Restful Api call and testing using RestTemplates and a Pojo for modelling the Json.
  • BDD with Cucumber for Feature
  • Webdriver   
  • Docker
  • Postgres Db   
  • Spring JPA   
  • Swagger Api Documentation
  • Rest Assured   
  • Page Object Modelling   
  • Saucelabs integration
  • Tomcat – Standard with Spring

What else should I add in here?

The word of the day: DIP


Ok, its not actually a word but an acronym.

In “The Dependency Inversion Principle” (or DIP), the author states the three defining factors of “bad code”:

  • It is hard to change because every change affects too many other parts of the system (Rigidity)
  • When you make a change, unexpected parts of the system break (Fragility)
  • It is hard to reuse in another application because it cannot be disentangled from the current application(Immobility)