George Dinwiddie is an Agile consultant and speaker. In part one of this two-part interview, we learned about some of the differences between traditional testing and Agile testing. In part two we explore questions about automation, certifications, changes in Agile in the past 10 years and ways testers can grow their skills.
SSQ: Do you think it’s important for Agile testers to have programming and automation skills?
Dinwiddie: It's important that the team have programming and test automation skills. It's not essential that the testers have those skills. In order for a team to act in an Agile fashion, they have to get beyond the concept of “this is my responsibility and that is not.” Instead, they need to think “we need to get all of this done.”
Of course, the more skill an Agile tester has at programming and automation, the bigger advantage they have. But any tester who can write a test script in a Word document should also be able to write one in an Agile-friendly test automation tool. I've often seen a tester and a programmer work together to connect such a test script to the system being tested.
But don't forget exploratory testing skills. It's very important for someone to be able to uncover the situations that no one thought about. When a problem is found there, it's likely to be a whole nest of bugs.
SSQ: What types of automation skills would you recommend testers to get? Should they become skilled in particular tool sets? Scripting languages? Should they pair up with developers and learn how to do test-driven development?
Dinwiddie: The most important automation skill for a tester is thinking about the desired functionality in business terms, instead of in terms of the software implementation. Writing test scripts in these terms instead of text fields and button clicks will result in more powerful, less fragile tests.
Should they want to investigate particular tools, I'd recommend Cucumber, Robot Framework, and FitNesse as good starting points. All three of these tools allow you to express your functional expectations in a language you extend to fit the application you're developing.
I wouldn't worry too much about general-purpose scripting languages or developer-style test-driven development. If these become important to your work at some point, you can learn them then.
SSQ: The topic of certifications can be somewhat controversial. What is your feeling about certifications? Which, if any, do you think are the most important to obtain?
Dinwiddie: The purpose of a certification is to be a token representing that someone has learned something. Some certificates may set a higher standard than others, but none of them (even college diplomas) can certify that the person can do the job that you want done. Hiring managers or personnel clerks who don't know other ways to judge competence too often treat them as a certification of the person's ability.
Having been on both sides of the job interview desk, I don't put a lot of faith in certificates. I've gotten a couple to provide credentials for work I was already demonstrating I could do, though I don't think anyone really cared. When I've done so, I've chosen ones (or particular classes) that I thought would maximize my learning. When I've interviewed someone who touted a certificate, I've asked them what they learned in gaining it.
Certificate or not, it's the learning that's important.
SSQ: What changes have you seen in the last 10 years in the way Agile testing is being done?
Dinwiddie: Those 10 years cover the entire time that the word Agile has been applied to software development. Compared to some ways of working prior to that, it's completely different. Compared to others, it's very similar. It's difficult to make meaningful generalizations.
The last few years have been an exciting time for test automation, though. The choice of good tools has absolutely exploded, and most of them are free and open-source. These tools have allowed expressing test expectations in business terms, before development, in ways that previous expensive tools from large vendors have not. And, while the industry has made great strides, I don't think we've reached the limit. I look to see bright people come up with even more ways to express expectations that can be easily understood by business stakeholders, testers, and programmers.
SSQ: What do you think are some of the best ways Agile testers can grow their skills and stay current in the latest tools and technologies?
Dinwiddie: First, stay in the loop. Talk with others in the testing community, both in person and virtually. There are great opportunities to do so at big conferences and at small regional ones. There are online communities, such as the agile-testing yahoogroup. There are blogs where you can respond in the comments. There are excellent testers you can engage on twitter.
And practice. Try things out. Play with new tools. Join in groups, locally or online, to test some system together and learn from each other.
You can never afford to stop learning.
Read part one of this interview: “How are Agile testing and traditional testing different? Interview with George Dinwiddie – Part 1.”
George Dinwiddie is an Agile consultant specializing in team- and skill-building with broad technical experience ranging from embedded firmware to business information technology.