Crash (UA)Test Dummy

31 Jul

Part I:    Crash Course

I’m very fond of the phrase “laws are like sausages — it is better not to see them being made”, as even someone without the experience of being on the working end of a meat grinder can relate to not wanting to know the details of certain things. In the case of technology applications, everyone loves the new functionality being introduced, but the work to bring the application to market is purposefully and happily ignored by the users. It is bittersweet that I say I used to be in that camp, ignorance was indeed bliss. Today, I’m one of our development team’s user acceptance testers; I’m not just watching the sausage get made, I’m helping create the recipe and taste the finished product.  Let me set the stage a bit.

Over the past few years, I have steadily become more involved with our software development process, specifically on the requirements and testing phases. Here at Fortigent we run what’s called an agile process for software development. Agile in the sense that a project is broken into smaller pieces, “sprints” as they are known, and the requirements gathering and testing are continuously performed. Agile is the critique of the mainstream approach to software development known as the “waterfall” method. In that process, the requirements for the entire project are collected upfront, and the business testing is performed after all the parts have been assembled. The premise that the waterfall method is based on is getting the requirements complete and correct in the beginning, which is exactly what agile is critiquing.

My role is to provide the voice, or persona, of our advisory clients and their end clients into the development phase for each sprint. After development finishes their work, I make sure what we thought was needed works in a way that improves our client’s experience while delivering the intended solution. I’ve learned phrases like “iterate” and the term “scope creep” has been levied towards me more times than I can count. For the sake of full disclosure, I do have some experience with technology prior to this. I was a computer science major for all of one semester during my freshmen year at college, so some aspects I had a high level knowledge of.

Because you work on the same big project and go through multiple iterations of requirements gathering and testing for each feature, I feel like I’m getting behind the wheel of the same car to test out the brakes in one sprint, then the driver’s side airbags in another, and so forth. You know with each sprint that the brakes won’t stop the car completely and will need some tweaks, or the airbag deploys but not at the optimal time. What you want to avoid are the instances where you crash through the windshield. Part II will walk through what one of those crashes looked like, and how our agile process allowed us to quickly move on to keep me in the driver’s seat for the next crash test.

One Response to “Crash (UA)Test Dummy”

  1. Jamie McIntyre (@Jamie_McI) August 4, 2013 at 7:18 am #

    WOW. Never knew about your CompSci Experience at school. Impressive.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: