The Technical On-Deck List

There have been times when I have questioned our approach to staffing the test team with only technical people.  What will we do when all the test frameworks and testing-related tools and utilities are built? How do we keep all these programmers in testing happy and productive?

Happily that day never seems to come.  The applications and business needs keep changing and, better yet, the more cool (and productive) stuff we do, the more cool (and productive) stuff we find to do. I call this the escalating awesomeness factor.

This struck me today as I was sitting with a few members of my team troubleshooting some automation code.  As we worked on this, my mind raced to a list of other projects not getting attention.  Here is a sampling from my technical on-desk list:

Automation of Test Maintenance for Existing Tests

We have a large test suite that we run every day.  Running them each day enables us to keep up with test maintenance (things shouldn’t pile up until the end of a sprint before production delivery).  Even with proper staffing (the right people and the right amount of the right people), some parts of test maintenance is tedious.  On the short list of things to do is to look at all the tasks we do for test maintenance and then program our way out of it.

Automated management for rerunning tests

Our build system kicks off our test suite, and most of the processes are automated.  But each day, we still spend too much valuable time babysitting tests.  One of the biggest time sucks is rerunning tests.  With our current application suite, we cannot send all our tests to the grid or cloud, and we have to work with a limited set of resources – licenses and workstations.  Using smart people to babysit machines is so wrong.  We must make tests and machines take care of themselves. We know what to do (in fact, we have a pretty cool plan for what to build), but the challenge is to find time and do it.

Create custom test portals for each project

Our current test repository is geared for the test team.  It does not present information in a way that a specific development team (product owners, application programmers, and testers) cares about.  Further, we are between test frameworks.  Most tests are in our old GUI framework, some are in our new services framework, and soon tests will be in our new GUI framework – and there are unit and programmer-written integration tests.  Project teams don’t care about which frameworks we use, they just want to know if their code and features are working each day.  We have a prototype that pulls all this together and presents it in a useful way, but it is one more side project that we have to find time and energy to complete.  The product teams will love it, though.

Being better with TDD and unit tests on our test team projects

This is a case of the shoe maker’s son having no shoes.  We on the test team have developed applications with no unit tests and no regression tests.  Eek.  We have some work to do to clean up our development projects.  Even though there is work here that doesn’t add any cool new features to our frameworks, I am looking forward to this as an excuse to work on some new testing tools.  We have been looking at Cucumber and RSpec for a while.  This will be a good opportunity for all of us.

Next generation tools

We are still using commercial tools and I am anxious to move away from them (and to save the licensing fees for the company).  There are things that I like about the current tools that we have to replicate before we leave.  Taking a relatively raw tool like WATIR (webdriver) and building all the features needed for abstraction, readability, reusability, and maintainability is a big job.  Even though I feel confident that we can use tools that are not complete and still get value, it is daunting task.  It hurts so good.

I love having a full queue of meaty technical work, and I love even more knowing that when this is done, the next work will be even more challenging (and fun)!