Five Questions With Bob Dewing
Bob Dewing has been managing testers for as long as I have known him, which means for at least the past ten years. He has been so focused on doing that well that I don't have much else to say about his testing career. So I will have to resort to telling anecdotes from when I worked for him. Well, maybe I shouldn't, because then he will likely turn bright red with embarrassment, like the time he was presenting at an all-hands meeting and his laptop went to screensaver...which his wife had customized to say "I love you Bob!"
There I go, telling stories after I said I wouldn't. I'll stop now and turn you over to Bob.
Here is what Bob has to say:
DDJ: What was your first introduction to testing? What did that leave you thinking about the act and/or concept of testing?
BD: I would love to have a story about a 'calling' to test, but at the time it was about preserving my mental state and helping the business. In the early 90's I worked in product support for a small privately held company that had no formalized testing process. In fact I witnessed the owner walking in to where the developers sat and yelling out 'who compiled last?', someone raised their hand and he hands them a disk and said 'great, copy it on here...we're shipping today'. Needless to say the product support role was a bit of a challenge and we ended up needing more and more time to research customer issues. The head of the department and I eventually convinced the owner that it would be cheaper (PSS was getting paid overtime to research bugs, near monthly product updates were needed, etc.) to create a formalized testing team. From there it was reading about manufacturing quality processes, talking to other companies about their processes, and coming up with an approach that 'made sense' to us. It felt like we were blazing a new trail and we were seeing immediate results and I was hooked.
DDJ: How would you describe your testing philosophy?
BD: I think the way I got into testing (through PSS) has stuck with me and defined my style or philosophy, and that is:
- Customer focused - regardless of where your feature is in the stack, you have some impact to the customer. It's super important to understand how your work is used and have some way to keep your finger on the pulse of your customer. This knowledge will not only help in the test case design stage, but also in the early feature design stage and can help you ask the 'how [or] does this solve the customer problem' question.
- Find the right tool/approach for the job - There's no single approach that will work for all problems. The typical personality profile of a tester is one that can look at a problem from different angles and ask 'what if' or 'what would happen if I...'. Learn about the different methodologies, even if your team doesn't use them currently. Look at how other testers with seemingly unrelated problems have solved them. You never know, with one small tweak that unrelated solution may all of a sudden become applicable.
- Continue to learn and improve the discipline - Related to above. I'm surprised at the number of experienced testers that don't continue their learning of the industry or discipline after they become comfortable with the basics of testing. Test can be an influential and dynamic discipline, continue to learn and evolve and bring your ideas to the table.
DDJ: What do you see as the biggest challenge for testers/the test discipline for the next five years?
BD: Test has arguably undergone the most change of the primary engineering disciplines (dev/test/pm). Over the last 5 or so years more focus has been placed on how Test contributes to a company's success and that has really pushed the discipline, which is fantastic. We've come from being a feel good action ('did some testing...check') in a product release to being equal partners in the process, affecting product design and influencing engineering practices. There is still plenty of change on the horizon, so apart from keep pace, I see the challenges as being:
- Attracting, growing, and retaining great people - There is no longer a question of 'do we need to test', Test is critical to any software engineering process and now the challenge isn't how to establish a test organization, it is defining what a career in Test looks like. We can't just throw more entry level work at senior testers and expect them to feel like they have a fulfilling career or to picture what a 10+ year career in Test might look like. Find opportunities and challenges that are commensurate with the person's skillset, create mentoring opportunities, and share a clear career road map with individuals. This will help companies attract great people by articulating the role and career path in Test, as well as give their existing testers the ability to manage and drive their own careers and stay committed to the discipline.
- Finding ways to scale/managing the process - As systems become increasingly complex and the test matrix never seems to reduce, traditional defect detection approaches don't scale to meet the need. Test will need to better meet the need by (along with keeping quality top of mind throughout the organization) becoming more predictive in their scheduling or forecasting, moving towards static analysis tools that catch common defects, and creating re-usable systems that don't become obsolete version to version.
- Not focusing on a single metric or test approach (ie. automation) - A large number of passing automated tests in your lab doesn't mean you've achieved your goal of a stable, robust, secure, global-aware product that meets the customer's needs. Automation is super and can free the tester to think creatively and go deeper into the product. But it is easy for an organization to be crushed under the weight of their own automation and have it become more of a maintenance burden and each tester ends up spending more time with the overhead and never get to the interesting cases that the automation was supposed to free them up to do. There is no one datapoint to use as a quality indicator, don't become so focused on one that you ignore the others or so focused on one testing pathway that you ignore others (for example, automation vs. scenario based test sessions).
DDJ: What has most surprised you as you have learned about testing/in your experiences with testing?
BD: You'll usually get one of a few different answers depending on which day you ask me....today it's....The stigma that the Test title still has - From the college campus trips to talking to experienced industry people, I'm surprised that a Test position is still seen as either poking keys at random and/or the place where developers that aren't good enough coders go.
DDJ: What is the most interesting bug you have seen?
BD: My favorite bug was back when I started, we got a call from a user whose cat walked across his keyboard and it locked up our application. Now who's going to test for that?!? But it's stuck with me and made me remember to think about the 'cat walking across the keyboard' scenario. Meaning, try to think about what could go wrong with your system and be leery of the 'oh, that could never happen' statement.
[See my Table Of Contents post for more details about this interview series.]