Reuse/re-purpose existing steps in your code by using the pipe delimiter.

@Then(“^(I search for and select an existing user|I validate a user has been created)$”)

– Use this sparingly and make your BDD’s more readable.

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

 

 

 

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.

To spin up a WebDriver is pretty easy. We really only need 4 lines of code:

System.setProperty(“webdriver.chrome.driver”,”…”);

WebDriver driver = new ChromeDriver();

driver.manage().window().maximize();

driver.get(“http://…”);

For manual testing, Postman is a great resource for API testing. Validate your results post call using their inbuilt test functionality.Here is a link to some test examples.

https://lnkd.in/g5qnF48

 

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 Struggle is real!

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)