Dave Liebreich bills himself as a software testing architect, a consultant, a coach, and a manager. I bill him as someone who knows a whole lot about testing. Regardless of whether he is helping your team as an individual contributor, your Director Of Test, or anything in between, Dave can help your team become its Best Option version of yourself. Dave has served as Test Architect at Mozilla Corporation and as QA Manager at Yahoo!, so he knows his way around complex, distributed, networked systems. What's more, he has the know-how to translate his experiences into the product you are building, even if said product is neither complex nor distributed nor networked. Through it all, Dave helps you keep track of what you are doing, why you are doing it, and how you will know you are done.
Here is what Dave has to say:
Q: What was your first introduction to testing? What did that leave you thinking about the act and/or concept of testing?
A: First introduction: Back in the days before they called it "I.T.", I was a system administrator for a communications infrastructure equipment maker. I moved from the sysadmin group to the test group, and started writing automated test libraries. After a while, I was assigned some testing responsibilities.
Left me thinking: Mostly due to dumb luck, I realised I was testing as a sysadmin, not as a tester. I noticed that there were some testers who had a 'knack' for quickly finding problems in new builds and with new products. I wanted to be like that.
Q: What has most surprised you as you have learned about testing/in your experiences with testing?
A: Testing is part of any creative work - everyone asks technical questions of the technical stuff they do. The idea of having specific skills and studies in testing was a bit of a revelation.
Q: What is the most interesting bug you have seen?
A: As a user? I worked as a bank teller during college. One day, I noticed I had created $500.
As an observer of another tester? I saw someone find a memory leak caused by moving the pointer across the UI.
As a tester? I wrote a script to populate a network management system with dummy nodes. The script printed out the name of each node as it was created. I left the shell window open and noticed that the script slowed down as more and more nodes were created.
As a professional? The next one.
Q: How would you describe your testing philosophy?
A: Testing is:
- answering questions
- shortening feedback loops to answer questions faster
- moving feedback earlier in the process to answer questions sooner
- asking questions like "given what we just learned, what kinds of improvements to what we do can and should we consider?" so that we can ask and answer better questions
- starting with each tester's strengths in noticing stuff, use critical thinking techniques to notice more stuff, so we can discover questions we should have asked, but didn't
Q: What do you think is the most important thing for a tester to know? To do? For developers to know and do about testing?
A: Most important for a tester to know: applied critical thinking skills. Most important to do: apply them to both the problem domain and the solution domain.
For developers to know and do: ask testers to help find something developers would want to know, but do not currently know, about the system under test. Not just developers -- same for dev managers, project managers, customers, stakeholders, etc.