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.
Comments
- Anonymous
January 28, 2005
The comment has been removed - Anonymous
January 31, 2005
There are several aspects to keeping people interested in test. I think the most important aspect is establishing Test as an equal partner in the software development process. Too often Test is viewed as the junior partner to Dev and PM. This results in sense of not being empowered to make changes and not being fulfilled professionally. If you can get your management team to agree that QA is important to the product both short and long term you can fundamentally change how QA does its job. The kind of change I am talking about is driving testability into the product, increasing the number of tests that are automated, and increasing the investment in testing infrastructure. Automation is probably the key factor to reducing the tester boredom and burnout. Because automation usually takes longer and is more expensive than developing manual cases you will need to get a resource commitment to make an investment in automation. Lastly testers have to have career path that allows them to grow in a similar manner to Dev and PM. If people see being a tester as a road to nowhere it is going to be very hard to retain them.