What does it mean to be a tester? (by Cameron Slade)

There is quite a bit of ambiguity, both within the software business and outside of it, about what it means to be a software tester. I can’t count how many times I have been at a party and told someone outside of Microsoft what I do only to get a bewildered look. On the other hand most people know or think they know what a developer does. Here are my observations from interviewing people to work at Microsoft and going to conferences.

 

In some shops, testers are people that know an application or specific application domain very well and their primary task is to define and execute scenarios that a piece of software should be able to complete. Most of the time the scenarios are executed manually and it is necessary to repeat the test passes many times during a product cycle. This cycle of running manual tests doesn’t scale very well and usually leads to high turn over rates within the test team. Bottom line, testers are expendable resources.  

 

On the other end of the scale there are companies where testers are engineers who are considered peers of Program Management and Development. In these organizations QA is highly involved in all phases of the product cycle. Testers create Test Plans, design and create automation infrastructure, write and execute automated tests. There are very good career paths for testers; in fact some of them go on to the VP level.

 

In case you haven’t guessed already I am talking about Microsoft Corporation in the latter example and the VPs I am talking about are S. Somasegar, Corporate Vice President, and Brian Valentine, Senior Vice President who both have backgrounds in test. In fact Microsoft is leading the charge to make QA a first class career. I work with some super talented people that take quality very seriously. We are innovating ways to design and test software that I believe most companies only dream of.

 

I would like to talk briefly about my experience as tester at Microsoft. I have been working in various product groups at Microsoft for over 10 years now. I started with Visual FoxPro 3.0 and believe it or not a vast majority of our test cases were automated way back then. Not only did we automate our test cases but we had an automation system that automatically ran the cases and reported results. We still had to do some of the boring and time consuming things like build the machines and analyze results. Today the SDETs at Microsoft have developed automation infrastructure that builds the machine, installs all necessary software, runs the test cases, gathers results and automatically analyzes failures. An even more impressive aspect of this is that our modern automation infrastructure can do this across many machines so that mini enterprises can be setup and have tests run on them without human intervention.       

 

If you are interested in what others are thinking about QA at Microsoft here are a couple links to other blog entries https://blogs.msdn.com/scottgu/archive/2004/10/28/249458.aspx and https://blogs.msdn.com/steverowe/archive/2005/01/19/356361.aspx.

 

PS: If you think you are super strong engineer who has passion for quality and databases our team is always looking for new talent. Our open position is listed here. If you would like to drop me an email, you can reach me at: camsl@microsoft.com.