I’ve been a .NET developer here at Apprenda for about two and a half years now. In that time, I have had the pleasure of working with our phenomenal dev team, learned new technologies, and built / improved upon our remarkable product. However, for this next release cycle, I have (willingly) put on a different hat and moved to the other side of the R&D wall to become a Senior Test Engineer. I will now pause so any developers reading this can catch their breath and process that information.
Why would I do such a thing?
Well, the most pressing reason is need. We‘ve struggled to find qualified people to fill the role required of a full-time test engineer. It’s probably a bit of a hard sell to most devs. But, the reality is, it’s a really cool position! Keep in mind: we’re not a company that makes a SaaS app or even a traditional on-premise app. We’re a complex, distributed system that interacts with many other complex systems, like IIS, SQL Server, Oracle, Tomcat, and most importantly, the host OS itself.
This means that testing is inherently more challenging. Traditional unit tests cannot, for example, determine if the command issued to IIS to create an app pool has succeeded or not. Could we abstract and mock the interface to IIS? Sure. But there comes a point where you’re actually testing your mocks more than the system itself. This means that, in addition to unit tests, our test suite is comprised of numerous integration tests. Some are traditional Selenium tests that exercise the platform through the user interface, but there are many other types of test modules that are used. Some invoke external tools like ACS (Apprenda Cloud Shell), some invoke NUnit to run tests against the platform’s REST APIs, some run SQL queries, and some use AutoIT to fill in browser authentication prompts when using an external user store, etc.
You get the idea
Behind all of these complex tests is a home-built system (web UI and Windows service) that allows the test team to author modules and glue them together into test suites. These tests can then be run ad-hoc or be scheduled through our build server. Every night our master test suite runs against multiple environments, each of which consists of several VMs, for each supported version of the platform. But with great power comes great responsibility and it falls on us test engineers to keep this running smoothly. We are constantly on the lookout for new tools that will make our job easier and faster: we experiment with a variety of technologies to see if they’ll work.
The important question now is “How do I like the change so far?”
It’s great! It has certainly been a challenge to detach myself from the normal product development routine or to resist trying to diagnose and fix a bug that someone else on the test team finds. But it has been fun to recognize all the improvements that can be made to our processes and define stories and tasks to accomplish them. My first task has been building a report that the test team will use to analyze the previous night’s test runs. Historically, analyzing test runs has been a painstakingly manual task, but hopefully it will now be reduced to analyzing a single report.
The lesson learned is that being a developer for the test team does NOT take away any clout or prestige. In fact, you get the gratification of people benefiting from your work much faster…without needing to wade through the pressures or red tape associated with product development. I challenge all developers out there to channel your inner Test Engineer as much as possible…it’s better than you think!
Does this sound interesting to you? Apply today!