TestBash Brighton 2018 – a first-timer’s impressions
Although I‘ve been engaged in testing work of one sort or another since 1995, it’s only been since joining CELCAT in 2016 that I’ve had any sort of contact with the testing community. This came about because Ben Fellows, one of my colleagues on the testers’ team, was heavily involved in that community and encouraged new colleagues to take part. As a self-taught tester whose involvement in the craft pre-dates the main qualification in the profession, I jumped at the chance, participating firstly in the local Midlands Testers meetup, then exploring the on-line resources provided by the Ministry of Testing (which models itself on the night-club Ministry of Sound, rather than on any Government department), and finally attending their annual conference, TestBash Brighton, for the first time this year.
TestBash Brighton was their original test conference, and 2018 was their seventh such event. The format has proved so successful that it has spawned similar events in Manchester, Dublin, Munich, Utrecht and even Sydney; and similar conferences are springing up world-wide. Talking to test professionals in meetups, at conferences and online, one of the common themes that arise is that testers do not necessarily come from any sort of uniform background; indeed, the diversity of our various experiences is one of the strengths that the profession is beginning to appreciate. It is because of this diversity, and the variety of reactions to the very concept of “testing” that arise in different organisations, that the testing profession is evolving an idea of itself as a discrete discipline.
This was certainly reflected, for me, in one of the most noticeable things about TestBash itself – the levels of energy and commitment that were self-evident through the conference, starting with the organisers and spreading to the attendees. Many of those at TestBash were almost evangelical about testing, both in their work and in their daily lives. Certainly, the organisers’ personal enthusiasm spread into the conference itself; they were organising it because testing was their passion first, and their job second.
(Although this was my first TestBash, it was certainly not my first conference; as a veteran of different conferences and conventions in a number of spheres, and a frequent speaker in front of large audiences, I recognised a lot of what I was seeing and could draw parallels with similar experiences elsewhere.)
This TestBash concentrated on a number of themes that are current in the IT industry generally. One is test automation – using computers to test computers, replicating the steps necessary to ensure that computer code is checked to try to ensure that applications work first time. A parallel thread was that of “exploratory testing”. Some people think that test automation means that there is no need for actual people to test applications. But automation is only part of the story. I like to use the analogy of test pilots. A test pilot doesn’t start by flipping all the switches in an aircraft’s cockpit to make sure that the landing lights work or the undercarriage retracts. That’s done on the production line before an aircraft ever flies. Rather, the test pilot gets into a new aeroplane to try it out, to establish the parameters of the “flight envelope” (how high the aeroplane can fly, how fast, how low and how slow), to explore the performance of the aeroplane against the specification, and to try it out in practice, to see if any unforeseen problems arise in everyday use and to see if it is safe for people to get on that aeroplane and use it, day in and day out. This is something that only human beings can do by taking the role of the end user and reporting any issues, from the trivial to the highly impactful.
This process isn’t guaranteed to find every problem – no piece of software can ever be guaranteed 100% bug-free – but proper, focussed exploratory testing can hopefully find the worst issues and highlight them so that the business can decide the priority for fixing them. Obviously, the more this can be done before the application is shipped, the better.
Other sessions looked at issues relating to the management of testing using what is known as the “Agile process”; whilst there were some speakers who looked at wider workplace issues about keeping people in general, and testers in particular, happy, healthy and productive, and how to support them when these things go wrong. Some delegates queried whether this was the right place to raise such issues; but TestBash is set up as a “safe space” where testers can discuss any matters that concern them, and there are not many forums nowadays where grassroots workers can get together and explore some of these issues.
The CELCAT test team found TestBash a useful and enjoyable few days which has given us a lot to think about. Ultimately, the aim is to use the best and most up-to-date techniques to improve the product that CELCAT creates and to improve the customer’s experience. CELCAT’s testers are an integral part of that process.