In Through the Side Door: Advice from an Unconventional Career

First off, Happy New Year to all of my friends and readers out there. I wish you all a great 2015 with the hope that what you strive to do and accomplish will be met.

About two years ago, I was given the opportunity to do a talk for a conference that would be happening in India called ThinkTest. My friend Smita Mishra extended an invitation to me to participate, and while I could not actually travel to India at that time, we decided to try something unorthodox. Why not video-tape my talk, and we would whittle it down to a presentation length and make it available to those who wanted to view it? Since I found myself in a hotel room near Chicago for an extra day, I decided to turn the room into a makeshift film studio and talk about my career as a software tester, its ups and downs, and other things that helped make it a reality.

Sadly, due to an automobile accident that incapacitated Smita for awhile, the conference had to be canceled. The talk project was, of course, put on hold, and then, over time, other initiatives took center stage, and I forgot about the talk and the recordings... that is, until a couple of months ago. Lalit Bhamare of Tea Time With Testers, asked me if we could use the material for his new project, TV for Testers. I said "sure", and he then proceeded to gather the clips I had recorded and delivered to Smita into the talk that is presented here.

In Through The Side Door

First, I feel it only appropriate to say... this is a long talk! I had originally recorded it with the idea that we would cherry pick the best parts and make a shorter presentation (something around forty minutes) but through correspondence with Lalit, he asked if it would be OK to present the entire talk, in its (mostly) unfiltered form. He felt that there was a lot of insights I offered that would be of value to those who, likewise, came to their careers from peripheral avenues, and the asides and segues, in his opinion, actually added to the value of the talk. So, again, that's what we decided to do. Lalit posted the talk on TV for Testers today, and I am now saying to those who would like to check it out, please do so.

Again, my thanks to Smita for asking me to put this together, and my thanks to Lalit for deciding he wanted to have it be seen. If you take the time to watch it, I also thank you for doing exactly that. To borrow from and paraphrase the recording artist Seal, "I hope you enjoy the presentation; it was the best material I had at the time" :).

Have I Found What I'm Looking For?

As those who follow my blog might notice, I tent to mangle pop culture references to make my titles or make other post points when I write here. Today is no exception.

As many of you may be aware, I started a new job on Monday, November 19, 2012. You might also notice that this blog has been quiet since Tuesday, November 20, 2012. That is not a coincidence! Much of my time the past two weeks, with the exception of Thanksgiving weekend and some much needed time with my family, I've been dealing with a single minded focus; coming to grips with the paradigm shift I've undertaken.

For years, I was the lone gun. I was the guy who either had the answers, or needed to get the answers. I was mostly responsible to myself, and mostly took care of things on my own. Today, I'm the polar opposite of that world view. I'm part of a testing team with some rather talented people, and we communicate about our findings... a lot. Socialtext uses a tool called Colloquy, which is, effectively, an IRC client. There's two main chats that go on all day, every day. One's for dev, the other is for testing. When I say these conversations go on all day, that's exactly what I mean. We all contribute, we all share what we see, we all keep each other updated as to what we see and what we find, and those chats inform where we go next, what we do next, and what the developers see next. So I'm on that window and I'm typing a fair amount each day... and I came to a realization as I was doing it.

There's somewhere else that I do this. Once a month, for a couple of hours, I and a number of other testers get together, via a chat mechanism, and we talk testing. We pick an app, we explore it, we find issues, we talk about them, we decide where to go next based on what we learn, and we discuss what we learn. If what I'm describing sounds a lot like Weekend Testing, that's because it is what I'm describing. A couple of years ago I lamented "oh, wouldn't it be really cool if an organization actually used the Weekend Testing model? Think of what we could all learn! Think of what we could share! Think of how much wasted time could be avoided because we are actually communicating!"

For the past few years, I've dreamed of seeing something like this exist. I've hoped, but had my dreams either dashed by indifference, or the feeling that there's no time to do such a thing. I often wondered, though, what would a company look like that actually did this? Now I know. It looks like Socialtext. It looks like that because they actually leverage what they learn and they use it together. If something is going off the rails, we all know pretty quickly. If something looks promising, we're encouraged to explore it. Explore and share what we find. Feedback is almost immediate, and it's refreshing, exhilarating, infuriating, exhausting, maddening, and enlightening, all at the same time. It's the chance to live the Weekend Testing model and ethos full time. The funny thing is, though, it's left me with little energy to do many other things, at least for the near term.

So, for those wondering why I've been so quiet as of late, there's the reason. Also, be careful what you wish for... you just might get it :).

TESTHEAD REDUX: Testing's "Lone Gunfighters"

Image URL: The Old Gunfighter

As I was first trying to design TESTHEAD and figure out what would be the core point, I played with a lot of different ideas. What could I really offer to the community? What would be my niche? What could I speak to differently than anyone else out there? There were a lot of us talking about changes to how we test, to looking at Agile practices, to integrating development and testing, and touching on testing automation, but I wasn't seeing the way I could add any kind of a fresh voice to those discussions. About a week in, though, I came across what was, really, the one thing that I could speak to very directly, and in a lot of different ways. That topic was what it feels like to be the sole tester in an organization.

Before I standardized on the term "The Lone Tester" (yep, it kinda' sounds like The Lone Ranger, so I ultimately went with that slightly poetic moniker) I played with lots of different terms and names. Regardless of what I called myself, though, the reality was the same. For all practical purposes, I was alone in my testing efforts. How did that shape me then? How does it shape me now?

THEN:

When the situation of the “Lone Gunfighter” happens, testing takes on an interesting hue. Now, it’s all on you, and when you are the last line of defense, you really are all there is between the product getting out into the wild and bad things potentially happening. Sobering is a good word for this situation.

NOW:

I'd say the big difference between then and now is the fact that, for all intents and purposes, I've put down the cudgel of "it's all on me". It may seem that way, but it's really not. In an Agile organization, there are other people testing, not just me. My role is that of the sole person whose primary responsibility is testing. For everyone else, it's a peripheral activity, but I've stopped believing that I'm the only one actively testing in the organization. What's more, I've dropped the conceit that I'm the only one qualified to test. That's an insult to the programmers, who to be honest can do quite solid testing, and think of things I don't.

THEN:

Many times, we can feel like we have no direction, or that we are being barked at to get this or that accomplished, with little to no support from others. By putting yourself into the mode of consultant, you change the relationship. Now you are providing a service to a customer, and in this case, the development team and the ones purchasing or using the product are your customers. When the development team becomes a customer and your goal is to provide top notch service to that costumer, your entire mindset and focus changes.

NOW:

I still see a lot of truth in that mindset, more so than I did when I first wrote about it, because in many ways, in the organizations I've been part of, I've often been held apart from the programming team. I'm not entirely sure if that was by design or by circumstance, but there is a sense that there are a lot of people who believe that testing should not become too "chummy" with the programmers. By being held as separate, like a service provider to the team, that "respectful distance" is maintained. Again, I've heard that many have gone beyond that relationship and have had a more casual connection, but that hasn't quite been my experience. Not yet anyway :).

THEN:

Make sure that you define your role as clearly as possible, and what you feel the expectations for your contribution should be, and let them say what they feel it should be as well. This agreement may be formal and in writing, or it may be something discussed in meetings or between team mates. Either way, get it out there so everyone knows the expectation and can work to meet or exceed it.

NOW:

I agree with this more now than I did then. This can doom you if you get it wrong, or be your biggest ally if you get it right.What's also important is to regularly revisit this topic. Situations change, and different people have different opinions and attitudes. I had a period where I had three directors and all three directors had a different idea what my contribution should be. That's totally OK, but it also reinforces why it's important to consistently get those who you are working with to come to a consensus as to what your role and contribution should be, and what the team actually values. One director thought that my developing technical chops and programming skills would be the best use of my time. Another thought exploratory testing was of much higher priority. Both are valuable, both are important, but different people put different weight on certain things. Knowing that and working with that in mind can be a big help.

THEN:

Get over the us vs. them mentality: If you have no idea what this means, congratulations, you work at a company that “gets it”. If you are all too familiar with this mentality, make the first steps to change that dynamic. Testing and development are allies, they both have the same goal, to ship a product that has high quality and that will meet the needs of its customers. No other attitude is going to help that other than development and testing working together to help solve problems.

NOW:

Nothing to add to it, I believe this 100%, now and then.

THEN:

Accept that you will not be an expert in everything: You will have knowledge gaps, and at times those gaps will be huge, but you have to make a clear assessment of your strengths and weaknesses and put them out there. Yes, make them known, the strengths and the weaknesses. Also, make a game plan to overcome those weaknesses where possible and telegraph the fact that you are working to close those gaps.

NOW:

How ironic that I was talking then about my knowledge gaps, only to step into an environment where there were ten times more moving parts! Again, a Lone Tester will not know everything, they will not be able to be all things to all people on the team, unless they are an especially rare kind of superhero. I'm not that person.  That need not be a barrier to success, but it needs to be addressed seriously and honestly. If you have big goals of making huge strides in a particular domain, know you will have to devote a substantial amount of "private time" to make that happen (meaning off the clock). On the clock, don't be surprised if you find yourself juggling five balls at once, all day, every day.

THEN:

When you are Lone Gunfighter, you may be able to find someone who can help you in the development group, but often they may have limitations as well (especially around testing questions and issues). Reach out to other testers you have worked with and ask questions. I still have mentoring relationships with friends who were instrumental in my development over the past 20 years, and I also occasionally get asked questions as to something I have experience in. I believe it’s important to have a mentor and to be a mentor, so look for opportunities where this can be utilized. 

NOW:

Twitter and the testing blogosphere is the single biggest resource of ideas, inspiration, cheer-leading, coaching and mentoring that a Lone tester could hope for. I follow around 400 people that are involved with testing or are thought leaders in software testing and software development. So many breakthroughs with ideas and approaches have happened through discussions that take place on Twitter (especially those that I just read between other testers) that I feel I can go there and be "spiritually fed" daily. That's not a saccharine sentiment, I actually mean that. I'm amazed at the discussions and insights I have learned from other testers all over the world.


Post Script:

The irony to writing this update is that, as of last Friday, November 9, 2012, I made a decision to, for now, hang up my Lone Tester status. That will deserve a much more detailed blog post, and I will be writing that soon enough. Many of the thrills of that line of testing are also many of its more draining challenges, and for me personally, some of my reflections on these ideas and the way that things have been for the past decade has made me desire the interaction of a testing team, where I can interact with and bounce ideas off of other testers. Not just testers in the Twitter/blogoshere world, but testers I'm sitting with, interacting with, mentoring and being mentored by them. To that end, I'll be starting a new adventure with SocialText on Monday, November 19, 2012.

Pulling Out of the Shadows

Image from http://douglascootey.com/

The next few paragraphs should be a blinding flash of the obvious.

For those who have followed this blog for any length of time, you will notice and you will know certain things about me. You know I have a high energy level. You know that I am involved in a lot of endeavors, and enjoy those endeavors. You know that I like to write, sometimes a lot. You know that I enjoy investigating various aspects of life and the way things work. You also know that I believe strongly in being an open book about my life, my journey and the challenges that I face. So here goes, and if this is a surprise to anyone, you really aren't paying attention...

I am an adult with Attention Deficit Hyperactivity Disorder (Adult ADHD).

Nope, no self-deprecating humor this time. No jokes about “squirrel” or “shiny” or any of that. I have ADHD, and for the past 27 years, I have done my level best to try to deal with it in a variety of ways. The key point is that, for those 27 years, I have left out one piece of the puzzle, and entirely on purpose… medical treatment, and specifically, medication.

When I was younger, meaning around age 7 or 8, I first went on medication for ADHD. Like many kids in the 70s, I was put on Ritalin (Methylphenidate Hydrochloride) to help keep me under control. It worked amazing well in areas of focus and information retention, as well as getting good grades. What I hated about it was the person it made me; moody, angry, sullen, withdrawn, introverted, and isolated. I hated the latter elements so much that I was willing to do battle against the very benefits it provided. Over three cycles of my school life (elementary school, junior high and then in my first years at college) I used Ritalin. Each time, the same things happened. My grades and performance improved, but I became a raging tool in the process. Ultimately, I decided to just live life without the meds, because I didn’t want to be “that guy”, even if “that guy” could focus and be extremely effective.

Fast forward to today. As a part of playing with “The Hours”, investigating issues such as expectational debt, looking at my time commitments, my energy levels, where I choose to focus my time, and how it ultimately gets distributed, the tester in me decided it was time to do an even deeper dive. Enough with the immediate and superficial; let’s look at the past 20 years of my career! I spelled a lot of that out in my posts about meandering through 20 years of software testing, but I realized there was a lot I was leaving out. Not deliberately, but because I wasn’t willing to face what it meant to examine it at the time. Many of my career choices, the activities I participate in, all of the ups and the downs and the very way that I like to work (as a lone tester), all make sense when you put one phrase in context with all of it: Untreated Adult ADHD.

So what’s made me decide to do something about this now? I have three people indirectly to thank for planting this seed in my head and convincing me to act on it. Those three people are Merlin Mann, Scott Hanselman and Iris Classon. Merlin, as many of you may well realize, figures into lot of the things I talk about, because he’s where I heard about a lot of this stuff first (Expectational Debt deserves to be a service mark of Merlin Mann as far as I’m concerned ;) ). In one of the earlier Back to Work podcasts, he talked very directly and specifically about his own challenges with Adult ADHD and years of not treating it, and finally deciding to treat it. Scott Hanselman, in addition to being a vocal tech pundit, has also been quite vocal about his own challenges and issues with diabetes, and the fact that he’s been willing to put it out there for everyone to see first hand. He said he could have hid it, but why? Finally, it was on Scott’s podcast with Iris and her openly discussing her challenges with ADHD as a child and as an adult that made me decide “there’s no reason for me to hide behind it any more.” Besides, if I do hide behind it, it has to be the world's worst kept secret.

So today, I made the first steps into the fray of this. My primary physician just made the referral to the psychiatry department so that I can get this underway. Am I nervous? A little. At the same time, the tester in me would never forgive myself if I didn’t at least explore this avenue of who I am and if I can do something about it. It may turn out that I’m actually fine, and that I’m making much ado about nothing. If that’s the case, then I’ll have other avenues to explore. If I am diagnosed, there are a lot more varieties of treatment today compared to three decades ago. Also, this time, I’m not the sullen kid resenting the fact that I’m “different”, and wishing beyond hope that I could just make it go away. Instead, I now have the opportunity to actually look at this for what it is, and potentially change how I interact with my own brain. In a way, I’m excited about that. Perhaps there are benefits to being older, wiser and a bit world weary. Because I'm all of those, I’m willing to take it for what it is, and deal with it non-judgmentally, with open consideration as to where the road may lead. Like all good testers should :).

Virtually Speaking: A Meandering Walk Through Twenty Years of Software Testing

In 2001, I stepped away from the only tech company I'd ever worked for, and recalled with amazement that a company that, when I started working with in 1991 had 300 people, when I left they had more than 30,000 people working for them, and had grown to be one of the dominant tech companies in the world (and very briefly, they were THE most valuable company in the world). I joked with people for years that, if I could go back in time and redo anything, there was no question what it would be... sell every share of Cisco stock I owned on March 24th, 2000! Alas, that was not meant to be, but even with the resulting decline, we had enough shares saved up that we could effectively, at the time I had the most shares, lived off the proceeds and had enough money to replace my income for five years. Not enough to retire, by any means (and nor would I want to) but enough that I was open to experimenting and trying different things without too much stress of losing everything.

Connectix counts as trying a different thing. In some ways, I was still a tester, but in others I definitely wasn't. I was hired on as an Applications Engineer. I wasn't entirely clear as to what that meant, and truth be told, if you asked five different people what it meant, they'd give you five different answers. In a way, I was a senior tester with direct communication to big accounts, which also put me in a position to be a consultant to customers as a top level support rep. It made for an interesting mix of work, and I enjoyed working with both the Quality Assurance team and with the support team. for the first time in my career, I had an office I could call home, and a team that would come in and discuss the challenges they were facing, and I would either offer advice or try to see if I could replicate their results and try to find ways to solve the problems they found. Sometimes I was very successful at this. Other times, not so much.


One of the most interesting experiences I got to be part of was the official Microsoft Certification process for Virtual PC for Windows. At the time, Windows was just on the verge of releasing Windows XP, and I and a couple of other people in the company got flown up to Redmond to get trained on the new operating systems from an IT and a testing perspective. It was one of the few testing specific trainings I would actually receive in my career up to that point. Additionally, I was given the responsibility to help get Virtual PC certified so that it would have the Windows XP Compatibility logo. To do this, I was periodically flown up to Redmond over a period of several months and worked on site with Microsoft engineers to test various applications. Many of them were simple things to test, but many of them had unique challenges and proved difficult to virtualize (and a few of them, which were specifically created for adaptive users, we had to challenge their findings and state that the applications we were testing made no sense to be run in a virtualized environment, so why were we having to test them?).


A good friend of mine worked for Microsoft at the time, and it was fun to head up and talk with her when I was there, and as I explained what I was doing with the applications I was working on, she told me what was actually happening... "Microsoft is sizing your company up. It's a good bet they want to acquire you! You might want to consider where near Redmond you'd like to live!" Interestingly enough, that would prove to be true, but not for awhile.


2001 was a year of intense transition in the tech field. It seemed no company was immune. Just about everyone went through some kind of "tech sickness" and shed people for various reasons. Connectix was no different. September 11th happened while I was there, and I remember arriving to work early that morning, and my co-worker Sheri told me a plane had crashed into the World Trade Center. I thought it was some idiot joyriding in  a Cessna. I went to my lab, turned on the radio... and sat motionless for three hours trying to take it all in. As I heard some noise outside the lab, I came out and saw everyone gathered around a TV on a  cart, and we all sat dumbfounded at what we were seeing. We all knew that somehow, the world had just changed. We didn't entirely understand how much, but we would soon.


One of my most pleasurable memories of the time at Connectix was managing the user forums and helping to answer questions where I could. In many of the forums, there was a guy who was just phenomenal. the crazy things this guy would do with Virtual machines was just, well, awe inspiring. I talked with our management team and said "we have to get this guy on board!" After some additional inquiry and communication, we discovered he was in Australia, and was just barely 21 years old! Still, I lobbied hard to get him out here and onto the company payroll, and fortunately, most of the management team agreed, the kid was a genius, and was a welcome addition to the team. Within a short time, we were paired up as a duo of Application Engineers.


January 29th, 2002 started like a normal day, and it was as I was getting things ready for the morning when our HR director asked me if I could come in for a meeting really quickly. I said sure, and I walked into our main conference room. Slowly more people would come into the room, and as I noticed that each person seemed to be from a different organization, a sinking feeling hit me. Something's up, and I don't think it's going to be good. A few minutes later, our CEO walked into the room and said "I'm not going to keep you in suspense. This is a lay-off."


It was a first for me. I've been underemployed at various times in my life, and I've been in positions where I was able to make a jump from one spot to another, but this was the first time in my working life, ever, where I'd actually been laid off. As I looked at the room full of people, there were some good people in that list, some surprising people, but often, that's how it works. People get fired for under performing a lot, but in layoff circumstances even good people get cut. I'd been lucky over the previous fifteen years, I guess it was just my turn. Still, getting laid off felt like getting the wind knocked out of me, and it was happening at a time when the pendulum had decidedly swung from boom time to bust. I was not relishing the thought of being unemployed in a down economy.


I would spend the next three months working feverishly to try and find a new job. I interviewed with a lot of old friends, and went to a variety of job interviews. Just a year ago, I was a hot commodity and could take my pick of where I wanted to work. Now, however, I found it very difficult to get an interview anywhere, and  most of the interviews ended at the first round. Not enough experience, too little automation experience, no knowledge of industry standard tools, no college degree, I didn't have five years programming experience with J2EE (hey now, J2EE hadn't even been OUT for five years, are you KIDDING ME?!!).


Still, I kept looking and one of my friends got me an interview with Synaptics, a company known for making touch devices to go into laptops, as well as various devices that were being used on products that were being developed for a new generation of devices called Ipod's and smart phones. I figured "hey, I'm a tester, I can test anything!" Maybe. Then again, maybe not, but you'll have to wait until tomorrow for for me to tell that part of the story.


So, what pearls of wisdom did I get from this experience?

- Some of the best "testers" I had the pleasure to work with were the customer support engineers. They had a clear line into the real pain that our customers were feeling, and they helped articulate it in a way that we could all understand and boil down to the issues we should be focusing on.

- Being a top level support person helps you to start thinking on your feet really fast, and sometimes the ability to talk someone of a ledge is more important than having an immediate fix. Customers appreciate candor, and if you can't promise them a fix, tell them that.

- Sometimes you have to question another company as to why they picked what they did to be a representation of your product, and yes, even the mighty Microsoft has to be told from time to time that their recommendations and matrix doesn't make sense in some cases.

- Some people joked with me that, had I not lobbied so hard to get the Whiz Kid from Australia out to work with us, I'd still have a job there (LOL!). Well, no, I doubt it, and frankly, if I had it all to do over again, I'd have made the same recommendation. I'm proud to have championed him coming here, and in some ways I like to believe I have some credit in having come to the U.S. and making a name in the Virtual Server space (if you don't know who I'm talking about, do some Google searching and you should be able to figure it out ;) ). The point is, there's a very real chance that someone is going to come along and show you up. You can either act defensively and block their opportunities, or let the chips fall where they may and let the talent rise to the occasion. In this case, that's exactly what happened, and he deserved it :).

- Microsoft ultimately did purchase Connectix, and the organization was absorbed into Microsoft. Those who were retained were (mostly) moved up to Redmond. In this sense, it was a blessing that I didn't have to make that decision, as it would have been tremendously unpopular with my wife and children. Sometimes things happen for a reason, and we have to accept that, even if at the time, those happenings don't appear to make any logical sense.

- It's easy to get discouraged when you lose a job, and to that effect, it's critical to keep a cushion in your savings account that can help you absorb such a blow. I was fortunate in that I had plenty to keep us afloat for a very long while if necessary, but I certainly didn't want to burn through it. Still, if it did turn out to be a lengthy spell of not working, we had the emergency funds in place that we could roll with it. From that experience, if its at all possible, do whatever it takes to gather together three to six months of emergency savings, enough to replace your income for that period of time. It makes a world of diference when you interview. It will help stave off desperation.

This finishes off the first decade. I hope you'll join me for Decade Number Two starting tomorrow :).

10 Years on a Rocket Ride: A Meandering Walk Through Twenty Years of Software Testing

For the first three years of working with Cisco Systems, I had a peripheral relationship to software testing. It was something that I did, but it wasn't my primary responsibility. Mostly, I focused on maintaining a lab to keep the people in Release Engineering happy, and as far as I was concerned, for the most part, that meant working for and helping make sure that the infrastructure to test builds was working, and so that customer problems could be investigated.


I knew who the software development engineers were. They were the ones who wrote the actual code that went into the images. I definitely knew who the micro-coders were, as they were the ones writing the code that went on the interface boards. I knew who the software engineers were that worked on the release engineering side, but I didn't make the connection that they were software testers until considerably later. Why? Well, first off, there was nothing in their title that led me to believe they were testers. All of them were "Software Engineers". The "Testers", i.e. those who were officially titled as such, all worked with hardware, and for the most part, they were responsible for rework of the PCB's and making sure they worked.


I think for me, this idea of being a tester has been bred into me from years of hearing about testing of physical products, and was driven home by the old Hanes Underwear commercials and the "Inspected by #12" commercials. I know I'm really showing my age by that reference, but what I mean to say is that I looked at the group doing testing as the group that was physically testing the assembly line, those physically inspecting boards and electronics. I didn't look at the idea of their being a difference between software development and software test until I met a new hire at the time named "Chuck". Chuck was the first guy on the team to clue me in to the fact that what he did was software testing. I met Chuck because he was one of the Release Engineering team new hires who was willing to roll up his sleeves and help with designing the next hardware testing lab to go online. Because of this, we worked closely together, and as we talked more, I got to understand his role in the company and why he was hired. His phrase has been a hallmark of mine for almost 20 years... "I was hired because I like to break things!"


This was the first time I heard about this kind of approach. I had heard of the testers checking to make sure that boards worked, but the thought of actually deliberately being destructive hadn't occurred to me. One of the ways that this was manifested (and very clearly) was when one of the Release Engineers wanted to get some error output for debugging purposes, but they weren't sure how to do it. Chuck smiled, pulled out a couple of paper clips, and went over to where an AUI cable was plugged in (yes, I remember when Ethernet was too thick to fit into an RJ-45 connector :) ), and jammed the paper clips into the AUI Connector. He then walked over to the console window and lo and behold, errors!


This was a whole new idea to me, that software testing could be, well, negative, and aggressive, and have a touch of "weird science" to it. Because of this, and the fact that Chuck and I had a lot in common outside of work (music, video games, spicy food, etc.) I got to spend a lot of time talking with Chuck, and Chuck introduced me to the world of software testing. It was in this world I started to understand that Release Engineering was more than build engineers, that every software engineer that worked for release engineering but wasn't specifically a build engineer was in fact a software tester. Technical software testers, engineering grade software testers, able to code in C and C++ software testers, but still software testers. Through Chuck I got to see more of how the bug tracking system worked and the back and forth between the software developers and the release engineering group (of testers) and what I saw surprised me. There was a bit of a rivalry going on there, and there was a bit of back and forth with each bug. Chuck taught me a number of idioms that would be familiar to many testers; throwing over the wall, the dividing line, us vs. them, breaking things for fun and profit, and the all encompassing "wow, that's interesting... can you do it again?"


As Cisco kept growing exponentially each year, more and more testers were joining the team. Around 1993, an initiative was undertaken to help Cisco manage its immense growth, and at the same time, work to secure contracts in the broader marketplace, especially Europe. This initiative was called ISO 9001, and it touched on every part of the organization. As part of this change., the original Release Engineering group was split into three area. The first was the build group, and it would in a sense stand alone from this point going forward. The second group was Development Test, and the third was Product Test. This was the first time that Test as a group in the software realm was codified and made explicit, and it was around this time that I had to decide which group I would support (actually, it wasn't so much "make a choice" as it was that we had three administrators, and it made sense to have a point of contact for each group. Since Chuck was now part of Development Test, I decided to be the point of contact for that group, and with it, I started to work more closely with a core team that was now specifically labeled as Development Test and people who now, for the first time, were called "Dev-Test Engineers".


As the growth kept escalating within Cisco, we still had the problem of too much work and not enough people, no matter how fast we hired, so a lot of the manual testing tasks were offered to me, and I accepted them. Over time, a number of the Dev Test team (which was now swelling with the ranks of Manufacturing "Testers" who made the switch over to Engineering) and I felt that it made sense to have me be more directly involved with this group. As had happened a couple of years before, this DevTest crew went to bat for me, and asked if I could be moved into the group as a Dev Test Engineer. The manager for the Dev Test team liked what I was doing, and made it happen. Remember, I'm a kid with no tech training, no CS or EE degree, and no experience with "testing" outside of what I'd picked up from this group. Still, the crew that was there felt I'd be able to do a good job on the team, so in 1994, I was re-assigned to the Development Test group as a junior Dev Test Engineer.


In many ways, the following six years would be opportunities for me to learn more about testing from the Cisco perspective, to work with various groups and responsibilities (Enhanced Online Insertion and Removal, Performance Testing, Stress Testing, Negative Testing, and a bit of Automated Testing using the Tcl/Tk language and toolkit). I have to admit I was never really good on the programming end, but I did strive to get better at it. Cisco supported testers and engineers in getting further education, and through that support I went and completed a UNIX Programming Certificate through UC Santa Cruz. I also went back to Mission College in Santa Clara during these years to focus on and develop some better Computer Science chops. To that end, I decided it was time to bite the bullet and dive into an area that I was woefully deficient in, and that was mathematics. I went in and took classes starting with first semester College Algebra, and worked my way through over the next several semesters through  Pre-Calculus and Trigonometry (about two years worth of total classes), until I completed first semester Calculus with a B. Make no mistake, I considered that one of the greatest academic achievements of my life at that point :). I also did a number of "Direct Study" projects because what I was working on at Cisco was more advanced than what I would be able to take classes for at Mission. This two year period helped me greatly in filling in a lot of general education requirements that I hadn't taken in my five year stint at DVC so many years earlier. Cisco also sponsored several training brown bags and official product trainings, and I attended a bunch of those, but there was very little in the way of official tester training offered. We tended to fend for ourselves and collaborate together to improve our craft.


During the six years that I was directly testing, I worked on big teams that were pushing out full platforms like the 7500 and 7200 routers, the Catalyst 5000 switch, and the PIX firewall, as well as in much smaller groups (or even by myself) on projects like the CiscoWorks Network Management platform, and the NetFlow FlowCollector & FlowAnalyzer. I finished up my tenure at Cisco working with the Content Management group and working on the Cisco Cache Engine and Content Switching team.


One of the things I can say for certain about the Cisco experience was the focus on documentation. Test plans, project plans, test scripts, etc. were the order of the day, and the more detailed, the better. I cannot count how many times I went int to present test plans and then being told that there was "not enough detail" in the plans. Looking back, I really wish I had the presence of mind to say "detail for what purpose?!" But alas, I wasn't at that level of focus or understanding.


There is no denying the fact that the growth of both the physical company and the growth in their stock price had a big effect on my staying as long as I did. It had its ups and downs, but through the 90s it always came back bigger and more valuable than ever. Cisco's stock had jumped so much in value that it allowed in, in one fell swoop, to exercise options, sell off and pay the taxes necessary, and net enough cash to pay off all of my debts by the middle of 1995. Ten years of debt management came to an end, and with it, I could now sell off my option shares and bank the rest, which I did religiously for the next five years. In 1999, my family was now me, my wife and two young children and with the shares I had saved, I had enough to sell and buy a house with. I bought most of it up front, but took a small mortgage because I didn't want to have to sell ALL of my share to buy the house. To say that Cisco's stock had been very good to me in the 90s would be a tremendous understatement.


Of course, no good thing goes on forever, or as a Chinese proverb well puts it "no tree grows to Heaven". In 2000, I saw the signs of change coming; many of the perks were being restrained for the company, one which had been enjoying a screaming growth curve for a decade. My commute for years had been long and, well, hellish, but it was worth it while the stock was rocketing upward. As it started to come down back to earth, and the value of my shares were coming more in line with a new reality (and for the first time, future shares were well underwater) I started to question whether or not it made sense to keep commuting so long and being away from my family for so many hours. The Golden Handcuffs were less appealing, and I was getting offers from other places to go and see if I'd be a good fit for them. One of these companies was Connectix, located in San Mateo (just ten miles from my house) and the thought of being able to do what I did closer to home really appealed to me. Thus, after ten years, I decided it was time to get off the rocket ride and bid farewell to Cisco. A lot of the old timers were sad to see me go, and I remember well a number of people who told me that "I helped make this Company", and that meant a lot to me.


So what did I learn from this time and interaction?

- I learned that there was a distinction between software development and software testing, regardless of the labels applied and the titles used. Developers are developers, and testers are testers, and while the organization can try to foster a different culture, the groups know the difference.


- I had some great interactions with development managers and individual developers that helped me make my bugs more focused and meaningful, and help me look at what I was really trying to solve. I also learned that a priority to me was not necessarily a priority to development. I also learned that having a high "Junked" bug count was the worst indictment a tester could have (whether this was meant to be the case or not, I did whatever it took to make sure my bugs would not be junked).


- I discovered that a lot of projects made sense to have a test team, and others made sense to have just one tester. As a Lone Tester, there were skills I had to step up and develop because I couldn't rely on other testers to fill in the cracks.


- The World Wide Web was the best friend of a tester if you knew where to look. three cheers for dejanews (look it up for those of you who weren't there ;); it was basically the webified version of NNTP newsgroups).


- Cem Kaner's book "Testing Computer Software" would become a good friend, but alas, one I wished I'd read more carefully and completely. Still, with the areas I did read, I did well.


Coming from Cisco, I had the world at my feet and the ability to do just about anything I wanted to do. In a boom economy, you can do things like that. In a bust economy, though, one quickly discovers one may not be as good or as talented as they have led themselves to believe. Needless to say, 2002 would give me my first understanding of this... but I'm getting ahead of myself ;).

Learning Ropes and Making Tradeoffs: A Meandering Walk Through Twenty Years of Software Testing

When I found myself working at Cisco Systems in 1991, I found myself working with a fascinating mix of very eclectic people. Release Engineering was the group that I would be working with specifically, but because I was actually burning images into EEPROMS, I was actually considered a contractor working for Manufacturing. Manufacturing was in one of the three buildings and when we say manufacturing, we really mean assembly. We sourced various parts from other companies and we had a group of people that actually assembled them. In addition to programming EEPROMS on both an individual level and on a much larger level with seriously big machines that could burn 8 sets of EEPROMS at a time (64 total), I felt like I was living in the world of The Jetsons.


I also had the chance during these early days to get two different visions of testing. In the Manufacturing side of the company, testing was synonymous with hardware rework. Everyone would go through and work at their stations checking boards using oscilloscopes and determining if the electronic pathways were working right. If they weren't they were able to drop in resistors and wires and fix the problems. these were the classic "testers", so in many ways, I felt like that wasn't something I'd be capable of doing. In Release Engineering, though, there was much less hardware rework and much more talk about protocols and interfaces and throttling and other things that has less to do with physical hardware tweaking and much more to do with playing around with the console and sending commands.

An early, and exciting, interaction came when I met my good friend Shannah, who I still communicate with to this day :). Shannah was a release engineer, and she also spent a lot of her time managing the "testing lab". At first, I thought that this was going to be another place where people reworked boards, but when I came in, I was surprised to see that it was racks of equipment and a lot of cables branching out to various computers. Words like Ethernet, Token Ring, FDDI and X.25 were used, and I saw a bank of big white square boxes that, from my time working in the manufacturing area here and there, I realized was the flagship product of Cisco, the AGS+.  As I looked around at the various patch panels and the systems that were on both sides of the room (Sun SPARC 2 workstations, a couple of VAX/VMS servers, various HP-UX systems, plus several variations of PCs and Macintosh systems, I made a mental jump that would help me immensely... this place looks like a recording studio! Not in the sense of the mixing board and tape machines, but in the mass of cables going from machine to machine and having patch panels there to help you route the signals where you wanted to have them go. Now THAT I could understand!

Over the next several months I would do what they needed to have me do so that I could get images burned and released, and to help me also keep track of what was going on, I had my little DEC terminal replaced with what was to me at the time one of the coolest things I'd ever seen. I was given a 21" NCD, which was effectively a graphical UNIX terminal. It allowed me to use X Windows and spawn terminal windows on several machines, give me access to various tools that let me see how I could access this wild thing called Email, and most amazing of all (to me), use a tool called XRN that allowed me to access this insanely wild world of information called "newsgroups".

Another fact that I was not entirely aware of, but would come to discover soon enough, was that Cisco was on  a growth curve that was, to put it quite simply, insane. From the time that I worked there, from March 1991 until February 2001, the company would grow by 100% or more each year, and sometime by much more than that. The net result was that there was a lot of work that had to be done and not enough people to do it. There was no question that I was not at the time qualified in the slightest to be interviewed for a permanent position with the company, but since I  came in as a temp, I could easily be applied to any and all "grunt work" jobs that others either didn't have the time for or found less than tasteful to do. As for me, I was just happy to be able to work steadily, and for more money than I'd ever made up to that point. The staggering sum? $8.00 per hour, plus overtime if I worked it, and double time if I worked it. For several months, I really had the ability to do as much as I could stand, and I could be rewarded nicely for doing it (nice is relative here, remember; as a musician, outside of gigs, I'd made maybe a little better than minimum wage).

The time on the EEPROM programmer was limited; I could only burn one set of images at a time reliably, and since they were connected by a serial connection, it meant that an average image would take a half an hour to burn. This gave me a lot of time to go and help Shannah with the build out of the testing lab in our building, and then to do more build outs for several more labs that were to come on line within the next several months. Setting up the racks, building the PC's, loading the racks, and stringing all of the cables through the wire ladders was actually a lot of fun. It was physical work, and it was very tangible. When a lab was ready, it was obvious how much went into to putting it together. Of course, all of this equipment had to be maintained, and had to be "tested" to make sure that everything was running as it should. To that end, I started to learn how to "telnet" to the various systems console ports and issue commands from my NCD terminal. It felt so high tech and space age. Later I'd realize that, outside of the Cisco specific routers and terminal servers, I was working with what was considered at the time "low end gear", but to me, I felt like I'd been given a shot at being some kind of "mad scientist".

After ten months, several lab build outs, lots of cable wiring, and more beta software images than I could count, I had made friends with a number of the release engineering team, and they all went to bat for me to get me hired on full time. They felt that I'd done a really good job keeping the labs in shape, and that if I were to be hired on full time, I should be the junior Lab Administrator, along with some others that would be hired to help manage the workload. They realized there was more to do than I could reasonably do even if I worked 14 hours a day (and some days, I  did).

The year that was my break through into the tech world was also a year that was to "crater" the music scene that I was a part of. All this time, I was making money, paying off debt, financing a new but very modest car, and putting money towards getting to that next level. 1991 was known for many things, but in the music industry, it was known as "the year Nirvana changed everything". Truth be told, Nirvana wasn't the change so much as the over-saturation of hair metal ballads was. I'll make no bones about it, I loved being a glam performer. I loved being outrageous, being larger than life, putting on a show, and looking somewhat off the wall. In 1991, al that changed. If you were still wearing make-up and big hair then, you were a relic. If you sang about good times and played sleazy grooves, you were also a relic. Grunge was the order of the day, and it was a time of adapt or die. Industrial was also becoming more mainstream with ultra heavy beat that you could dance to as well as rock out to, and truthfully, this appealed to me more than Grunge did.

My band morphed into a semi combination of Grunge and Industrial, where I deliberately lowered my voice to less of a high tenor and more of a high baritone. It sounded forced, and while musically it was interesting, I was having a lot less fun doing it. Line-up changes were inevitable, people came and went, and finally, in the late summer of 1992, my band mates decided that they wanted to move to Los Angeles and seek the record deal and go for it all. For the first time in ten years, I found myself in a strange situation. First, I found myself in a situation where I actually had something to lose. Second, would I want to:
-  go and drop everything
- lose all of what I'd learned and understood
- to go to a market where my new found skills didn't apply
- and start all over with the debt load that I had (which had actually increased with the money I was making)
- so I could maybe get a record deal in a scene I didn't recognize anymore and play a music I wasn't really enthusiastic about playing
- and lose the connection with the fans that actually supported us all these years in the area where we'd made our mark, i.e. San Francisco?

Even with all of that, it was the most agonizing decision I had ever made up to that point in my life. How do you effectively drop nearly ten years of your life?! Was this company I was working for really all that? It took me some time to come to some simple conclusions:

1. I was in debt up to my eyeballs, and were I to go down to LA, I would have to carry all of that with me.

2. The scene I was part of had changed, and I was enjoying it a lot less than I had two years previously.

3. In just the 18 months I'd worked at Cisco Systems, I'd seen the company grow from around 300 people to close to 1,200 people, with new offices opening up on the east coast and other places.

4. I started to pay attention to a little number called "stock options" and ESPP shares, and looked at the stock price. It was doubling every year, and the stocks themselves were splitting just about every year. I did the math and realized that, if the current trend held, I could conceivably work my way out of debt in two years. I had no idea if I'd ever be able to do that if I left and went to LA, even if we did get the big record deal. We'd had a chance to see many of our friends who did get record deals and we saw the truth about their financial situations. They were dire. Yes, they'd had some fame, but they were also broke and deeply in debt. I decided I just didn't want to live like that any longer.

Thus it was in those late summer months of 1992 that I decided it was time to make a change, and let the band I'd worked on for so many years go their own way, and I wished them the best of luck. From there, I decided it was time to put my head into overdrive and see what this tech world really was all about. I would play with other bands over the next couple of years, but really and truly, that magic period where I was "all in" for music had ended, and the prospects of getting married, having a family and exploring some other goals in life took center stage.

So what had I learned during these couple of years?

- If you are lucky enough to find a company that has more work than what it can reasonably get done, don't be afraid to volunteer for grunt details. Sure, it's not glamorous work, but in many ways, you can learn a lot about the systems from a holistic standpoint, and get to see what all the moving parts can do.

- Even the best and most accomplished engineers don't know everything about the systems they work with. You can be a valuable source of information about what the product is doing in  a significantly complex arrangement.

- We had a gathering every week with our customers that came to our training sessions called "Beer and Cookies" and I'd walk around and get to know our customers and see what they were doing, where they worked, and what they were experiencing. Again, because of my years as a musician, I'd learned how to go about and chat with people and do some "promotion". I decided to use some of those skills in this setting, but rather than promote Cisco (let's face it, they were already customers, there was no point in my doing that) I listened to what problems they were having (and there were many of them, to be sure). I would then try to go back to the labs we had and see if I could set something up similar to what they were describing and see if I could make it do the same thing.

- Release Engineering was, for all practical purposes, the group that built the software to be released to the public. It was also the software testing group. It took me a while to figure that out, but figure it out I did. Most of the people I was working for and with, the ones who were my strongest allies in helping me get hired, were testers.

I began to self identify as a software tester as well, since I was supporting and helping them do their work. In a short period of time, I would be given the opportunity to see what being a tester, for real and for full time, was all about. I'd also see what being strapped to a rocket ride for 10 years can do to a person, for good and, perhaps, not so good.

A Prequel, of Sorts :): A Meandering Walk Through Twenty Years of Software Testing

Well, I thought there might be some amused interest at my post of my "former rock and roll self" in yesterday's blog post, but I did not expect the volume of response that I did get (on Twitter and Facebook, as well as emailed and personal comments). Some people wanted to know what led me to this point and how I traded in rock and roll for software testing. The trade in happens later, so I won't be talking about that very much here, but the lead up actually has a fair amount of amusing and interesting details that I don't think I've ever touched on before, or at least, not directly, so for those interested...

One cannot start a discussion with me about my early life, childhood and teenage years without a very simple detail being put out there, so I'm going to start with it. I have ADHD, and by some accounts also have mild spectrum disorder. I'm aware of all of this, I've dealt with it in various ways over the years, and have managed to be medication free since 1988. I mention this for one reason. My personality is such that I am easily distracted. "Ooh, Shiney!" has my name written all over it :). There was also one tell-tale anti-pattern that is still with me today, and that is what I call "The Obsessive Fixation". I am not content to dabble in something. If I get involved in anything, I go all in, and I often exhaust the knowledge, trivia, minutiae and peoples' patience the way a forest fire consume all available fuel (and air) that surrounds it.

I've had many obsessions over the years. My first that I can pinpoint was dinosaurs. By the second grade, I knew the timeline and taxonomy of just about every dinosaur known to the western world (at least those known in 1974-1975). Likewise, by the end of 2nd grade, it had run its course, and I was done with it. I still enjoy reading about and seeing shows and stories about dinosaurs, but nothing like the level I did when I was that age.

Over the years, I could fill in tons of "year long obsessions" that dotted my youth.

- 3rd grade it was American History and the Revolutionary War (hey, it was 1976, it shouldn't be too hard to see why ;) )
- 4th Grade it was Chemistry
- 5th Grade it was the band KISS
- 6th grade it was playing Soccer (what the rest of you lot outside of the U.S. call Futbol ;) )
- 7th grade it was performing in a repertory group and singing in chorus at school
- 8th grade it was playing guitar
- 9th grade it was martial arts
- 10th grade it was skiing
- 11th grade it was photography
- 12th grade it was bodybuilding  and modeling.

Also, as an undercurrent and continued "obsession" was an interest in music that crossed just about every known genre, from Classical to Punk Rock, from Funk to Metal, from The Beatles to The Jam, from the English Beat to the Sisters of Mercy, from Black Sabbath to Black Flag.

Each one of these things was not just an "interest", it was an all consuming passion, and in each case, I actually did something with each of them. Many of them had natural barriers of price, proximity or availability for me to really get too far into them, and most of them, after they had run their course, I was done and went onto something else.

In a way, that all changed my first year in college. When I met some other musicians, I thought it would be fun to form a band, and just have a lark at being a musician. I realized that performing in repertory theater as a kid, having learned how to play guitar a little (and bass as well) plus having sung in chorus, and my experience working as a teenage model for a little bit (don't make too much of that, I spent way more money to support that pursuit than I ever made :) ), I felt I could help develop and guide a band to where we could play some gigs.



I expected this would be a short lived obsession like so many others, but that was not to be the case. I spent almost ten years working to develop my skills as a musician and the marketing skills to get a band out in the scene and perform. Being a musician certainly had its perks. It also had some tremendous drawbacks. I was planning to spend two years at a community college and then move on to a University someplace. Due to my all consuming focus to make it in my various bands, I took a job delivering pizzas at night and on weekends, and practiced in the afternoons, which left morning hours the only time to take classes. My unit load went from 15 units, to 9 units to 6 units, and a two year stay drifted into almost five years, most of which was classes that were all over the map.

I took classes in Astronomy, Philosophy, Creative Writing, Music Theory, a BASIC programming class, which I failed spectacularly in, but I got an A in the Computer Lab itself, because I was able to sit with other people and talk about the problems they were having and help them think through the problem they were having... I thought this was just because I liked being social. Instead, I think it's my earliest inclination that showed I was genuinely interested in asking questions of a product, not so much an interest in making the product myself.

I took a studio recording and arranging class twice (because you could do that and get full credit due to the projects being unique each semester) and one of the things I did was help rewire the control room with my at the time keyboard player, who was an electronics buff. The point is, I took classes that interested me, but I did a lousy job putting together a cohesive transcript with good grades. Oh, and somehow, I tried taking multiple math classes, and ended up dropping each and every one of them. Not one of my prouder admissions, but it just wasn't where my head was at the time. In a later post I'll tell you about going back and taking almost nothing but Math classes for two years, but that's at least ten years from this period.

During this time, I had very kindly parents who let me live at home, go to school, work where I could. After the job delivering pizzas stopped making sense because I ran three cars into the ground in the process, I started working as a housekeeper, which again meant I went to school Tuesday and Thursday in the mornings, worked the other days, practiced in the afternoons with the bands I was playing with at the time, and did shows whenever and wherever we could.

The truth is, my bands were my obsession, and all of the work I was doing with them (developing songs, producing recordings, booking shows, marketing shows, developing a stage image, getting us radio play, getting us interviews in small music zines, etc.) THAT was everything I was "living for" up to that point. I was also racking up a considerable amount of debt in the process, because I believed that "big break" was just around the corner, and if I just financed "this PA system, this demo tape, this ad campaign, this [fill in the blank]", we'd get over that hump.

Finally, when I was 22, after several years of plugging away and being on what I felt was the crux of something big, I told my parents I couldn't play half way anymore, I had to go "all in". It was now or never. With that, I dropped out of school completely, moved out of my parents place and in with my guitar player and some other friends so we could share rent, and I devoted 100% of my attention to making the band a success. This was in the Fall of 1990.

It took me three months to come to a startling conclusion... I wasn't going to survive. I owed too much money, and I wasn't making enough performing or cleaning houses to make ends meet. I was officially living below the poverty line, and while that might sound dramatic and glamorous for awhile, it was really difficult and frustrating. The band was doing well enough for the time and the scene, and it definitely looked promising, but I needed something more stable, and I had to dig myself out of the debt hole that I'd made for myself. The question was, how?

The answer came from my drummer. He was working with a tech company in their sales department (he had the gift of gab, and out of all of us, was the one doing financially the best). Needless to say, I listened when he suggested I do what he did, which was go to a temp agency and just start developing some work experience, anywhere. Short of my being willing to start my own cleaning business and buy all my own gear to do it (which I really didn't have the funds to do, my credit already having been maxed out, and the thought of running a cleaning business the rest of my life really didn't appeal to me) I figured, OK, I really don't have anything to lose by trying this. The temp agency I picked was the same one that Taz, our drummer, used, and it was them that sent me to Cisco Systems.

So what can we make from this rather strange litany?

- From an early age, the idea of exploration and learning, of asking questions, and obsessing over trivia and minutiae proved to be an exceptional training ground for developing the kind of mind that serves a software tester well. Not just "what happened or how it happened, but why did it happen?"

- I had the chance to look at knowledge from many different areas, and in truth not from a prescribed map. In short, I took classes that interested me, and they brought lots of things to my attention that a more "focused" curriculum would never have helped me tune into.

- I discovered that I liked to solve problems through experience and learn how things worked, but I wasn't really all that excited about building it from the ground up. I just didn't have that kind of patience (and even today, I fight hard to work though stuff like that).

- I discovered that I liked to write, but not in the prescribed manner of the term paper requirements of the time. I wrote a lot of bad poetry (and really, most lyrics are truly bad poetry (LOL!)), but I also discovered writing from many different perspectives. I discovered philosophy for the first time, and found I liked talking about different ways of looking at the world.

- I discovered that a lot of skills come to the fore when you try to create a band. You are not just a singer or a songwriter or a performer. You are also an entrepreneur. You are a salesman. You are a technician. You are a logistics manager. You are a marketeer. You are a financial analyst. You are a designer. More than anything else, you are a creator, someone who has developed a brand, and put it out into the marketplace, and you have adapted and worked with it to help leverage the greatest level of success possible.

In March of 1991, it really looked like we were almost there as a band, and if I could just get my foot in the door of a job that could help me pay off some of my debts, and help me get some more money so that we could open up some more lines of credit, then we'd be able to make the big push and really get into the marketplace, get signed, put out a real record, get out and tour the country, and we'd be on our way. That was the plan, in any event... but as John Lennon so keenly put it "Life is what happens when you are busy making other plans", and life seemed to have some twists and turns I hadn't yet considered :).

More on that to come.

First Steps: A Meandering Walk Through Twenty Years of Software Testing

I have been thinking about this because, in a way, I officially entered full time employment in the tech industry on January 20th, 1992. It was on that day that I officially became employee number 876 at a company called Cisco Systems. I actually came into Cisco Systems entirely by accident 10 months earlier. At that time, Cisco Systems has about 300 people in their Menlo Park office setting, one that spanned three modest two story buildings between O'Brien and Adams Drive, across the street was Costaño Elementary School in East Palo Alto, and just up the road was open fields and the roadway leading to the Dumbarton Bridge.


I'm serious when I say that I was sent there by accident... well, sent there for another purpose. At the time, I was not looking to get a job in the tech industry. I was just looking for a job, any job, to help me keep from being a literally starving musician. My extent of being tech savvy in those days was that I used a Macintosh that I could find at a Kinko's somewhere in San Francisco (and yes, I learned the schedules of all of them) and would rent the systems by the hour, and would keep all of my stuff on three floppy disks that I kept in my bag. I'd edit my files, make my flyers, and keep up to date my simple database that consisted of a mailing list for sending band flyers (made in Dbase III, for anyone who can remember back that far ;) ) and likewise maintained on any PC that I could rent from a Kinko's as well.


I had never heard of the Internet, I didn't have email, I'd never touched a UNIX box... in short, I was probably the least qualified person to ever be sent to work at a tech company imaginable. For that matter, I wasn't sent there to be a tech guy at all. I was sent there because their engineering library was a complete shambles; all of their printed materials were in piles and boxes and no one could find anything. I was sent there to help with that because I told the temp agency two things. The first was that I'd spent the past three years working as a housekeeper. The second was that I had to work someplace where my having long hair wouldn't be an issue. For the record, and just for a little bit of fun, this was what I looked like for my night time job.

Now seriously, would you hire this guy ;)?

A project they thought was going to take an entire week, I was able to finish in two days. Note, this had less to do with it being terribly easy, but because I knew how to clean, and I knew how to organize stuff. They could have sent me home, but since they still had me for three days, they asked who could use some temp resources. The Release Engineering manager had a need for someone to help them with producing beta images for customers. Sounds technical, huh? well, not really. It required someone being willing to sit down and erase Electrically Erasable Programmable Read-Only Memory chips (EEPROMS). I did this by sitting next to a heavily shielded UV machine with a tray that I loaded up with EEPROMS that had been used previously, blasting them with UV light, and then loading them into a machine and checking that they were clean. After doing that, I would then sit in front of a DEC terminal that was connected to a Sun Server of some kind, and I would enter in a cryptic string of words and I would hit Enter. This cryptic string caused an image to be sent to the machine, and that image would be burned into the 8 EEPROMS I loaded up. If all went well and the EEPROMS reached the end of the process with all green lights, I could then eject the EEPROMS from the machine, load them into the small CGS router that I had sitting on the desk, power it up, and issue it five commands:


Show the version number
Show the configuration
Show the interfaces
Configure the console (and make a change)
Confirm that the change took place

If all this worked, I would then unplug these EEPROMS, put them in a static resistant foam, put them in a box and carry them to people in release engineering and they would do more stuff with these images.


At the end of the remaining three days, and the end of the week, the release engineering manager asked me if I'd be interested in doing what I was just doing for a little while longer. They were getting ready for a "big release", and would need to get a bunch of images into the hands of "beta customers", and it was a time consuming process. I said "sure", and with that, my one week "filing and cleaning" gig became one where I would be burning images into EEPROMs and making sure they were ready to be shipped to beta customers who would deploy them in their routers on their networks.


Thus, on March 8th, 1991, I officially started working as a temp for the release engineering team. In other words, March 8th, 1991, would be the day I would be able to say that I first became a software tester :).

I'll post tomorrow on what it was like working in that environment and my recollections of what software testing, to my eyes, was like in 1991.