Five Questions With Sara Ford

Although Sara Ford is currently the Program Manager for the Visual Studio Power Toys, she started life at Microsoft as a tester. Back then she drove accessibility into Microsoft Visual Studio' s shell (i.e., all that UI you see as you use Visual Studio), most parts of which she owned testing for at one point or another. Nowadays she spends her time convincing teams across Microsoft to share code with y'all via shared and open source.

Sara spends her free time doing sports of all kinds, including riding her custom-built bicycle. Sara says her goal in life is to be a ninety-seven-year-old weightlifter, so that she is featured on the local news. Here is what Sara 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?
SF: My first real introduction to software testing was actually during my interview at Microsoft. During the Exchange interview in the morning, they asked me to test a simple weighted network (think traveling salesman style question). The interviewer explained to me that my answer was actually trying to implement the network, and not test it. She gave me a few examples of what she was looking for, and I thought, “whoa, I never thought that way before.” It was similar to only having a pencil, then getting a box of 8 colored crayons to work with. I started to get the feeling to this “software testing” thing throughout the rest of the loop, and by the time I got to Visual Studio that afternoon, I was honestly having fun answering the questions. Originally, SDET was the last thing I listed on my list of positions I wanted, but I left the interview loop jazzed about being a SDET. Equally important, the last interviewer said something that has stuck with me ever since about software testing. He said, “software testing is all about doing the optimal amount of testing in the minimum amount of work.” So this “fun” problem of “how many ways can you break something” became a challenge of “how many ways can you break something as fast as possible.”

DDJ: What has most surprised you as you have learned about testing/in your experiences with testing?
SF: I was most surprised the day I realized the paradox of, “so, um, how am I going to write tests for the tests that I’m writing?”

DDJ: What is the most interesting bug you have seen?
SF: I love this question =) One of the coolest bugs (yes, a die-hard tester will call the bugs they’ve found “cool”) I’ve ever found was in Visual Studio 2005 Tool Window Docking (sorry Chris, my former dev, for sharing this story). In a pre-beta release, if you re-docked a tool window to the same place over and over again, about maybe 100+ times, the window size would start to shrink (as if the user resized the window) until the size actually became negative, eating into the title bar. And no, I didn’t find this manually. I actually stumbled upon this while experimenting with model-based testing, when one of my models got away from me.

My other all-time favorite bug had to do with a screen reader. If Visual Studio had more than 500,000 characters opened in a file, and a screen reader was running, Visual Studio would crash. Took me 10 days working with a customer who was blind to figure out the root cause of his crash. But persistence prevailed in the end.

DDJ: How would you describe your testing philosophy?
SF: Every tester has their own techniques and styles. But, if I had an actual philosophy, I would have to say it is letting Murphy’s Law work for me. I seem to have really dumb luck at times with software. Maybe things don’t come as intuitively to me, or maybe I just see UI slightly differently from the rest of the population. But whatever it is, the bugs always seemed to find me, instead of the other way around. Software testing was such a great job, until Murphy’s Law found a way to one-up me. The bugs would find me only once, such that I could never get a repro (i.e. getting the reproduction steps for the developer to investigate the bug). Sigh, Murphy’s Law.

DDJ: Is there something which is typically emphasized as important regarding testing that you think can be ignored, is unimportant?
SF: From time to time, I hear testing philosophies of “100% automated testing – no manual tests.” I couldn’t disagree more. First, automated testing can never truly replicate the end-user experience. It’s critical for a tester to know their customers, to use the features as they would, and to share their pain. Automation can never catch end-user pain points, even at 100% code coverage. Secondly, manual testing is where a tester’s creativity comes into play. As I said above, the bugs find me, since I can never seem to use UI the way it was designed.

Posted by The Braidy Tester at 07:30 AM  Permalink