How do work assignments take place for STE's? An example would be, I was testing this product which involved client/server stuff. I was assigned to test the funtionality of the server. In short, anything in the spec which was server related or came from the server dev. team, I was put in charge of by my test lead. How does it work at Microsoft? How is one assigned which part of the software/specs to test? Is there a particular method followed (such as maybe a new tester on the team will be assigned certain tasks which he might find easier to handle and slowly get into the product). I probably am not being able to explain this well with an example, but I hope you get the picture.
In the main, one person is responsible for each feature in a product, and each person is responsible for at least one feature new to the in-progress version of the product. When that release goes out the door all those new features instantly become legacy features, and so each person is now responsible for whatever feature(s) of that version plus one or more features new to the next version. Over time, each tester builds up quite a portfolio of features for which they are responsible. Automated tests are the only way to effectively deal with this situation. (Well, I guess you can always just ignore those legacy features on the assumption that they aren't changing and so they don't need to be tested anymore. But that's a sure path to shipping buggy software. And I know you don't want to do that. <g/>) Some features, especially new features, require more than one person to cover them. Introducing a new file format, for example, will almost certainly require a small team of testers to bang it into shape. (Once the new format is fully tested, however, just one or part of one tester is probably sufficient thereafter.)
(A "feature" pretty much lines up one-to-one with a specification, and specifications generally don't span multiple groups. So it's unusual for testers here at Microsoft to be in the situation Apoorva describes above of "You're responsible for anything in this spec that relates to A, Jane will test anything that relates to B, and Bob will take care of the rest.")
How a person gets assigned to a particular feature varies based on the person's interests and the needs of the team. The team's Test leadership tries to take each tester's desires into account when making assignments. A happy tester is an effective tester I always say, and a person who is excited by a feature is more likely to do a good job banging on it than someone who finds the feature extremely boring and spends as little time working with it as possible. On the other hand, there is a set of features that all need to be tested, and someone won't necessarily want to work on each one. Or the person who does might have a full plate of features already. We must also take into account each tester's experience and abilities, but this is less important than you might think. As I said in Grow, Darn You, Grow!, we believe very strongly in growing and challenging our people. A less experienced tester will certainly be watched over more than a more experienced tester will be, but even brand new testers have opportunities to own important features.
New testers are acclimated in a variety of ways, everything from throwing them in and letting them learn by force of necessity to sending them through formal tester training. The most successful method, in my opinion, is pairing the newbie with a more experienced tester on the team. This gives the new recruit a well-defined person to help them get going and show them the ropes. My team does this not just for brand-new-to-testing testers but also brand-new-to-our-team testers. Regardless of experienced a tester you are, it still takes some time to learn how your new team does things. We find this mentoring process smooths the inevitable bumps and helps people come up to speed more rapidly.
After testing a particular feature for some length of time its owner may lost interest in the feature. Or another feature may become more interesting for some reason. Or the feature may be dropped. As I said earlier, happy testers are effective testers, and so if you want to get rid of a particular feature management usually is happy to change things around to make that happen. Here's a hint, though: your request is much more likely to be granted if you make it at logical changepoints such as during planning for the next version!
*** Comments, questions, feedback? Want a fun job on a great team? Send two coding samples and an explanation of why you chose them, and of course your resume, to me at michhu at microsoft dot com. I need a tester and my team needs program managers. Great coding skills required for all positions.