Testing Talks with John Ferguson Smart

Testing Talks is a series of interviews highlighting well-known personalities from the world of software quality and testing. In this new episode, we had the pleasure to talk with John Ferguson Smart.

You can watch the interview on YouTube, or directly head to the transcript below.

Can you introduce yourself and your background?

I'm John Smart. I've been working in Agile for several decades. I created a test automation library framework and I wrote a few books on Agile development. One of them is called ‘BDD in Action’ and the second edition is coming out shortly. I have been doing software development since the mid 90s in different forms. I got involved in Agile development in the late 90s, early. I started getting involved with BBD, more particularly, when I started working in London. In fact, I was hanging out with the London XP practitioners and worked with a lot of very smart people there who were floating around ideas like TVD and BBD, and practices like that. I picked up a few things there and started applying them. I've been coaching teams in XP and Agile in general. I think the first one was in Egypt around 2001-2002.

I've sort of watched the evolution of test automation over the years going from automating test scripts to clunky big commercial tools to Selenium or JavaScript tools. I’ve been watching this evolution with great interest - seeing things like low code and no code tools coming out.

What I do in my day job is more about helping teams but also bringing testers up to speed and running a thing called the Serenity Dojo. It is a program for manual testers and testers who are new to test automation and get them up to a level of what I'd consider to be a senior test automation level. Because I think there are too many testers held back by not knowing the right way to go about test automation, not knowing the right techniques. And these are not necessarily complicated techniques, but nobody shows it to them. And a lot of the people who do teach or a lot of the courses which get taught aren't necessarily very helpful a lot of the time. So I am trying to bring testers up to speed that way.

What motivated you to get into this industry?

In testing? That's a really good question. I drifted into testing from the BBD space. I've always been interested in the testing world. When I was a technical project manager, I was involved in testing activities, in measuring defect rates, in studying models... I've been involved with the testing side of things for quite a while, and I think it all started in Sydney in 2011. I was helping teams do test automation there. And then one of my friends' managers at the time proposed this idea of what if you could use tests to document applications? What if you use tests to be able to document features? And so we talked about that. I thought that was a pretty cool idea and I came up with some prototypes. I got more involved in test automation – I mean I was teaching test automation before that probably in 2005-2006 – but actually getting into writing the tools and creating a test automation tool that would not just automate tests but also document features was new

What do you love the most about your job?

I like to see the evolution that people make in their work, in the way they work; when they learn to write good test automation techniques or to use really effective test automation frameworks.

I find it satisfying to see tests move from writing very crude ad hoc test scripts to tests that take less time to write new scripts. So it's sort of about what I like seeing. What I enjoy most about my work is just seeing that impact. Seeing the impact of when you teach people a technique and they pick it up, apply it and run it and how it actually has an impact on their career. It is not just about the theoretical esthetical idea of writing nice code but the concrete impact it has on the projects earning and on their own career paths.

Do you have an anecdote to share?

I have lots of anecdotes… There was one project I was working on, and we were doing a requirement 3 Amigo sessions. The Product Owner came up with the requirements, saying: ‘Right. Well. What needs to happen is we need to upload an Excel spreadsheet into the database, and then it needs to send out a message into our workflow system where all the system users have to be notified. And then they need to be able to update the workflow state or change the state and make this spreadsheet.’ It was basically all about locking down data. They could upload a spreadsheet, but it couldn't be changed. And the only way to change it was to submit a workflow process where they could go into the workflow and modify the data, and then they had their permissions and access rights. It was a very complicated system and one of the testers there on the team said ‘Yes, but why do we need to do that? What's the reasoning behind it?’ We were sort of doing the BBD approach of having three Amigos and being very analytical and critical about requirements as it came through.

I'm always asking, why do you need this? What's it for? And the PO said ‘Well, we need to do this in this way because that's the way it's always been done, that's the way it was done with the previous application.’ And so she asked her why was it done like that in the previous application? And turns out it dates back from an application before that, two applications back. It was where this file got uploaded, and the file was basically a reporting file from vendors about a bus timetable system. But basically, did the buses run on time? They had to upload statistics and pass a certain date. They weren't allowed to modify those statistics. And so they had this whole workflow in place because of the original system. So, one of the developers said, “Well, why don't we just send an email notifying everyone that this data has been uploaded?” And it turns out that's actually all that was needed.

So this requirement went from about three months work to about a day or less because the tester was asking these questions. So I quite liked that story. It saved the government department quite a lot of money just by asking the right question. I think that shows when testers do get involved earlier on, not just waiting to test stuff that comes out the end of the pipeline, but are actually involved in the requirements' discovery. The critical mindset that you have as a tester can really help to prevent waste much earlier than people often think.

What are the main points to succeed in agile transformation for you?

So the main success criteria of an agile transformation… I guess at the end of the day, are you delivering value sooner, and can you adapt to change? That's what agile essentially is about. Can you adapt to change more readily? But generally speaking, that's quite hard to measure, and you don't actually measure that until a fair bit down the line. So the thing I tend to keep an eye on is little things, little what I call proxy metrics. Like, how often do you deliver working software? How early do developers or development team members, including testers, get involved in requirements discovery, in talking about requirements? Do you have a testing team? If you've got a separate testing team, it's usually not a very good sign on the agile front. Do you have a UAT space? Do you allocate time to UAT testing at the end of each phase? Those

things tell me that we're not really doing things in a job way. So when I see teams that plan three months of work, and then they have another two months following that to actually do testing or integration testing or UIT testing or whatever they want to call it. That usually tells me that there is an agile process. Their agile transformation is not as optimal as it might be. And they're not actually using an agile approach if it's delivered when everything is ready. And that includes the testing.

How should companies organize testing teams for better efficiency?

Read full article on Agilitest' blog.