One thing I enjoyed was that lunch was provided. This means nobody had to leave and we got to meet and talk to fellow test-bashers. My favourite part of any conference or meetup is meeting folks. You can learn from talking to fellow testers just as much if not more than from some talks.

On to the afternoons talks.

Shift Left, Shift Right, And Improve The Centre – Augusto Evangelisti (@augeva)

Gus started off by saying it was ok to sleep during his talk as he had the after lunch death slot. Of course Gus is way to energetic for anyone to fall asleep.

He started out by busting some myths about continuous delivery (CD). Such as:

CD does not work for complex things

CD teams have buggy software

CD can only work in non regulated industries

Gus went on to mention various companies such as Facebook who proved these wrong. We tend to complain that our software is too complicated for this to work with, but we would be lying if we said we are more complex than Facebook.

A team should be able to envision, analyze, monitor, and support software. Teams can do this, in three main brackets, left, right and the centre.

Shift Left:

Reduce the complexity of the code. Chunks of code should be small, Gus said about the size of your head. This makes it easier to review and maintain.

Using BDD as a collaboration tool will help keep work focused and uncomplex. This leads nicely into test automation. Pair programming can help reduce complexity and ties in well with code reviews. Another cool idea was mob programming. Maybe trying it for one or two stories and seeing how it works. Of course impact mapping is also a brilliant way to question the value of features, before any code is written. Gus then mentioned improving testability but thanks to Rob from the morning did not have to delve into the subject. Another good shift left activity mentioned was WIP limits, this allows a team to focus on tasks and actually start getting work finished not just started.

Improve The Centre:

The centre is usually where we live as testers. We are used to exploratory testing and getting bugs found and fixed. But Gus says to help improve here, we can teach others. We can pair up with our team mates and teach exploratory testing. We can help everyone to get thinking like a tester, and at the same time improve our own dev and analysis skills. Pair exploratory testing is a great way to do this. Even showing some testing in the demo can help explain how we think, and help share ideas.

Shift Right:

Right shifting is all about finding the value in what we do. This is where we engage the customer. Gus suggests monitoring the customers use of our software. We can then see what is used and what doesn’t work. This allows us to use customer feedback to design new products. A great way of doing this, is by using canary releases. For those who don’t know what this is, here is Martin Fowler’s explanation: Canary release is a technique to reduce the risk of introducing a new software version in production by slowly rolling out the change to a small subset of users before rolling it out to the entire infrastructure and making it available to everybody.

As testers how can we help do this? Gus answered by saying we need to develop three core skills. These are:

Active listening

Empathy

Influencing

A Test Pyramid Heresy – John Ferguson Smart (@wakaleo)

John says that test automation is like any other tool. It is either a benefit or a hazard. So we need to ask ourselves, how much are our tests worth? Three questions we can use to figure that out are, why, what and how.

Why are we doing this?

What are we trying to test?

How are we going to test it?

Without asking these question the testing pyramid can very easily turn into the testing ice cream cone. Don’t use a web test when a service or unit test could do the same job. My favourite point John made was about writing unit tests. Writing unit tests after the code is written is largely a waste of time. Unit tests that are written after the code, will perfectly test that the code is doing the wrong thing. If we write the unit tests first we can guide how the code is written.

Tests come from different sources. There are three main areas:

Business tests – Typically acceptance criteria and created using BDD (feature mapping/example mapping).

QA tests – Usually exploratory and found manually.

Developer tests – These are usually unit and integration level tests.

Instead of focusing on writing loads of tests, start by writing examples of how the API should work. Tests should have three main roles:

Discovery – Using tools like impact mapping to help figure out what features are valuable. Describe – BDD tools to help describe and document the software. Demonstrate – Tests should show the code does what you expected it to do.

Testing In Production – Jon-Hare Winton (@jonhw87)

My first thought when I heard this title was, this man is insane. Testing on production is pure madness. But I decided to put my bias aside and see if there was some method to the madness.

Jon started by saying we do most of our work very far away from where our users are. Test environments are not an accurate portrayal of live. OK he has a point here. Jon then says what’s wrong with our test environments. We test something, make a mess, don’t clean it up and move on. This leaves us with a really messy area to test. They are lower in importance to our dev environments so don’t get the same level of maintenance. They are inaccurate and full of weird test data. Are they really a good environment to use the software the same way as our customers?

Feature toggling was Jon’s recommendation. What has worked for them is toggle something off to the customer, but start testing on live. Jon was saying they started slowly, just manual testing, just a little bit. Eventually the automation was run on hidden live environments. So once the feature is tested on live it can then be toggled on and the customer gets to see and use it.

I was sold on the idea. I now want to try it. Testing on production, maybe not such an insane idea after all.

The End

This is where my notes ended. My head was about to explode with all the information I had taken in over the day. I decided to just listen for the last two talks. So I must apologise to Sharon McGee, and Simon Tomes (@simon_tomes ), for not having any notes.

Luckily though it has taken me so long to get this second post out, the talks have since been put online. I highly recommend everyone get over to the dojo and watch the talks, especially the last two, they were fantastic.

They can be found here: https://dojo.ministryoftesting.com/series/testbash-belfast-2017.

You can also look out for me messing up a 99 second talk, by not being able to make a solid point in 99 seconds (shocking I know).

Roll on Test Bash Dublin, watch this space for more details.