This interview with Isabel Evans, learn about artificial intelligence, communication, and the evolution of software testing in terms of Agile, QA, and DevOps.
At the StarEAST software testing conference in 2017, Isabel walked onto the stage during the popular “Lightning Strikes the Keynotes” session and delivered a presentation on ancient Scottish sheep farming practices. The talk, which could only last five minutes, was informative, witty, profound, and extremely relevant to software testing — all at the same time.
That is Isabel Evans for you. A highly regarded speaker in the conference circuit and luminary in the software testing world, she approaches the challenges of quality assurance with deep insight. Combine that with her thirty years in the IT sector and you get a rare, tour-de-force perspective — one that can tackle the daily challenges faced in QA from a broader, “big picture” position.
If you want to see Isabel speak in person (and you really should!), check out her upcoming events and master classes here .
Since then, I have developed several interests. I am interested in user experience, UX design, and testing, and about how you can take the engineering qualities in software and see how they merge into UX attributes like trust and flow.
Another area that I have worked in is organizational quality, where I explored organization excellence and improvement. IT is really just a tiny part of the picture; it is just a service into the rest of the organization. So how do we, as an organization, improve and build better things?
Within that, I developed an interest in team work and how people interrelate. That was partially driven by the fact that I am not particularly good at teamwork and networking myself. I realized that there are many other people in the IT industry who are not particularly comfortable with that either. It’s a bit of a stereotype, but sometimes those stereotypes are there because they fit.
So, I started looking at ways in which you can work with other people even if you are not necessarily comfortable doing that. A lot of the techniques companies put into place (for example, formal reviews) are about getting people to communicate and giving them a structure within which to do it. How do you develop those structures so that they are flexible and encourage people to communicate in ways that are positive?
All of that has come together into my main interest at the moment: The UX and usability of testing tools for testers. There is a big focus in the industry right now on the fact that test tools are not necessarily easy to manipulate. For a while, people have been saying that testers need to become more technical so that they can fit the demands of the tools they are trying to use and leverage them more easily.
So, it’s not an issue with testers only; it’s a whole UX problem within the software industry.
At the same time, development has gone from small focused teams working on a specific problem through to big projects with silo working and now coming back to people saying they need more frequent deliveries — essentially, the rise of Agile and DevOps.
I find it quite fascinating that it feels like we are just cycling.
It seems to me like there is a tension between a desire to create in a completely free sandbox and the need to control that space out of a desire to “become serious about it.” The problem is that if you control it too much, you damp down the creativity and people will eventually feel like they need to burst through into the “next thing” open sandbox. It’s a sort of evolution in how people deal with ideas.
Much of that fear now revolves around artificial intelligence, but the truth is that it still looks like we are nowhere near being able to relinquish the running of the world over to machines. At some point, if that arises, we may be in a new reality of perpetual leisure. But at the moment, all the automation we see requires human interaction or human direction. How long will that last?
When I was first in the industry, studying computer science, my final thesis was about whether machine intelligence would ever be possible. I focused on the subtopic of natural language processing. Back then, the idea that anything like Siri or Alexa would exist was laughable. It was not that long ago that people thought that kind of technology was simply impossible.
It’s the same with things like DevOps and continuous delivery.
The funny thing is that some people who were the earliest adopters of Agile are now saying that it has morphed into something that is not what they intended. As it becomes more widely adopted, it becomes standardized, there are certificates associated with it… it’s not new and exciting anymore. They are pushing things in place to make it safer, which makes it less appealing to the early adopters who will begin looking for something new. Agile needs to change and adapt in order to be agile.
So when we talk about that tension between the free sandbox and the need to be “serious” about doing something, we can identify the same tension in Agile and DevOps.
When you set up an agile co-located team, you will certainly have shared spaces, but it is also beneficial to have “caves.” Once you go into your cave, you can be left alone and work on something without needing to communicate. That gives you the rest you need to be able to deal with things in a common space. Remembering those human factors is very important because it is just as bad to force everyone to be in constant communication and interaction as it is to force people into silos.
Here is another question you need to consider in regards to whether communication is improved or not. Suppose you have set requirements that are stable and very complex. The best way to communicate those requirements could be to write them down and then study them very carefully. And if you are dealing with something that is stable and complicated and you have the time to do it, a formal review might just be a better solution than attempting to understand the requirements via Agile story cards.
There can be a “baby and the bathwater” issue with this sort of thing. The principle of Agile is that you are flexible to change how you do things based on the project or requirements. Not all the practices of Waterfall are bad; sometimes, they are the best approach, and it should be within the scope of Agile to realize and implement that appropriately.
