SDET in Training?

I've been a little out of the loop the past few days, and I've had a number of reasons. One of which is that I've just finished editing the next podcast for TWiST, and delivered it this morning. Once it's posted, I'll tell you all about it :). Also, there's the Week 3 of Bug Advocacy, which is heading into the Final Exam after Saturday, so I've been spending a lot of time there, too.

Still, those aren't the biggest areas I've been focusing my attention. Most of my time has been with a new reality. Getting ready for my first official "stand-up" on my development project. Huh?!

Yep, it's true, I have my first project that's a real development initiative (well a Development Test  initiative,  to be more accurate) but I can claim a project in GitHub, paired development time with other developers, and something that's been entertaining... a tester to test my code and fixes (because really, no developer should be testing their own stuff, right? Oh, and I use the term developer loosely here ;) ).

A couple of weeks ago at our most recent retrospective, it was decided that there was a need for a different level of automated testing. We have lots of TDD happening here, so there's a lot of  focus on unit level testing and behavior driven testing, as well as automated acceptance tests, but even with those, we were still seeing issues that crept through to other environments. With that, it was decided that we needed a more user facing suite of tests, that covered what the user would actually see on each of these environments... and that I should be the one to lead up that project and get it into production. With that, I added the project manager and programmer hat officially to my job title.

In the past, I have had informal test initiatives. If I automated them or not was my own concern. Here, however, I have been asked to make it a genuine project, with real stories, real velocity points, and real people that I can call on to help me get things in place and to make sure that those initiatives are met. In short, I have to answer for them in an official capacity now. It's no longer just me doing things on my own. My test asets have become part of the company and I am expected to deliver on them... and I'm excited!

Most of my career, my test assets were just my own personal toolbox. If they helped me get something done, then great. They existed separately from the rest of the product, and were often not version controlled beyond on my local machines. I certainly never had a project in GitHub to pull and commit from. I do now! SideReel is making good on their promise to integrate me into the development team, and to be regularly involved in programming initiatives. Granted, at the moment, it's limited to me writing steps and procedures in Cucumber, b ut even there I'm having to cobble together a lot of different  projects, applications and tools to accomplish my goals.  Even a basic set of tests is interacting with tools like ruby, celerity, nokogiri, capybara, rspec, selenium, webrat, plus a bunch of others I'm going to need to get more familiar with.

I've been using The RSpec Book (review coming soon) to help me understand all of this, and to get into the mind of a TDD and BDD coder. Progress is moving along a little bit each day. I've been blessed with a developer that has been very patient and helped me build some of the background structures I'll need to accomplish a lot of the goals that we have. We made a conscious decision for this project to try to keep the focus on what the user would see and interacting at that level. This has already shown us some interesting challenges, the first of which is finding ways to make sure that the tests are not brittle (or to be fair, not as brittle as they might normally be). I've also been given a crash course in targeting actions to CSS locators. My tests are stil a little more verbose than I'd like, but I'm already seeing places where I can DRY up the code and make for more reusable pieces.

The  real benefit of this is that I am being given time to do this every day; in previous jobs, it was hard to get the time to sit down and dedicate myself to doing any meaningful automation. Now, it's expected that  the group will help take on testing roles within their pairings so that I can focus attention on automating tests. I will still confess that it's not a natural fit for me. I still feel like I'm playing in the wrong sandbox, but hey, I'm not complaining :).

So does this spell a future as an SDET? I'm not entirely sure that I'll go that far, but for now, I'm greatly enjoying the fact that I am expected now to wear a coders hat for a good portion of my time here, with the proviso that I still subject our applications to real world exploratory Test-Fu, which I am more than happy to do!