Five years and counting...

  • Article

What can I say. Time really flies by.

Five years ago, I join Microsoft shortly after graduation. The most unique thing with my NEO (New Employee Orientation) was that Bill Gates stepped in to make a short speech. Apparently, he does this once or twice a year, and I happen to catch the right week. I can't say I remember what he said, but hey, I don't remember much of NEO at this point, either.

At Microsoft, tradition states that five year multiples mark major milestones in employment. So, I got the first such "differentiators" last week - a silver desk clock. Apparently, there is now a choice between a clock and a pen, but I have no idea why anyone would go for the pen other than to be "different".

Well, as with any milestone, one has to step back and reflect. What have I accomplished, and what do I want to do in the future?

I started out testing ISAPI Filters, eventually added ISAPI Extensions to the mix, and now, the new API for the IIS7 integrated pipeline. Hmm, a pattern emerges... likes to test native code API that underlie core IIS extensibility. I enjoy learning and figuring out how things work, plumbing and all, so if it is supposed to work on IIS, I probably had to look at it at one point or another. :-)

Then, there are all the tools that I have had to write throughout the years on my "copiously spare" time to make things go.

  • Automation framework and driver to install Windows and consume and run all IIS tests
  • Automation to install all IIS tests, which are built and packaged as a bona-fide versioned and installable MSI every night
  • Automatic MSI generation tool to create the daily MSI installer of all IIS tests after the test binaries/scripts/content are built/released
  • Virtual Machine integration so that installing Windows and IIS (and running tests afterwards) on a virtual machine is no different than a physical machine
  • Ever so often, it would have to automatically run something else, like Indigo

Yes, it has been a lot of fun learning in-depth about various technologies, building automation tools, integrating them all together to accomplish team-wide processes, and oh, did I mention that I still test IIS extensibility while building all of this on my own? Yes, it all has to work, or we might as well go home that day. But therein lies the pressure and the challenge - how to write and release reliable and debuggable code that is flexible and just works.

To put it into perspective - yes, it is very cool that I can find and contact the folks who built Windows Setup, MSI technologies, and Virtual Machine, directly ask them some questions that documentation did not make clear, and they would pull up all sorts of other related documentation and details to help me. It is critical to thoroughly understanding the problem space and solutions available.

However, this sort of "privilege" is no longer constrained to just Microsoft internally. Now, it is pretty much visible and available to anyone outside of Microsoft as well - if you would only take the effort to find and contact the right folks in the right channels (incidentally, this is something I have to figure out as well). Microsoft is driving hard at community efforts and getting everyone in the company to engage in some manner with the customer and end-user. So nowadays, you can find (with some effort) the same folks who build the technologies that you are using, directly ask them questions, and see their tremendous responses. For an example, just look at what is going on with Visual Studio "Whidbey" and ASP.Net 2.0 (and what will likely happen for IIS 7.0). Customers and end users have such direct contact and influence on those products because you could be talking to the developer coding the feature, PM designing the feature, or the tester validating the feature.

Yes, I have seen and done a lot of fun things the last five years at Microsoft. So, let me ponder a bit about what is coming over the horizen as well as what the future brings beyond the horizon...

  • Testing, as a discipline, must invest in and advance itself. This requires technical people to remain in testing
  • Testers need to debug and develop more code, and developers must test more

Gone are the maverick days of manually typing/clicking or ad-hoc checking of product functionality. While code development has not change fundamentally, the degree of complexity brought about by integrating code interactions have increased exponentially. And you simply cannot manually repeat those steps with every functional single integration. So, code needs to be written to allow automatic testing of basic I/O - to replace the manual typing/clicking - so that human testers can use intuition and other non-mechanical facilities and focus on the non-obvious effects of code interactions.

Yeah, that's where I think we are going, and the ride should be fun.

//David