Five Questions With Lyne Brown

Lyne Brown is currently a Development Lead for Microsoft's Macintosh Business Unit tools+automation+build team, which means she spends a lot of time working with testers to build tools that will make their jobs easier, faster, and even more fun. For thirteen years she has been doing this, through many a title, management, and organization change. Before that she helped engineers at the GM Proving Grounds do their job, and before that she was a CS student after deciding that ornithology wasn't really what she wanted to do with her life.

Here is what Lyne 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?
LB: My first introduction to testing was when I did a phone interview with Paul Williams. I sent in an unsolicited resume to Microsoft in ’94 and Paul called me with an SDE/T position that was available in the new Office core team. I didn’t realize at the time that testing was a possible career path. At first I was deterred but the more we chatted the more it piqued my interest and the more I realized that I might actually have an aptitude for testing. I had always had an interest in how things worked and how I could break them :).

DDJ: What has most surprised you as you have learned about testing/in your experiences with testing?
LB: I was initially surprised at just how rich of a career path that testing can offer. Testing has changed substantially over the past 13 years that I have been at Microsoft. There is always something new in the wind. Whether it is richer automation, model-based testing, PICT, white box testing, a well-defined automation stack that leads to such concepts as decoupled automation, etc. – there is always something new to learn that can be another tool in the tester’s arsenal.

DDJ: What do you think is the most important thing for a tester to know? To do? For developers to know and do about testing?
LB: Testers: 1) don’t become an automaton – keep that child-like curiosity and desire to “break” things as you discover their inner workings. 2) Look at the code you are testing whenever possible. If you can look at the code from the eyes of a tester you can better deduce how to test it as well as feed those observations back to the dev. Developers: 1) work closely with your tester. Understand that there is no hierarchy in the engineering disciplines. You are all working together for one common cause – delighting our customers. 2) Give the testers what they need to help them better test the product. If a certain feature does not have an exposed API, then make sure you expose it thru accessibility.

DDJ: What do you see as the biggest challenge for testers/the test discipline for the next five years?
LB: I think the biggest challenge will be in balancing the growth in technical areas (automation, white box testing, etc.) with good old-fashioned testing skills. I see all these sharp, new, technically sound testers being hired but they don’t seem to have the rudimentary skills (ad hoc-ability, curiosity, thinking outside the box) needed to really be a great tester. I believe there needs to be more education done in teaching testers the skill set they need to be great ad-hoc testers and there also needs to be more time dedicated in the product life cycle for ad-hoc testing. Where did all the bug bashes of yore go?

DDJ: Is there anything else you would like to say?
LB: I would just like to state for the record that the comments above are my observations from outside the role of a tester. I only owned a feature (Office toolbars) for one month before it was decided that our team would work on white-box testing tools and the automation system and so I handed my feature to someone else. All my 13 years at Microsoft have been in the role of an individual contributor or lead for a team that is dedicated to tools development, primarily for the test organization. I have been in the same role the entire time but have been titled as SDE/T, SDET and SDE and have been in both the test and now the dev organization. I am giving this background information because my hope is that someday the distinction between people in the engineering disciplines is not in their title but instead in their role. This may become more of a reality as more teams move to agile-type methodologies such as SCRUM and Feature Crews. I see that the unspoken caste system that has been around at Microsoft in the engineering world for as long as I can remember is slowly disintegrating but it still exists at least in the minds of some of the old-timers.

[See my Table Of Contents post for more details about this interview series.]

Posted by The Braidy Tester at 07:30 AM  Permalink