A great presentation from the recent 2018 Selenium Conference with a few shout-outs to this blog. I really like what Wes and Kurt were able to achieve using AWS Lambda – amazingly fast e2e tests running in parallel.
This is an approximate transcript of the talk I delivered at TestBash in Sydney on Friday 19th October 2018.
Today I’d like to share my story about how we started with automated end to end testing at WordPress.com since I started at Automattic over 3 years ago.
I only speak at one conference a year and this year that conference will be the first ever Australian Testbash in Sydney on October 19, 2018:
At WordPress.com we constantly deliver changes to our millions of customers – in the past month alone we released our React web client 563 times; over 18 releases every day. We don’t conduct any manual regression testing, and we only employ 5 software testers in a company of ~680 people with ~230 developers across . So, how do we ensure our customers get a consistently great user experience with all this rapid change?
Our automated end-to-end (e2e) tests give us confidence to release small frequent changes constantly to all our different applications and platforms knowing that our customers can continue to use our products to achieve their desires.
Alister will share how these automated tests are written and work, some of the benefits and challenges we’ve seen in implementing these tests, and what we have planned for future iterations.
Takeaways: How to effectively use automated end-to-end testing to ensure a consistent user experience in high frequency delivery environments
Grab a ticket before they sell out #
2. Go out on a regular speaking circuit tour which is going to require multiple days of travel multiple times a year. That’s too disruptive to our own work schedule and to your fellow teammates.
For this exact reason, without knowing, I created my own personal rule2 of only committing to doing one conference presentation per year.
This are my slides during my presentation on distributed testing at the ANZTB Test 2017 Conference in Wellington, New Zealand last Friday 5th May 2017.
I learned who you were by watching your Google automation talk last year in 2015. Your presentations are really nice. Are you planning on giving any other presentations this year or next year?
My short answer is no.
My long answer is also no because I actually don’t actually enjoy giving presentations at all. I wrote about my battles with anxiety last year and whilst I am 90% better than I was, last year I committed to present three talks in less than two months which resulted in me having panic attacks about giving these talks. This wasn’t fair on my wife or children who I need to support on a day-to-day basis.
Each talk requires a huge amount of preparation and since my personality leans towards perfectionism I wanted to make sure each talk was as good as it could be, so I wrote every word of each talk and (unsuccessfully) tried to memorise these. This resulted in me delivering the talks partly reading what I’d prepared, which I wasn’t happy about as I was comparing myself to others who delivered their talks without notes.
The reason people give talks is that speech is an amazingly effective communications tool – probably the most so – yet it’s a drastically inefficient communications tool – each minute of a talk requires at least an hour of preparation. I much prefer written communication as I find confidence in writing, and I hope with frequent, thoughtful updates to my blog I can reach a wide audience and still be effective in spreading new ideas.
I enjoyed your GTAC presentation on “your tests are not flaky“. How did you pick your topic?
Firstly thanks for the compliment, you’re very kind.
When I came up for the topic I was working on a system where we were practicing continuous delivery by frequently doing production releases. As we began releasing more frequently the business expected this and so the reliability of our automated tests became more important. We wouldn’t release on a failed build since we were working on a high volume eCommerce site where a small bug could cause an outage costing a very large amount of revenue. We didn’t have a team of testers to fall back onto for any manual regression testing, so we were 100% dependent on our automated tests.
Even though we were clever about building testability into our system, we still had too many full-stack automated tests which would create non-deterministic results.
I believe everyone looks at the same thing slightly differently as we each have a unique lens that we see our world through and everyone’s lens has varying degrees of difference:
“Each of us tends to think we see things as they are, that we are objective. But this is not the case. We see the world, not as it is, but as we are—or, as we are conditioned to see it. When we open our mouths to describe what we see, we in effect describe ourselves, our perceptions, our paradigms.”
~ Stephen R. Covey
As people who were developing and maintaining tests, we were looking at our non-deterministic tests as the test’s fault. What we didn’t do was look through another lens to see that it could actually be the fault of our system as we had built it instead.
This aha! moment struck me when we released a bad build to production that had passed all automated QA by someone re-running our automated tests a number of times (to get them to pass).
We were blinded by perceived ‘test flakiness’: we refused to believe our problems were something else, so I thought it would be a good topic to present. From the feedback I received both at and after the event, it seems I am very much not alone.