I spent Monday and Tuesday making a third pass at my suite of web performance tests for an internal database tool.  This time around, I wrote up a design document which detailed my proposed changes to the existing codebase and cleared it with my supervisor, to ensure that I wouldn’t overlook anything major again.

I am fairly happy with the results.  I ended up with a package of standard tests which run through various functionalities of the tool, looking for errors and unacceptable response times.  These will be executed nightly, so that if any daily development changes induce a bug, it will be caught right away rather than later (when it is much more expensive to fix). These standard tests are mostly component driven– I created a couple dozen components and updated existing components to be dynamic and data driven, whilst preserving compatability with legacy code.  These components each execute simple tasks such as logging in, looking up a certain piece of data, making changes to various fields, and so on… the idea is that they are modular building blocks that can be used to create further tests.

I checked in my new tests to the source control and they are now being executed nightly, although there is still a bug with one of the tests that Ernie is going to take a look at.  As you can tell, though, I am learning quite a bit about web performance test automation!

On Wednesday, I spent the afternoon shadowing Ernie as he troubleshooted some technical issues.  Witnessing him winnowing down the various possibilities was a great chance for me to get a sample of exactly what a Senior SDET does.  I also started reading a book on Service Oriented Architecture (SOA), in order to broaden my understanding of the relationships between the various software components the company uses.  This will be invaluable moving forward in my career, as so many companies either already use SOA or are moving towards it.

I ended my week researching the topic of web test creation for Microsoft Silverlight applications.  Silverlight is a web application framework with capabilities analogous to Flash or Java applets, and which uses an encoded binary body messaging protocol called msbin1. Unfortunately, official support for Silverlight is weak, and there is no built-in way to edit msbin1 messages in Visual Studio.  So in order to make a quality & dynamic web performance test, you need some kind of third-party plugin to handle decoding & encoding of msbin1 objects.

At first, I tried to write my own plugin by following a tutorial on MSDN, but it didn’t really work that well.  I did some research and found a third-party solution that I am pretty happy with, and presented it to my supervisor.  The only problem with this third-party plugin is that documentation is very poor, so I have begun drafting a document which explains it’s use and capabilities.  I will also create a few sample tests to demonstrate the plugin’s capabilities.

Friday, I came in to see a bag full of goodies sitting in my office chair.  It was chock-full of Magic cards, Kaijudo cards, deck boxes, and a D&D soda cozy.

A few of the goodies from the swag bag.

On the company culture side of things, I attended the employee pre-release party for Magic 2014.  A giant booster-draft card tournament was held… I ended up winning two of my four matches, which I was relatively happy with, given how good at the game many of the employees there are.  I also met several different people from around the company and learned about what they do.  Oh, and pizza was provided… it seemed like there were around a hundred pizzas, although that could have been my imagination.

I walked away with a ton of booster packs, exclusive promotional cards, and good memories.  Being an intern does pay!

This week was a half-week due to the 4th of July holiday.

So, I learned some tough real-world software engineering lessons this week.  I submitted the test suite I wrote last week for a code review and it turned out that a bunch of test components which I had assumed were unused and superfluous were actually being referenced by the tests for another software tool.  Whoops!  So some of the new tests that I wrote are now duplicate in functionality to the old existing code, which is a major no-no, as twice as much code means twice as much cost to maintain.  Yeah, that was a bit embarrassing…  I will be refactoring my test suite next week to fix all of that.

Lesson learned: NEVER assume a piece of code isn’t an external dependency elsewhere.

I also began studying some more performance-related concepts.  I worked my way through the book “Advanced Web Metrics with Google Analytics” by Brian Clifton. Google Analytics is pretty much the current industry standard for website traffic analysis and provides a wealth of data which can be very useful in creating accurate load & stress tests.

Another lesson learned: never go on vacation, lest your cubicle be Justin Biebered:

This is what happens if you use your vacation time at WotC.

That’s all for this week.  I look forward to transitioning beyond scripted web testing and into performance testing.

I spent this week cutting my teeth on test automation by revising a set of web performance acceptance tests for an internal database tool. Web performance tests are basically coded scripts that run against a web service, validating that certain functionalities are present and that response times are within the defined standard. Besides just revising and updating the existing test suite, I also created several new tests for features that were not already within the test coverage.

I spent a good chunk of time defining a set of reusable components for basic things like page navigation, so that creating future web performance tests tests is somewhat streamlined. By the time I was done with these, I had learned quite a bit about HTTP and data extraction from web services. I now feel confident in my own ability to create a set of meaningful automated tests of a web page/web service.

I also took some time to explore creating my own sample WCF (Windows Communication Foundation) web service and client application. This was just an ASPX webpage interface that let a user browse and edit an underlying SQL database. It was a pretty basic program but gave me a deeper understanding of what was going on under the hood of the web services I’ve been working on.

Other than all that, I also met with my supervisor and received a high-level overview of performance engineering. Now that I have learned basic web performance testing, I will move on to learning about creating and analyzing load, stress, stability, failover, and endurance tests– whew! It’s going to be a busy summer.

Oh, and a couple personal highlights– the office ergonomics expert switched out my old chair for a giant, awesome new chair that looks like a CEO should be sitting in it. Definite upgrade!  Also, the intern who sits next to me had been out sick all week, and I came in one day to find this:

You would think WotC, of all places, would keep a cleric on staff to remove curses.

A couple of times, I could swear I saw its hand move out of the corner of my eye…

Looking forward to diving into more testing next week!

This blog will chronicle my experiences as a Performance Engineering intern at Wizards of the Coast.  Having been a WotC fan for many years, this internship is in many ways a dream come true.  I will be working under the mentorship of WotC’s Ernie Nelson (Senior SDET) and Evergreen’s Sheryl Shulman (Professor of Computer Science).

Stay tuned for weekly summaries of what I’m learning, challenges I’ve encountered, and workplace experiences in general!