In my previous post I discussed some questions around UI automation testing for iOS applications. I looked into questions regarding stability and the use of stubbing data as a base for most UI tests.
Choosing the right tools
The most important part of doing automation is to choose the right tools. There is plenty of choice on the market for UI automation testing tools for iOS. Appium, Calabash, KIF – these are just some of the big players you can choose from, not to mention a large number of smaller ones and one native tool – Apple UI Automation. All of these tools have some benefits but also some disadvantages.
The main challenge is this: there is no ideal solution. Continue reading
The gong went off with a humming twang.
Around the table, 20 people sat staring. Our agile web team had kicked off many sprint planning meetings, but none like this. As the sound of the Tibetan meditation bowl receded into silence, nervous impulse rushed to fill the space – fidgeting, murmuring, exchanging glances. After 30 seconds or so, this noise died down too, settling into a deeper silence still. Once another half-minute had passed, I rang the gong again.
We then proceeded to have one of our most efficient sprint planning sessions in weeks. We even finished 15 minutes early. Not a bad return on investment for one minute of silence. Continue reading
Our team was tasked with creating a new RESTful API to help reduce the amount of logic that is implemented in potentially different ways across our front-end channels. One item discussed early on was if we should try using JSON API to structure our responses.
Other teams within Trainline have had some success creating JSON-API-based services in Ruby, and we saw no reason why our C# implementation would be any less successful. This blog post is an attempt to tell the story of the journey we took and where we ended up. Continue reading
I was selected for the Trainline graduate scheme right after university and the first few weeks here have been a new chapter in my life. It might be somewhat confusing for most people how an Aerospace Engineering graduate finds himself starting out at a tech company that deals with trains. Software was always a key part of my work in engineering and I have always wanted to learn the tricks of the trade in this sector. What better way for me to achieve these goals than to join one of the most innovative e-commerce companies in Europe? And, more specifically, in a team which is responsible for so much interaction with the trains on the ground? Continue reading
Since my talk at AWS re:Invent in December, we’ve had a lot of questions about how we tackled our Oracle Exadata migration to AWS.
This post goes through our Oracle migration journey in more detail and also includes some general tips for moving large databases to the Cloud. Continue reading
We recently started working on rebuilding the desktop version of the Trainline website. It is a big deal for the front-end engineering team because we have to make sure every choice is justified so that the user experience is never compromised. I am writing this blog post to explain how we went about selecting our front-end tech stack and why we made these choices. Continue reading
From Change Control to Assumed Approval: how we first managed the operational visibility of Continuous Delivery and how it’s still in use 2 years later
Trainline has changed in many ways over the last 2½ years and, as a 4-year veteran, I have been ideally placed to watch and help enable that change. One of the big changes was from a project-led to a product-led organisation. Along with that comes lots of things, one of which is Continuous Delivery (CD). The advantages of this are well known, and one excellent stat was recently produced that showed that we have achieved a:
122-fold improvement in deployment agility!
2016 has been a very busy year at Trainline as we have been growing at a rapid pace. This means our tech team has had to work hard to scale effectively and cope with the sheer demand.
New product teams have been springing up all through the year, while older teams have grown and been split into sub-teams to maintain the essential agility of small teams. With such growth, we have needed to ensure our processes were in good shape to manage the increased complexity that this brings.
Here are a few fascinating stats which tell a short story of the year at Trainline … Continue reading
Hacktrain is a three day hackathon on a train. Around 80 software developers, designers and entrepreneurs from across the world gather together to imagine a better travel experience for the rails. The best ideas win a trip to Hong Kong and an assortment of light sabers, drones and other suitably geeky toys. Continue reading
About our App
The Trainline app is a ticket-reseller market leader with more than a million active users. So you can imagine that the quality of our app is one of the main things we care about. The ability to spot issues quickly and capture crashes is critical for the apps of this scale and complexity. And as we are always developing something new and updating the application continuously, we must make sure that we have a fast and robust way of making sure that we do not break anything on the way.
As with any responsible team, of course, we write unit tests for business logic, and we also have integration tests for some big system components. But we have started to get a sense that we are missing something and this something is quite big piece of the puzzle in order to get the right level of confidence about the quality and stability of our application as the team makes code changes from release to release. So we started thinking about this. What is missing? Logic is tested and covered. Even complex class interactions are covered, but what is missing?
Of course, one of the most crucial parts of the application to test is the UI! The most prominent piece of the application that people are guaranteed to come into contact with in their daily use of the app. If something breaks the UI, if something breaks in screen interactions, it will inevitably lead to a very obvious bad user experience and we definitely don’t want to upset the users of our app at all!
To address this issue correctly, we first identified any obstacles that we might face while working with a UI test automation suite: Continue reading