Friday, January 27, 2012

Limits and Laws: A Meandering Walk Through Twenty Years of Software Testing

On March 28th, 2005, I became employee #10 at ImmigrationTracker. That was also including a few people who had come and gone over the five years that the company had been formed. Without a question, this was the smallest company I had ever been a part of, and that actually sounded really exciting. When I walked in, there were two people who focused on selling the product, three people who did software development (with one person dedicated to data optimization) a customer services manager, a support person, and our company president/founder. That was the entire company at that point, and the closest I got to being in an early part of a company’s growth. By the time I left Tracker Corp in January of 2011, we had tripled in size and had made great strides in being one of the core players in the legal software area.

Tracker was a neat place, in that it was an outgrowth of an already successful law firm. Our President had had a successful career as an engineer and an executive, and his wife was the Principal attorney of the law firm. When they had children, he actually was looking forward to having an early retirement and being a stay at home dad, but when the law firm’s biggest client said they wouldn’t stay with them unless their clients could view their case status online, he thought “hey, I could probably do that” and with that, the first version of ImmigrationTracker was born. Later on, other people decided they would love to have this product for their practices, and then over time, a company was born. Tracker and the Pearl Law Group were and are what can best be described as “symbiotic companies” and that made for a lot of the ability for Tracker to grow and thrive over the years.

It was into this environment that I stepped in to be a Customer Support Specialist. For me, it felt strange to be out of the everyday realm of software testing, but truth be told, It would only be a short period of time for me to be 100% focused on Customer Service and Technical Support. By virtue of our having PLG working with us and co-located with us, and with PLG being the principal “first customer”, their development without a dedicated test team or test process didn’t seem so strange. However, as we would go through issues and “pain points” I was seeing areas where I thought that we could have easily caught some of the issues being described.

One thing is for certain in really small companies; if you decide you want to see something get done, nobody is going to tell you “no, you can’t do that!” In fact, people are more than happy to have anyone step up and do more and get involved in any way that will be beneficial. Thus it was, in just a couple of months, I couldn’t keep my mouth shut and I kept talking about how, when I tested certain products, I would do [fillintheblank] and how I found it helpful. Test once, it’s seen as a nice thing. Test twice, and people are appreciative. Test three times, and from then on, you are the de facto company tester. What can I say, I couldn’t leave well enough alone. I would test SQL query changes, installers, and I would also often review customer updates and see what issues kept popping up and ways we could either avoid or minimize issues. One area that I would often find coming up was forms, lots and lots of forms. Tracker being an immigration management system had a ton of immigration forms associated with it, and one of the most frequently tested areas was any time a form had been updated by the government, we had to turn around a fix that included the new form. I think over the six years I was there I tested somewhere around a thousand form revisions if not more.

Having to work so often with databases and forms made the creation of “personas” critical. I created companies full of people with obvious to me names so that I could see if the persona was correctly represented, and if the data matched up the way we expected. That was fun when it came to doing our training sessions (I did most of them for our Server, Client and Web product). It was also fun when I’d see comments back from training and I’d occasionally get a comment back of “Dude, you totally used Fullmetal Alchemist for your data set. That was cool!” I’m not sure what was more surreal, the fact that Immigration attorneys and paralegals were giving me kudos for a persona character set, or that there were Immigration Attorneys or Paralegals familiar with Fullmetal Alchemist (LOL!).

Tracker was a tight knit family, and because we were so small, you couldn’t slack off on things, it would be instantly noticeable. In support, you couldn’t slack off anyway; people were stuck and needed your help. To that end, I really felt that my testing background helped me get to the bottom of some odd problems and helped me develop a good rapport with a lot of our customers. I often found it amusing when I’d hear that a company was planning their upgrade schedule around my vacation time. Loosely translated, they would not schedule an upgrade/update if I was not there (LOL!). It was also interesting to see the relationships that Tracker developed with many of their clients. It was not at all uncommon for customers to come and visit us at our offices and I’d get to meet in person many of the people I was helping over the phone. During those years, we dealt with some interesting challenges, and yes, we also had our share of problems that we all worked through on our product end as well. I am convinced that the Customer Support group was the linchpin that made all that possible (and I’m not blowing my own horn here, I really mean that all of the people we had work through support were fantastic at what they did and do). To a person, if someone were to ask me if I’d recommend customer support reps, without question I’d give our little crack SWAT team top recommendations, every single one of them.

Over time, our little group would grow, and with it, more support people, and those support people would grow into different roles. After two years of splitting my time between support and doing testing where I could, in the Spring of 2007 our Director of Engineering asked me if I’d consider pulling out of the CS group and becoming a full time tester once again. There would be a stipulation to it, though, in that, because we were growing and had maxed out our current space, I had to set up shop in the Director’s office in what was effectively a continuous pair programmer/tester relationship that would last for six months. Looking back, this was seriously one of the coolest things I ever did. I had never been in such close proximity and working so directly with a developer before, where coding and testing happened so quickly. The ability to have such a quick turnaround and such a tight feedback loop was awesome, and it sold me on the idea of “developer and tester pairing”. That arrangement would ultimately end when we moved into our new building and I got my own little place to call my own lab/work area.

Another benefit or disadvantage of working with a small and tight team is the fact that, no matter what you do, people are aware of what is going on with you whether you are aware of it or not. We all knew when one of our co-workers was having relationship problems and we saw it was affecting him and his work. We all saw when one of the guys on our team seemed to be buckling under the stress and frustration with issues, and we all rallied around to help him get through it. There was no cold and efficient HR bureaucracy; we all dealt with each other directly and we came to each other’s aid, and sometimes performed interventions when needed, because we were that close. Sometimes we had to be gentle, and other times, we had to be harsh, because we valued each other like family much of the time. Some times you have to be cruel to be kind when your family goes adrift… thus it should have come as no surprise when it was my turn.

Over the years, I had often said “yeah, I’m a tester, but my real passion is…” and I could rattle off a litany of things I was passionate about. Music, snowboarding, scouting and the various activities that surrounded them all got a great deal of attention from me, and often, it bled into my work life to keep everything on track. This really came home to me in 2009, when a record label contacted me and asked if my old bands material could be released on a compilation album, and then later, if they could release a CD of our material. This led to a special show we decided to do to celebrate the release of the CD, and this got all of us to come together to perform for this show. It was exciting, it was emotional, it was an awesome experience… and it carved a trench into my productivity as a tester! Actually, these were all excuses. The real truth was that I was developing avoidance and procrastination behaviors regarding testing. I just figured I’d get over these humps, and then everything would get back to normal and calm down, and I’d be able to just roll on and everything would be cool. But that wasn’t happening, and my team saw it, way before I was able to acknowledge all was not right in my world. To this end, our VP of technology, a guy I’d worked with shoulder to shoulder daily for five years, basically called me in to his office and laid it on the line for me. If I was going to self destruct, I could do it elsewhere, but he was not going to stand around and watch me throw away everything I’d worked for all these years. It was simple, get my head back into the game, or make plans to go somewhere else.

Because of the closeness of this “family”, this had a very profound effect. This wasn’t a faceless bureaucrat, this was a good friend, one who didn’t want to see me throw my career away. That interaction caused me to realize something. I was bored. Horribly bored, to the point that I almost didn’t care. Up until now all of the distractions were masking the symptoms. Now, with the situation laid bare to me, I was able to objectively review the real problem. I was bored with testing. It was really that simple. But what was I bored with? I later realized I was bored with doing the same thing over and over and over again. My effectiveness was diminishing because I’d lost all sense of excitement and wonder as relates to doing “real testing”. All I was doing was repeating the same steps with a few variations here and there. There was little left to help me be motivated to do yet another round of the same thing yet again. It was then and there I thought to myself “there has got to be a better way to do this”.

In October of 2009, I made a hard and firm decision. I’d explored my “obsessions” in so many other areas and learned everything in the world I could about them. Why hadn’t I done the same with software testing? When I went back to exploring my previous long lived obsessions, I saw that all of them were things I decided I had to know more about, and I dove into them with every fiber of my being. Why should what is effectively my career be any different? I didn’t explore all of those other areas in my life because I became obsessed with them; I became obsessed because I decided to explore them deeply with everything I had in me. In short, with that fateful week in October of 2009, I “took the red pill” and with it, I decided it was time to see just how deep the rabbit hole would go.  For many of you, if you have followed this blog since its inception, you already know the rest of the story. For those who are newer to TESTHEAD, I'll sum up that process tomorrow.

So what pearls of wit and wisdom did I learn during this stage of my journey?

- - When you are working with a really small company, it is a guarantee that the people around you, if you even have to question it, are working as hard if not harder than you are. This stands triply true for the founder and president. Guaranteed, they are way more exposed and on the line than you are. It’s one thing to collect a paycheck from a company. It’s another when you realize the check in question is in some cases coming right out of the founder’s own bank account.

- - When you deal with a lot of data to define if your tests are valid, one of the best ways to make sure that you know if it’s right is to personalize it. Not personalize it by putting your own information in, but having so significant a biography for your personas that you would recognize instantly if something was out of place.

- - Having a built in customer is good, but it dose not replace the need for vigorous testing. Looking at the way that the customer might use the product and getting into their skin may yielded similar results, but it may also open up new avenues to consider that your customers left to their own designs might not come up with.

- - If you can set up an option for a primary developer to have you focus your immediate test efforts with them, you can learn so much more about the code and what they are thinking than going through a bug database and communicating that way. This was my first “semi Agile" experience and I think it worked well.

- - If you are not comfortable with people knowing everything about you and understanding your deeper feelings and the realities of your life, don’t work for a small company (LOL!). Seriously, there’s a bond there that is hard to describe, and goes way beyond just working together. Just count on the fact that, if things are not going right in your world, for whatever reason, your co-workers in this environment will know it before you do. If they care about you, they will help get to the bottom of the problem with you, whether you like it or not ;).

- - We all find ourselves “sleepwalking” at times, and in larger companies, we can do it for longer without anyone really noticing or paying that much attention. Boredom is dangerous, and it can really derail you if you do not make a conscious effort to stave it off. Also, if you do find yourself sleepwalking through what you are doing, make a commitment to explore exactly why you are doing that. Your boredom may be temporary, or it may be a symptom of a deeper problem.

No comments: