Friday, June 19, 2015

Unit Testing...Not A QA Activity? #BuckTheNorm

Sooo...this past few weeks I've been getting down and dirty with a type of testing that is new to me, but not new testing (see how I did that? ;)). The type of testing that in my opinion, should be the start of the quality cycle during development, what say you, am I speaking of? Unit testing of course! Finally, after months of being to "tied up" and "busy", I had the opportunity to devote at least 6 hours per week, to learning how to unit test stuffs.

This opportunity was created, by the launch of a pilot class for our advanced "Top Gun" training program. Being a pilot, I thought I needed to prove out the fact that unit testing (and TDD in greater context) could be taught to people who did not come from a traditional developer background...aka yours truly.

Is Unit Testing Hard

Welp, the short answer is yes. The long answer, is yes initially, but not in the long term. So my first foray into unit testing, was focused around an area of our team's product, which focuses on ensuring a thing, can fall into a queue. So essentially, we are testing to ensure that the method which decides if something should be in a queue works.

The Hard Part

Unfortunately, the thing that we are testing, is not well suited for testing, due to lack of abstractability through traditional means such as interfaces. So, we could not new up our own real thing, and pass it into our queue checker method.  What to do? No useful interfaces meant we were in a pickle.

Mocking & Shimming To The Rescue

As a small team focused on attempting to unit test something that is hard to abstract, we decided to attempt to create a shell of the real thing, and fill it out as necessary through a mocking framework. I won't get into the nitty gritty details, but essentially mocking out a complex allows you to create a scaffolding of properties and methods that belong to the object, and when called, need to be provided input down to the property level. For example, if you have an order, which requires a transaction, which requires a list of requirements, which is a'd need to provide your shell with all of those elements, but nothing else. The powerful thing is, by creating the shell and providing the information necessary, you understand what the expected outcome of the method call should be, therefore are able to ensure it is or isn't working properly.

The Easy Part

So after going through figuring out which pieces needed to be filled out in our tests, we were able to abstract a few of the repeatables away, which allowed us to become faster, and created an overall repeatable and understandable process. Which to me, shattered the stigma of a hard unit test.

What This Means To Overall Quality

Think about it this a quality fanatic, I want to be involved in all aspects of the application stack. From how the code is written, to how the pieces talk to each other, to how the GUI works. Unit testing provides me the technical ability to speak to provide quality at the very lowest technical level, and at the very earliest possible time, with respect to when the application is written.

Additionally, writing unit tests, forced me to understand at a very granular level, how our application logic really worked. This is a very powerful idea. I now can understand what methods drive our queues!

I believe that all quality champions should get involved in unit testing, as that is where the meat of your application logic lives. You will help your developers code faster (since they won't have to write unit tests), you will help your team achieve higher quality (since tests will be written earlier, and be more granular) and you will definitely help yourself, by becoming more technically savvy.

But most importantly, you will keep striving to the ultimate Quality Champion state...

Friday, June 5, 2015

What Losing A Senior Developer Means To A Quality Professional

This week, my team experienced the loss of a senior developer mentor. The loss (not actual loss loss, just leaving the company), came as a shock for most, and I noticed a major deflate in our team morale. Losing the person who wrote our framework, pretty much gave us our GUI testing technical direction and solved many of our problems gutted everyone, even me as a leader. For a day or so I thought to myself, man it's really going to be hard to figure out the next big thing in testing. "Viper", was the dude who really set us off on the path we are going down now.

With his mentoring, it was amazing to watch our team evolve from arguing about which tool to use for GUI automation, to 'bicker' about which interfaces to implement. What I'm getting at, is while the loss of Viper will be hard to swallow, I have already moved on, and need to take the next steps for our team to do so. I have already noticed that although Viper has departed, our team is moving on, and this is an opportunity to form more new relationships with other awesome developers.

It is imperative for us as Senior Quality Professionals (because I really believe automation professionals are just that) to form more deep relationships with not only one developer.

The loss on of one senior developer cannot be viewed as a disaster. It has to be viewed as an opportunity for growth and a push to form new relationships with other devs.

Today while at a team standup, I pushed our team to push their devs to review automation code. We are forging ahead. We will get stronger and deal with the loss of one senior dev mentor/ally , by acquiring others.

So while Viper will be missed, Iceman and the rest of Top Gun will continue to forge The Fortress.

Melodramatic Iceman Out.

My Build 2015 Gump

So, a few months ago I went to \\Build\ 2015. Honestly, it was the best conference I have been to so far in my professional career. It was filled with new products, fun, and innovation. I learned a lot about new technologies, and even though testing is close to my heart, I explored some new dev territory. Build conference, is not only for developers you know...even though their focus was...developers , developers, developers. I would love to describe everything that was near and dear to my heart in text, but I had the privilege of giving a tech talk to my team mates , and so decided to post the presentation for everyone to view @ . If you are interested in what I thought of \\Build\ 2015, and what I learned That's all for today. Over and Out.