Be on the same page with us
Subscribe to our latest news
By clicking the button Subscribe you give a permission for the automatic sending of e-mails

"Don't marry a tester!"
Interview with James Bach

Solvd continues a series of interviews with world's most famous QA & Development specialists by talking to James Bach today. James is the person for whom Testing is not only a job but his life. Having worked for Apple and Borland, he is now leading Satisfice Inc., a teaching and QA consulting company. James is the one who is behind the Exploratory Testing concept and the Context Driven School of Testing. His testing blog breaks all records of popularity over the globe.
Posted by Slava Smirnov
May 12, 2020
SOLVD: James, do you believe that broadly understood testing might play a bigger role in prevention of global crises like the one we are facing today? Do you think Quality Assurance should be spread more widely in all spheres of public life?

Yes. Broadly understood, testing is the process of living an examined life. Testing is critical thinking coupled with experimentation. Testing requires a certain faith in the existence of trouble.

And of course that's why people don't like it -- Who wants to live like that? I do, but I have a suspicious and protective personality. But most people, including my own wife, prefer to live more optimistically. (advice: don't marry a tester. I didn't marry a tester and I'm quite happy.)

Testing is like insurance. Before trouble happens, you see it as just another expense. Once trouble is happening, you wish you had gotten more insurance. But it's too late, by then.

SOLVD: What will be changed in Quality Assurance after the pandemic? What trends of recent years will still be relevant and what new tendencies might you foresee?

I feel certain that, at least for a decade or so, humanity will use this experience to prepare itself well for the next pandemic. But if that next pandemic doesn't happen within ten years, the systems put in place after COVID will begin to erode. This is a normal pattern in civilization: our memory for any given risk fades over time. For the near term, I predict we will develop better systems for disease surveillance. Epidemiology will temporarily become a very cool career.

Closer to home, in our industry, we may be in for a difficult time, economically. It's not clear that the tech boom is sustainable. But let's say that we shrug that off. There will still be one huge change in our industry, I predict: people will get used to remote work. We'll all get good at it, and managers will learn to do remote management. Then more companies will wonder why we are maintaining big expensive buildings when we can save money and have tech workers stay home, or at least closer to home. That, in turn, suggests less commuting and less traffic congestion. It's better for the planet.

I'm expecting to do most of my training online, even after this is all over.
SOLVD: In your Rapid Software testing methodology you proposed that QA engineers should be context driven and based less on predefined rules and patterns. Does that mean that curiosity and ability to ask right questions are the main skills of a good tester?

It suggests that skills and accountability should be more the focus, not rules. Management throughout the ages has indulged fantasies of turning workers into scripted robots. In fact the original meaning of "robot" was a human worker treated badly. Well, those management fantasies never work out. There is no way to script excellent work. Excellent testing comes only from skilled and motivated testers who are given the opportunity to do their job right.

You can't do good testing using that so-called "traditional" method of writing a lot of scripted test cases and then brainlessly following them. But poor testing can seem good enough, for the same reason that a fake smoke alarm seems good enough as long as no fire breaks out. My wife gives me vitamins, too, and I have no idea if they actually make me healthier. I take them to please her; because I believe pleasing her makes me healthier. That's all I know. But I'm not a vitamin expert. I'm a testing expert. Poor testing is not good enough for me.

Curiosity and the ability to ask questions are indeed important qualities in a good tester.
SOLVD: How to shape a good and functional QA team? What main features have to be taken into account?

First I would look outward, at the working environment. I can't expect to create and keep a good team of testers when they are not given the time, resources, and basic respect necessary to do their jobs well. This is a key management role: to create a nurturing environment for testing to happen. Testing is a delicate process that is easy to disturb, like growing some exotic plant.

Then I look inward and foster a culture of self-criticism. We should not want respect that we don't earn. I want each tester to see himself as a craftsman. Testers who work for me learn to challenge themselves and to be challenged. This is how we get good at what we do. It's really how anyone gets very good at anything.

I also look at diversity. Test teams are stronger, I have found, when we appreciate and respect our differences, and when we each are honored for what we bring to the team, and forgiven for not bringing everything. I don't feel I need to create diversity on purpose, because it's always there in some form, but neither do I avoid hiring people whom I predict will irritate me (which is what "hiring someone different" really means). Irritation itself is not always a bad thing. It can spur creativity. But of course I think that: I have always been an irritating man.

After those considerations, I embark on systematic training. Most testers have never seriously studied their craft. So, we just have to learn on the job. I would drive that training with gusto.

To do all this I would need strong top management support. But the result would be a high morale crew of testers who could not be bullied. Our team would not only find trouble but also predict trouble. This would cause friction with developers. If there is poor leadership among the development staff, they would try anything they could to undermine the team and replace us with a docile herd of sheepish testers from Cognizant.

That's why you don't see a lot of highly effective test teams in the industry. And why Cognizant is very large.

SOLVD: Test automation, according to your opinion, is more a bug checking instrument rather than a full value software testing tool nowadays. Naturally, humans are behind the wheel. What do you think regarding the future of test automation? Solvd developed Zebrunner, a cloud-based Selenium automation hub, so we are an interested party :)

I don't agree that testing can be automated. I think you are talking about automating something that is only one part of testing: user simulation. Tools to simulate user actions can be very helpful. I have no problem with them, unless people are devoting too much time to create too little value. All those little scripts too often lead to trivial and shallow testing, when all is said and done.

(BTW, instead of "manual testing" which makes it sound like brute labor, I prefer to call it interactive or experiential testing. When I use a tool to automate what a user does, I lose the interactivity and I lose the experience of the product. This can be okay, of course. Not all testing needs to be fully interactive or fully experiential.)

As a programmer, I write tools whenever I test. I am a big fan of automation that HELPS testing. But remember there are lots of ways a tool can help-- simulating a user is but one of them. My favorite kind of automation is data generation. I can write a tool to do that and then use that data to interact personally with the product.

SOLVD: Thank you very much, James!

You can follow James on Twitter