[Rob] I know I said the next installment would be on tactics…but I think in response to feedback Woon Kiat I’ll go with ‘resources' first.
Before that, very quickly, there was a comment from AT on alpha/beta users submitting automation test cases along with bugs. Generally speaking, repro steps for bugs are added to the regression test case set and automated where appropriate. Directly accepting scripts, however, would cause security concerns. It would be a nice world though to just be able to build a customer ‘drop acceptance’ automation test case database… J Now you have me thinking about a tool to allow steps to be entered through a web page that would build a safe script to run against the product...hmmmm….I could build that using the VC++ IDE once I figure out the design…
Resources for Test in VC
Test candidates right out of school rarely have formal test training. The experience level is also limited to personal code and maybe a few small group projects. This gives us the challenge of identifying those candidates that have a rough talent for ‘finding bugs’ or ‘breaking things’ J along with a way to navigate through a product and identify where priority bugs may hide. We also look for people who can adapt quickly and apply techniques ‘just learned’ to new problem areas.
We write test automation and our product is a development tool. Therefore we also look for people who have development proficiency with C++ (knowledge, style, problem solving, … pretty much our customer base).
Our company has training courses (all disciplines) that supplement on the job experience. Everyone on the team is a mentor to some degree or another for every new hire we get. Formal and informal mentors are encouraged in addition to an individual’s team lead. Acquiring a mentor from outside the team is one way we continue to mix ideas, technologies, and techniques throughout the company. We also like to occasionally reorganize teams to allow people to move to new feature areas and ‘stay fresh’ by providing new challenges.
Product specific training is hands on. For Visual C++ we focus heavily on dogfooding (use the current drops for real world coding of team tools and personal hobby projects) the product. Plenty of texts exist on previous versions of the product to help people understand where we’ve been. Specification documents (or, when not available, talks with program managers and feature developers) bring us up to date for what to expect in the current version. When one is new to a feature area, reviewing the old test case base and the bug database helps bring you up to date on the current status and where testing has gone before. Particularly interesting are those bugs found by customers, as they show where customers went with the product that the previous test plans did not anticipate (allowing us to learn better what to give priority to in the limited time we have to test).
Some books found on my office shelf today (more at home where I have a bigger shelf…oh, and I’m not saying these are all ‘fantastic’ books, though some are, I’m just giving a snapshot of what’s behind me):
Various language books (C++, VB, C#)
Various manuals from internal microsoft training courses
Various manuals from Test conferences (most recent: PNSQC and SQE)
Debugging Applications for .NET and Windows, Robbins
Lessons Learned in Software Testing, Kaner et al
How to Break Software, Whittaker
Design Patterns, Gamma et al
Quality Software Management, Weinberg
Writing Secure Code, Howard et al
Automation Programmer’s Reference, Microsoft Press
Applied Microsoft .NET Framework Programming, Richter
Programming with Visual C++ .NET, Shepherd et al
Programming Windows, Petzold
Inside COM, Rogerson
;-)
[This posting is provided "AS IS" with no warranties, and confers no rights. Use of any included script samples are subject to the terms specified at http://www.microsoft.com/info/cpyright.htm.]
