Remember that machines can’t think. Interview with Paul Carvalho. Part II
Today a1qa continues interviewing Paul Carvalho, a software coach and practioner. You can check part 1 of the interview published on Thursday. This time we try to cover the issues of testing tools and Agile methodologies.
a1qa: We have been discussing the role of electronic tools and automated methods with many previous interviewees. The opinions were different to be frank. So, what do you think this is evil or panacea?
Paul Carvalho (P.C.): I don’t believe electronic tools will ever be the remedy for all diseases. I think that impression comes from the current statistical distribution of the general QA/Tester population. That is, we see a large percentage of testers focused solely on doing functional/black-box/system testing, so that is what most people (e.g. managers, developers, general public) think of as Testing. Therefore, automated/electronic tool vendors service that field, and that is where the “human vs. automation” debate festers.
Always remember that machines can’t think. The most important tools in your QA/Testing arsenal will always be your brains and your collaboration with others. Computers do what they are told, and nothing more, and that is a very narrow (and potentially dangerous) way to see the world.
If the majority of QA/Testers are doing work that can be better and more reliably performed by machines, then that testing/checking should be automated. That is the logical argument. But of course, we are talking about people here, so all this emotional stuff filters into the arguments and pollutes the logic.
I have no problem automating people out of a job. The reality is that if you do something that can be better performed by a machine, you need to take a good long look at what value you think you are contributing to the project and team. Is this an evil point of view? No. Humans should do creative, imaginative work, not boring, repetitive tasks that they are likely to mess up because, well, they are human.
The pinnacle of test automation on a development project may be found on a team following the Continuous Delivery model. The developers are responsible for automating all the risky parts of building software (including the majority of tests) so that it becomes boring and routine. This is a good thing. We don’t want software releases to be risky or stressful. We want them to be easy and quick so that we can release often and with confidence, and have our weekends free.
There is an opportunity here though. The Continuous Delivery practitioners say that we need some good thinkers (e.g. exploratory testers) to help the team see beyond the traditional automated checks. Good testers are amazing thinkers. They are valued and highly respected by developers who recognize their contributions above the usual boring functional testing work.
Good testers don’t fear automation replacing them any more than a carpenter fears being replaced by a tool belt. Automation and electronic tools present opportunities for testers and teams. Opportunities to grow and advance to new levels of quality confidence that are otherwise unattainable with manual methods alone.
Should testers learn about electronic tools that can help them do their jobs more quickly and efficiently? Yes. Do all testers have to become programmers? No. Do tool vendors service all our needs? No. Will they ever? No.
I do expect tools to get better — more useful and powerful. I also expect we will have fewer testers in the future as most of the boring, repetitive types of testing work will be automated by default. We’re not there yet, so there is still a wide range of skills, interests and opinions about how these tools help and hinder us in delivering high quality software.
a1qa: Paul, you spent a lot of time researching & teaching Agile and Exploratory testing methods. According to you these two are connected somehow? Does the Exploratory testing skills help to be better Agile tester?
P.C.: Yes. Becoming a good agile tester means becoming more adaptable and collaborative with your team members. I sometimes describe this as a two-stage process.
First, it’s important to know how to think and to really understand your particular specialty. That is, as a tester, I expect you to understand how to:
- think of good questions;
- design tests to uncover interesting things;
- look at your results to understand potential gaps and weaknesses, and [very importantly];
- communicate what you learn to others.
I see Exploratory Testing (ET) as a way that covers all these things, allowing for flexibility within each of those elements. I know some people who have a more narrow interpretation of ET and see it as a random, haphazard testing activity.
The next stage in becoming a good Agile Tester is to take Testing to the next level. You need to stop thinking like an *independent* contributor, and start thinking like a team player. New tools and techniques emerge when this happens.
For example, when I coach teams and give workshops I often hear the phrase: “how can I test this?” That is the wrong question. The right question is something like: “how will we test this?” or “how can we ensure the customer is happy when we deliver this to them?”
Note the difference in words. It’s not about you anymore. Everyone on an agile team has a special skill, a piece of the puzzle. It’s only through good collaborative communication, and iterative work and improvement that you will reap the agile benefits and rewards.
As an Agile Tester, you need to stop focussing on yourself and your testing contribution. Instead, focus on helping others on the team to learn what you know so that they can do it too. Start looking for new opportunities and ways to test things together and you will find a new powerful Testing force that you can’t achieve on traditional waterfall-type projects.
As an Agile Tester, you need to be a great tester. Your team members expect you to bring Testing expertise to the group. Without ET, you may find yourself struggling to apply familiar/traditional/waterfall testing approaches in ways that don’t help very much. You will be the weakest link.
And knowing ET alone isn’t enough either. I have seen good testers who couldn’t wait to get back to their desks to “find all the bugs that the devs missed.” Sigh. This is not a whole-team mindset to Quality, and also doesn’t help very much in the long run.
If you want to be a successful Agile Tester, learn to be a great tester and a great collaborative team problem-solver. You need both for success.
a1qa: Paul, thanks for the sharing your point of view. We will be glad to see you as our guest again.
