100+ Tips for Improving Your Testing Skills

Alan Myrvold (and tips from many others)

Abstract

Software testing at Microsoft can be a challenging and rewarding career.  Like any career, being self-critical and working to improve your skills can help you grow and succeed.

This paper presents more than 100 tips from 40 successful Office testers, test leads, and managers.  These tips are designed to help you improve your testing skills.

The tips are organized into themes.  The tips appear mostly as submitted, with minor edits.

Acknowledgements

Special thanks to the following testers who offered tips for this paper:

Aaron Birnbaum, Alan Brown, Allen Spruill, Andy Tischaefer, Arun Chitrapu, Atin Bansal, Bill Barry, Cathy McBride, Chris Barber, David Brodsky, David Hansen, Dipak Boyed, Eric Broberg, Gary Shaboo, Grace Sturman, Hameed Afssari, Jack Wen, James Reynolds, Jamie Campbell, Jim Pierson, John Beswetherick, Krishna Kadathur Srinivasan, Kristen Tardito, Mark Wirling, Marty Riley, Mike Blaylock, Mike Hollinshead, Noel Nyman, Ray Tran, Renee Cooper, Ryan Hurey, Ryan Jepperson, Sathia Thirumal, Shauna McDaniel, Suneetha Dhulipalla, Sylvia Hayashi, Tom Gallagher, Tracey Gauthier, Trang Luu, and Trond Hansen.

Using these tips

Read these tips, and find out which ones you are passionate about, disagree with, or are in areas that you need the most improvement.

 

Derive goals based on some of these themes/tips.  Include those goals in your commitments.

Themes

The collected tips have been organized into themes.  There is duplication of ideas within the tips, but that duplication shows that several people thought the idea was important.

1.       Enjoy what you do, and do it well

2.       Read bugs

3.       Read code

4.       Take pride in your bugs

5.       Get involved in your feature’s design

6.       Design your tests

7.       Know your feature

8.       Work with others to test your feature

9.       Learn your product

10.   Foster good relationships with your developers

11.   Expand your scope and network

12.   Find mentors/role models

13.   Be self-critical

14.   Manage your time

15.   Focus on the customer

16.   Automate wisely

17.   Improve your coding skills

18.   Attend triage

19.   Keep learning

Theme #1: Enjoy what you do, and do it well

1.        Focus on the basics: know your features, constantly find bugs, write quality automation, and develop good working relationships with the people around you.  Those core skills will carry you further than any cool shiny thing you chase down or driver role you pursue.  Foundation matters. [atisch]

2.        When you’re assigned anything (big or small), own it completely and unequivocally.  Plan it, document it, test it, report on it, wrap it up, and hand it off in better shape than you got it. [bilbar]

3.        Be an expert. Pick an area that you are passionate about and become very good at it. [trangluu]

4.        Find something you love or you think needs doing and start working on it.  I’ve seen lots of successful testers ‘create’ their own job by doing something important and well that adds value to the org. [davidhan]

5.        Take the front seat rather than the back seat.  Even better, be the driver. [ryanje]

6.        Take off the blinders. If you see a problem with the product or processes, then own the problem and get it solved. [rhurey]

7.        You are not only responsible to test your feature, you also need to help it ship. Pick up the pieces where needed and help out your Dev/PM counterparts. [atinb]

8.        Always look for efficient ways to solve the problem.  Don’t assume that the current solution is doing the work.  Look for new ways that would make the product better. [suneetha]

9.        Be part of the solution.  While it is good to be critical of process and issues and be a voice for change, the better tester not only raises issues but suggests (or takes part in finding) solutions.  [raytran]

Theme #2: Read bugs

10.     Spend 5-10 minutes each day to read the bugs logged by other team members. [liwen]

11.     Live the bug list.  Post lots of your own bugs, read every bug posted near your area, read every bug posted by other testers on the team. [atisch]

12.     Spend a few minutes each day reading through the incoming bugs for your product.  You can learn a lot from seeing how other testers find their bugs and what a good bug looks like.  This is also a great way to learn about features you’re not familiar with and to get ideas about integration areas you may need to explore more. [jamieca]

13.     Read the bug list daily. As an IC on a product team, each day I started by reading all of the bug titles for my product and reading the bugtraq mailing list.  The bugs against the product helped me understand what bugs were being found and the steps to uncover the bug (repro steps).  If I didn’t understand the bug, I followed up with the tester.  With this information, I understood that parts of the product was riskier and also could apply test cases I hadn’t thought about to my areas.  I learned a lot from others by reading their bugs. [tomgal]

14.     Study your own dup bugs by looking at the primary bug you got dup’d against and the other dups of the same primary bug.  It will help you to know the right way of searching for dups to prevent more dups in the future.  More importantly, it could help you understand what the underlining issue is. [gracez]

15.     When testing your feature for a specialty area that you don’t have a lot of depth knowledge in yet (Intl, Security, Perf, etc), scan the bug list for your team to see what kinds of bugs other testers are logging in their areas.  Particularly those testers who do have depth knowledge in that area or who have features similar to your own. [reneemi]

16.     Look at the last n bugs found and/or fixed for your feature area (not necessarily found by you) and understand if there are any changes to your test approach that would have allowed you to find them sooner.  Identify feature knowledge gaps or test approach gaps so that you don’t do the same thing again. [mriley]

17.     Read ALL incoming bugs, especially bugs others find in your areas! [sathiat]

18.     Read the bug list to understand the product changes in the current build and recent builds, and use that information to focus your testing. [aspruill]

Theme #3: Read code

19.     For a fix, review the dpk, and proceed with testing against possible affected areas/features. [liwen]

20.     Make it a practice when reporting a bug to determine what code is causing the issue.  Work with your developer to understand the fix and do both black box and unit testing on the fix.  Don’t just use empirical user testing for verify the fix. [johnbes]

21.     Know the code that belongs to your feature(s).  If your dev is willing, have him/her walk you through it. [reneemi]

22.     Look at the code, even if you can’t read the language that it’s in. Structures, comments, etc can lead you to cases you haven’t thought of. [cathym]

23.     When testing fixes with vague repro steps and/or nebulous Dev recommendations (“play around with X”), get code coverage builds and ensure you’re hitting all the new code.  Or, at a minimum, attach a debugger and set a breakpoint.  You need to know whether you’re wasting your time or actually hitting the code. [bilbar]

24.   Read your dev’s code – this always helps strike interesting conversations with your dev. Devs like testers who understand their code, and critique and ask intelligent questions. Read all checkins; make it a habit to look at DPKs. [sathiat]

Theme #4: Take pride in your bugs

25.     Take pride in the quality of each and every bug you log. BUG TITLE should be brief, listing the symptom first (crash, hang, slow, typo, etc), then optionally the impact (which customers will be impacted and how severely). REPRO STEPS should be numbered and written with no assumptions of feature knowledge, and have both an ACTUAL and EXPECTED outcome, then a NOTE about the impact of the ACTUAL outcome. [ryanje]

26.     Trust your instincts; if it feels like a bug, it’s a bug. [jamesre]

27.     Develop and trust your instincts. You won’t always be right, but neither will others and you need to be their second pair of eyes at times. [ericbro]

28.     Put everything in Product Studio that you think is a bug and don’t worry about By Design (or your find/fix ratio).  The conversation is often worth it even if the bug gets punted. [davidhan]

29.     If you know you’re not a gud speeler, spell check your bug titles; spelling errors here will make it less likely people can find this bug when searching. It also looks careless and unprofessional. [bilbar]

30.     The importance of filing a good bug.  This is a trivial task yet vital to the daily role of a tester. A good bug report can directly impact the time it takes for a Dev to resolve the issue, promote better communication between Devs and Testers, build good working relationships between Dev and Tester and reduce the room for miscommunication. Encourage use of bug templates that forces inclusion of Repro Steps, Actual and Expected results, use bugger etc… [diboyed]

31.     Deliver meaningful and actionable bugs – point the Dev directly to the problem with call stacks, etc. Don’t just say x is greater than goal y. That irritates many Devs because your just giving them work, not real value. [jimpier]

32.     When writing/investigating bugs, think of it as if you were the dev.  What data would you need to solve the problem?  Talk with your devs about your bug reports and what additional data could have been useful and what was not helpful. [mwirling]

33.     Brainstorm the worst case for scenarios and bugs. Many bugs are seen first as a much more innocent issue than they really are. [ericbro]

34.     Trust your observations; don’t let someone [or yourself] convince you that the event (failure/bug) you observed didn’t happen.  The fun comes from making your observation into an actionable bug supported by data you provide. [jamesre]

35.     Be willing to question decisions on “Won’t Fix” or “As designed” bugs which you feel are wrong.   Stay open minded in the discussion, you may not have the full picture, but you may also cause others to rethink the issue. [mwirling]

36.     When you’re dealing with a Postponed or Won’t Fix bug that you feel should be fixed, be sure to use all of the resources available to you to make a case for fixing the bug.  A couple of examples: Look at SQM and other instrumentation data.  Talk with your PSS contact or others that work with customers. [aspruill]

Theme #5: Get involved in your feature’s design

37.     Early in the product cycle, be very involved as specs are being developed.  Read through the draft specs and think of situations not addressed in the spec.  Go to the spec review meetings and ask questions.  Your goal is to elicit comments from dev along the lines of “ooh, yeh, that would probably break the feature.”  It’s much better for PM to design and dev to code for tricky test cases from the beginning! [shaunam]

38.     Try to involve yourself in the design process as early as possible. The spec review shouldn’t be the first time you’re hearing the plan. [aaronbir]

39.     Start your testing right from Planning and design, get involved in not only questioning the scenarios/specs, but also actively involving in providing suggestion for improvement. Bring up past design bug example in order to prevent future design issues. Don’t focus as critiquing the current design as “the only way” and expand to bringing up possible other design alternatives.  [hameea]

40.     Push quality upstream by using state modeling (SpecExplorer) to test the PM spec and Dev design doc.  Finding flaws in these areas before they exist in code is efficiency at its best. [traceys]

41.   During the design phase make at least one diagnostic request as part of the feature implementation to allow you to automate or test portions of the feature that would otherwise be expensive to do (this is very critical for hosted services especially).  The more difficult a portion of a feature is to test, the less coverage it will get, short circuit that. [mriley]

Theme #6: Design your tests

42.     Always test both valid and invalid. [cathym]

43.     Take a look at the “Am I Done Yet” list to get an idea of all the different levels of testing that are possible. [johnbes]

44.     Find the worst possible outcome in the most common user scenario, and log that as a bug.  [bilbar]

45.     Use PICT to find the optimal set of test cases to get prioritized coverage across your key variables. [traceys]

46.     Figure out the international dependencies for your feature set and come up with a set of equivalency classes to test your features for worldwide readiness.  Work with your management team to understand which groups are doing the localization testing and extended international functionality testing.  Determine what specific international tests you specifically need to do and create some test cases.  Have them reviewed by your team and the Office Global Experience Platform group. [johnbes]

47.     Think about how to break a feature, product, or scenario as opposed to functionally testing it to death, preferably a feature outside your usual purview. If the product lets you do it, then do it BIG and BAD! It's easy to get caught in a testing rut, getting mired in fairly simple and repeated functional and/or regression testing.  Think about increasing the inputs to your feature by maybe 2-5-10 times by adding more machines/endpoints, more simulated users, larger documents, more files, more complex data, etc. [gshaboo]

48.     Meet with your feature crew and ask them what their top 10 tests would be if they could only run 10 non-equivalency classed test cases.  Share your top 10 tests and discuss discrepancies.  Close gaps in feature/code design as well as feature area prioritization. [mriley]

49.   Most features have reached a level of complexity that makes it hard if not impossible to fully test as a black box. Write your TDS based on the spec and exploratory testing THEN look at the code to fill in the gaps, especially by using code coverage. [davbrod]

Theme #7: Know your feature

50.     Know your feature.  By the end of the release, no one on the team should know more about how your features work (technically as well as in terms of quality) than you – not even the developer that wrote the code. [atisch]

51.     Own your feature areas.  People should not be logging bugs in your areas.  If they do, understand why you didn’t already find these bugs.  Work with the tester who logged the bug to understand their approach.  Apply the approach all of your areas.  Do not be upset with testers logging bugs in your area; ultimately they are helping you and improving the product. [tomgal]

52.     Strive to understand your feature. The more you know about your feature’s working and code, the better you will be. [atinb]

53.   Aim to become the Goto person for your area. [sathiat]

54.     Use the available data streams early, iis logs, uls logs, perfmon and keep your feature clean from the start. [mriley]

55.     Do what you need to understand how your feature works.  The more you understand about how it is implemented, the better you can exploit that to find weaknesses in the feature. [davidhan]

56.     Use code coverage to figure out what code your testing ISN’T hitting. Code coverage isn’t about hitting the goal (although you should work hard to do so) but is about understanding what isn’t being exercised so you can test more thoroughly. Just remember code coverage only tells you how you are doing covering the code that exists. It doesn’t tell you what code is missing (should have been written but wasn’t). Make sure you think through the scenarios carefully looking for cases the developer didn’t support in code. [davbrod]

Theme #8: Work with others to test your feature

57.     Leverage your cross team contacts. Each team has a set of cross team contacts who are experts in particular focus areas. Make sure you are aware of who owns what and pick their brains when performing area specific test passes. Become a contact in a different area each release so you also build upon your test experience tool kit. [mikeholl]

58.     Remember your best testing skill is working well with your “Scenario Crew” to deliver a quality customer scenario.   In your first Feature Crew meeting discuss expectations and how the feature crew can best work as a team. In your second Feature Crew meeting define the expectations in detail and keep running notes as these expectations change throughout the product cycle: Define usage of process/tools  (Spec, TDS, Dev Spec, PR Testing, Product Studio Usage, …)  Will PM/Test/Dev keep the Specification up to date in real time as the design changes?  At milestones?  Will Testing log bugs in Product Studio during PR testing?   In your third Feature Crew meeting walk through your notes and have each person give their definition.  Testing a PR could mean very different things…  PR for a developer could be a x64 dev install mondo debug build with test Cc…ed on their BigButton run before check-in, PR for a tester could be x86/X64 equivalence classed across languages with detailed PR notes and a strict check-in policy. [alanbrow]

59.  Think about cross office integration.  How does the feature you are testing affect other features owned by other Office teams?  Find out who the tester on the integrating team is and sit down with that person to exchange ideas for test cases.  It’s pretty amazing what two people working through a problem can come up with sometimes! [shaunam]

60.     Cross Group Collaboration: This is extra important specially for testers in OSS or any other shared team (WSS) as our interdependencies grow more complicated. A solid tester will look above and beyond his/her feature/feature crew to find,bring awareness, and resolve inter-dependencies between their features and features in other team. [hameea]

61.     Remember your “area” probably has many integration points and you should work across your integration points so the “gray area” is covered by both you and your integration testing counterpart. [alanbrow]

62.     Work closely with Subject Matter Experts (SMEs) from all disciplines to learn the areas and try to become a SME in the areas you own.  Go deep in your feature areas and become technical. [suneetha]

63.     You are a member of a team – you each bring your unique perspective to what you are building – you each have ideas to contribute to its design, implementation, and testing.  Work closely with your program manager and your developer.  Even better, bring in someone from design too! [sylviah]

64.   You and your team succeed and fail as one. [sylviah]

Theme #9: Learn your product

65.     Know beyond your feature and area – usually feature crews tend to own a small feature – but know how it fits overall with the other features in the product/products. If they overlap multiple products, see how the features can be made holistic. Think about test cases that span multiple products – from a customer workflow perspective. Your feature is only as good as the overall customer workflow. [radsri]

66.     Understand the product at a deep level. This is so important in my opinion.  Software isn’t a black box and it should not be tested like one.  Even if black box testing is performed, we as testers should think about how things actually work inside.  Reading the code is great, but even if the tester can’t go to that level they should understand the components that are used and how things interact.  With this deeper understanding a deeper level of bugs can be found.  It is more time consuming to figure this stuff out, but it is an investment that almost always pays large dividends. [tomgal]

67.     Know any industry standards that relate to your area (Outlook folks should know RFC 5321 and RFC 5322 inside and out).  Even if your app doesn’t support that standard, you should get familiar. [davidhan]

68.     Get lots of hands-on experience with the product that you are going to test, including advanced ways to use it. [trondh]

69.     Talk to fellow testers in your team that are testing other areas/features. At times you might find that you can both learn from them or suggest ways to them to do things better. Overall this is also a good way to learn about the overall testing in your team. [arunc]

70.     Don’t being afraid to play with and test areas you don’t own.  This way you learn more about the overall product, help find some additional bugs, and find interaction/integration issues more quickly. [tomgal]

71.     Take an interest beyond your own areas.  You’ll be surprised how much you learn and how much your experience can help others. [cbarber]

72.     Join a team with 1 or 2 others to get experience with a large scale installation when the product supports it. [trondh]

73.     Monitor performance metrics regularly to see if the performance is stable, on the way up, or on the way down. [trondh]

74.     Become expert at reproducing hard-to-repro problems within debuggable test environments.  Don't be satisfied with just auto-submitting a bug for some sporadic Oasys scenario failure. Accept the challenge of determining how to repro these types of problems within the debugger, exceptions enabled, etc., for easier Dev resolution. [gshaboo]

75.     Focus on your areas, but dogfood the more broad Office functionality as part of getting your work done (e.g. build reports using a combination of tools Office provides.)  You’d be amazing how many additional bugs you can find by just getting your own work done. [jamesre]

76.   Data driven results. Be knowledgeable with the feedback channels available to your product and features which can clarify assumptions on usage and issue severity. [mikeholl]

Theme #10: Foster good relationships with your developers

77.     Ask your developer to give you a high level work through how the feature works.  You will understand the code pass, and come up with test cases you might otherwise not have thought about. [gracez]

78.     Your devs are your customers too. Serve them right, and they will pay you back with the best bug fixes. [trangluu]

79.     Show your developers how you do your job and what tools you use. Make them better at testing tasks and open their eyes to things they can do to help you. [aaronbir]

80.   Make your developers your best friends at work and build a good relationship with your dev.  Part of the tester’s job is to find mistakes and draw attention to them.  It is important that developers and testers don’t take this personally.  I used to eat lunch almost every day with my devs.  During lunch they would tell me about how they were designing the feature, areas that were risky, and areas they thought needed deeper testing.  Through this relationship, I was able to ask good questions about how I could test certain areas and how things really worked.  I don’t think I would have found as many bugs if I didn’t have these informal discussion and the devs’ trust that I was willing to work hard to understand and test their feature.  But don’t totally trust your dev.  I remember many times when a dev would make a comment that something wasn’t possible because he read/wrote the code and was the expert.  Testers should test things out, but sometimes people trust what they are told instead of try things out. [tomgal]

Theme #11: Expand your scope and network

81.     Establish your network. Strong testers have a support group behind them where they can brainstorm, find other key knowledgeable contacts, and gather feedback on created content.  [mikeholl]

82.     Identify Partners across the org that have objectives in common with you and then meet with them often to share notes. [jimpier]

83.     Investigate how other teams are solving your test problems and work with them to share knowledge and technology. [ryanje]

84.     Network with other testers across Microsoft. Don’t be confined to your building, your floor, or your team. Whenever there is a new testing problem, it’s almost certain some other team in Microsoft has already solved this. Don’t reinvent the wheel. Take what others have and make it better. [radsri]

85.     Get to know people.  You are much more productive when you can find the right folks and they can find you. [cbarber]

86.     Build your testing network.  Get to know testers on other teams and talk with them about testing challenges they face and the approaches they use. [aspruill]

87.   Present your work outside of your immediate peers and manager. Your manager isn’t the only one you need to impress in order to get promoted. You really need to be known and respected by your manager’s peers so he can sell the promotion at the calibration meeting. [jimpier]

Theme #12: Find mentors/role models

88.     Watch testers whom you respect test their feature/PR test and have them watch you do some testing.  Everyone has a unique bag of tricks, steal liberally from the best testers. [mriley]

89.     Identify Mentors.  Find the folks that you think do it right then learn how they do it. [cbarber]

90.   Identify your role models.  Find testers that have been here longer than you, that do things better than you, and ask them questions. [atisch]

Theme #13: Be self-critical

91.     Listen to your detractors – there’s some truth in most of what people say about you that you don’t like, but listen to it and improve. [jimpier]

92.   When getting constructive feedback, don’t immediately defend or deflect.  Great testers admit and learn from their mistakes, saying, “I could have done that better—next time I’ll apply what I’ve learned here.”  Create processes, automation, or documentation to help you and others avoid that mistake in the future—that shows you really learned and applied. [bilbar]

Theme #14: Manage your time

93.     Plan/prioritize your daily work items, and schedule some time to log bugs for every day. [liwen]

94.     Stay present – don’t do email in meetings. Say “NO thank you” to attending meetings where you do not participate continuously. Read the recap instead. [jimpier]

95.     Remember your job is to get bugs fixed – apply this especially when prioritizing test cases and writing bugs. [cathym]

96.     Don’t get stuck in a corner. That is to say, don’t drill down on a small piece of functionality for overly long. It doesn’t matter if some little piece of your feature has multiple bugs, if your overall feature doesn’t pass a simple user scenario. [cathym]

97.     Keep notes – sounds silly but many people do not keep notes on agreements made and then don’t follow up on the details. [jimpier]

98.   Be generous with your time when helping others.  Especially related to areas that you have interest and expertise.  It will increase your own depth as well as your scope of influence.  You will become regarded as a resource by others. [mwirling]

Theme #15: Focus on the customer

99.     Keep the customer in mind!  Put yourself in the shoes of the customer who will ultimately use the features you are testing - think about the overall tasks they are trying to accomplish, and do at least some of your testing from that point of view. [shaunam]

100.  Always keep the customer in mind, from design of the feature to triaging bugs. [atinb]

101.  The customer likely doesn’t have a BS in CS. [rhurey]

102.  Know your customer and key scenarios.  Target your testing to the highest priority areas of your feature(s) that will enable core scenarios to work seamlessly. [traceys]

103.  Do the right thing for the product, not for the metrics. [reneemi]

104.  Be tenacious yet respectful. Invoke the customer scenario when in doubt. [aaronbir]

105.  Attend usability studies at least once.  It will be an eye opener to see some things are so obvious to you, might not quite be the case with our customers.  This will again teach you to think like our customer, and use/test our product differently. [gracez]

106.  Use real world test collaterals for testing, and use the product like real customers would.  We need to do the basic and extended feature level testing, but we should never lose sight of we are shipping a whole product, not just features; and scenarios are the selling points.  We must make the end-to-end scenarios work very well to delight our customers. [gracez]

107.  Active engagement in Customer forum /Blogs. This will help you come up with new test cases and scenarios. [hameea]

108.  Gather real customer collateral when you can and use it in your testing. Our customers are incredibly creative in their use of our features and often exercise them in ways we never would have predicted. [davbrod]

109.                        Know your customer.  Find out as much as you can about your customer and what they want.  Ground that understanding in field data and research.  Don’t assume that everyone is your customer.  Don’t assume that you are the customer.  Work with your team (see above) to ensure you each have the same clear understanding of your customer.  Knowing your customer will help you make quality decisions each day. [sylviah]

Theme #16: Automate wisely

110.  Automate mundane and repetitive tasks so that you can spend more time discovering new things and doing the things you enjoy. [ryanje]

111.  Keep your eye out for the lazy way. Spending several hours on a tool that saves you (and/or others) dozens of hours later, is well worth the investment. [ericbro]

112.  Automate, automate, and automate, in any way. Don't let a test machine sit idle at night! It's easy to get trapped within existing automation systems, spending months to get a few tests running, and wasting time bookkeeping instead of testing. Hone your skills at testing and finding bugs, not maintaining failure tags or reports. [gshaboo]

113.  Buddy code review your peer testers’ automation.  Seeing how others create solutions for their testing needs can teach you a variety of different problem solving techniques, and sharing code review feedback spreads goodness across your team. [traceys]

114.  Don’t spend 80% of your time writing automation for the happy cases – automation for the sake of automation is wasteful, high maintenance and hurts the product.  Vista had a lot of automation for sure. We know how the product ended up being not as good as it can be. Think of the core purpose of each automation test and suite and how it will help your product/feature stabilize. [radsri]

115.  There is no magic in automation. A good tester always wants to get to the bottom of things. It things are like magic to you, you don’t understand it yet. Filing a bug for an intermittent or non-deterministic failure is just the first step. If the tester can find relevant code, debug it and narrow scope to make the repro steps actionable, the chances of fixing such intermittent issues becomes higher. [diboyed]

116.                        Testing is about accurately reporting the state of the product, not about the pass rate. [rhurey]

Theme #17: Improve your coding skills

117.  Write tools that help you and others test more efficiently.  If you can’t because you lack coding skill, then gain coding skills by taking a class that will teach you the basics of whatever coding language you need to learn, and applying that knowledge to write tools. [mikebl]

118.                        Learn how to code.  Devs know how to test their code, so we should know how to write solid code for automation and/or test tools. [trangluu]

Theme #18: Attend triage

119.  Attend a triage session.  Triage is a great place to learn how management thinks about bugs and how issues are prioritized as the product locks down. [jamieca]

120.                        If you’re not already attending triage and would like to do so, talk to your lead about sitting in one of the meetings once in a while if permitted. Some teams optionally invite others to be at triage. You can learn a lot from triage meetings. It gives you a great idea for the thought process behind the accepting and rejecting of bugs. You can also learn at such meetings how to better open your bugs, assuming you’re not already doing so. Basically look at the bugs that triage seems to spend the most time wondering about what the bug is about (i.e. triage can’t immediately decide what to do with the bug), and then see if your bugs fall into that category, and pay attention to the missing parts that triage wants to see there. If you know ahead of time that a few of your bugs will be looked at in a particular triage meeting, that meeting especially is one to consider attending. [arunc]

Theme #19: Keep learning

121.  Take advantage of training and presentations that are available online through http://mylearning [ktardito]

122.  Watch presentations hosted by Microsoft Research, especially those not targeted directly to testers, for new ways of looking at how people “test” things other than software, and new understandings of how customers and developers deal with everyday issues. [noeln]

123.  Read a book on testing or software quality.  Any book.  It is good to gain a perspective on how other people view testing. [amyrvold]

124.  Attend local software testing seminars/conferences to learn about current tools and trends. [ktardito]

125.  Look for and read blogs (add other site types or generalize this term to include them) that talk about how your product or feature work and the problems customers have using it. [noeln]

126.  Keep track of latest test methodologies and test tools being used across the company. Joining DLs that you find interesting (like a DL for Model Based Testing, Fuzz Testing, etc.) is one way to do it. You can also do something as simple as going to http://toolbox and searching for tools for the areas that interest you most. Before you decide to just blindly suggest to your team that they should adopt a particular tool or methodology, make sure you do enough research. A few points to get you started: Why will adopting that tool make testing better in your team? Did you do a trial run to demonstrate this? Did other teams use that tool and have positive reviews for its usefulness? [arunc]

127.  The most important thing for career success is developing the ability to present and share your ideas to a group of people.  Practice is how you get good at this.  Join Toastmasters or put yourself in a role where you will need to present a lot. [mikebl]

128.  Take an interview training class.  Learning how to effectively identify other great testers and being a part of the process of bringing them into Microsoft is one of the biggest places you can impact the company long-term. [jamieca]

129.  Be open to adopt new testing technologies and tools.  It could drastically save time and free you up to do more things. [gracez]

130.  Learn new technologies, engineering process and be on top of latest testing methodologies and have the ability to identify and apply the ones that matters to your team. [suneetha]

131.  Drive a team-wide testing project, e.g., code coverage analysis, debugging Watson crashes, and share your knowledge with your team. [ktardito]

132.  Ask questions.  So often folks will sit in silence when they don’t understand something because they assume everyone else already knows the answer and their question is “silly”.  The more experienced you get you realize that others don’t know all the answers either and at least one other person in the room will appreciate that you raised the question because they were wondering the same thing. [raytran]

133.                        Search is your best friend – if you have a question, odds are someone already answered it, and probably has already blogged about it. Bing it before you ask someone.  Use http://msw to search for internal questions. [sathiat]

134.  Learn the tools/methods that will help make your observations actionable. [jamesre]

135.  Explore and research software technologies (IE, Windows, SQL, etc.).  You will be surprised how your knowledge in something like how Win7 x64 vs. x86 or IE security zones will be an asset. [davidhan]

Inspiration and methodology

I had initially planned on creating a list of my own tips, but was inspired by the Microsoft Research talk “Lessons Learned from the World of LOLCats, FAILS and Other Blunders”, by Ben Huh, CEO, Cheezburger Network, available on http://resnet   One key message from the talk was that many contributors (and an editor) can result in better content than a single contributor. 

 

Instead of creating my own list, I crowd sourced the effort, and I was delighted with the results.  I initially asked members of the osenior alias, and a few test leads.  I then expanded to test leads and managers in my larger group, Office Shared Services Test.  Hoping for a better response rate, and hoping to limit discussion, I sent individual emails, and not one email to everyone.  I sent 61 emails and received responses from 40 people.  Not everyone confined themself to 3 tips.