Category Whitepapers and Guides
How do we deliver quality software at speed? This was the theme of Agile & Automation Days 2019, which was held in Poland from the 28th to the 29th October 2019. A few hundred quality specialists from around the world gathered in Gdansk’s impressive ‘Museum of the Second World War’ to explore this theme through a variety of presentations and workshops.
The conference building itself was magnificent. The main auditorium was impressive with its stage and lighting, and the second room was a cinema auditorium which provided a more intimate feel. The conference’s networking party occurred at a local brewery where attendees were able to sample traditional Polish beers. I’m not going to lie, it was a great experience all round!
Once again, I was presenting my talk ‘Coaching Your Team to Test’, which made up just one of the talks in a great line-up – including keynotes from Mirjana Kolarov and Bart Szulc. Speakers had travelled from as far as Australia, but there were also many local speakers which is always great to see. The topic of the talks was also mixed, with some focusing on people and culture, and others on technology and tools.
The quality of the talks did not disappoint either, resulting in me finding it very hard to limit this review to five main takeaways. These were the standout presentations for me:
It turns out the joke has no punchline! But no punchline was needed for Anne-Marie’s opening keynote to hit home for attendees. Anne-Marie discussed the idea that quality is ‘everyone’s responsibility.’ This idea is valued across companies across the world, but what does it actually mean?
This keynote discussed the idea from the book ‘Lessons Learned in Software Testing’ that testing is the headlights of our software projects. But Anne-Marie argued that it is so much more than this. Continuing with the car analogy, Anne-Marie compared testing to the car’s fuel gauge, speedometer and GPS guide – amongst other components.
Speed to market is a quality attribute, so who are testers to stand in the way of that? It was stated that testing will move into more of a coaching role in the future. This will enable other members of the team to be able to test and accelerate the process of delivering software.
Anne-Marie also invented the word ‘Qualitability’, a way to measure quality metrics at any point in time. These metrics should focus on team based as well as business outcomes.
The talk concluded with Anne-Marie’s quote “software testing of our software products. The audience really enjoyed Anne-Marie’s talk and rightfully so!
I have been a big fan of Rob Meaney’s work on Testability and Observability over the past couple of years, so his talk on Observability was one of the talks I was looking forward to most.
Rob began by posing the question: how can we deliver value reliably and ?
Delivering software is the beginning of your software development journey, and not the end. As teams, we need to balance mitigation, detection and recoverability. Rob stated that if your team isn’t testing in production, then it’s your customers who are testing in production. Which is not something all business can afford to do.
Using feature toggles during Black Friday, Rob’s team were able to safely roll out a new database layer as they had great monitoring metrics in place.
Rob shared three questions to get your teams thinking about observability:
Whilst the answer to these questions will change according to the project, these become a good starting point in those initial meetings to ensure you’re thinking about testability and observability at the beginning of your software delivery journey. I really enjoyed Rob’s talk. It was packed full of great models and heuristics. You can read more in my live Tweet thread.
Bas opened his closing keynote by asking ‘how fast would you drive if your car had no brakes?’
This question was met with multiple replies, but the consensus was unsurprisingly ‘not very fast.’
Bas continued his keynote focusing on the idea that automated tests are the brakes of your software development process.
As software development teams, our tests should give us confidence and allow us to go faster. We shouldn’t be writing automated tests for the sake of increasing the number of tests in our test suite. Our tests should provide us with valuable information that cause us to slow down or keep accelerating towards a release.
When I first got into writing automated tests, Bas was one of the first people I discovered on Twitter and LinkedIn. It was great to be able to see him share his ideas on automation strategies and the value automated tests provide us in person. Be sure to follow him on social if you’d like more insights on automation in the testing space.
According to Viktor, people should be interested in testing at the Application Programme Interface (API) layer as it provides you with relatively fast feedback. It also gives you good visibility of why something has failed. His inverted pyramid of failure (pictured above) demonstrates that the UI and web service (API) layers give us the most visibility as to why something has failed.
Like any form of testing, writing API tests should be done with goals in mind. If you don’t understand the purpose of your tests, then why are you writing them? APIs can be exploratory tested like any other piece of software. Don’t just stick to the ‘happy paths’ or API documentation when testing endpoints. Write tests that put the software under pressure, not tests for the sake of having passing tests.
Lukasz began his talk on performance testing by sharing some industry statistics.
47% of our users expect our websites to load within two seconds. 40% of our customers will leave our website if it takes longer than 3 seconds to load. A one second delay will result in 7% less conversions.
These statistics are striking, and are a great reason why performance testing should be at the centre of any team’s strategy.
The first step to writing performance tests is to gather requirements. For example, ‘How many users do you need to simulate using your product at one time?’ is a great starting point and links back to a talk one of my colleagues did on ‘Lukasz describes the need to create a solution which can run in your CI/CD pipeline, on demand and not just on your local development machine.
Throughout the presentation, Lukasz demonstrated the performance testing tool Gatling. This tool can be coded using its own Scala API and operates using an Open Model. An Open Model means requests are made independently, rather than threaded and waiting on other requests to be returned before firing off the next request.
By using the Gatling AWS Maven Plugin, Lukasz was able to scale tests from zero to however many they needed. This talk was my favourite technical talk of the conference. It demonstrated Gatling in an accessible way and described the problems that Gatling can solve clearly.
Agile & Automation Days was my last conference of 2019 and it didn’t disappoint. As a speaker, I was well looked after and enjoyed a speakers’ dinner the night before the conference. It was a great way to meet and network with fellow speakers at the conference.
I also enjoyed discussing a variety of different topics with fellow attendees from across the world. It’s a conference I’ll keep on my list to attend in future years.