Why is this so difficult? Well any tester knows how an infinite number of test cases can be made for even a trivial application. As a result, the tester is left making decisions as to which tests are most likely to expose problems given available resources. There isn’t an obvious “done” reached, but instead have to decide when it is “good enough”.

Coming from a development background, I’m used to the sometimes ambiguous art of estimating time. I contend that estimating testing is a much more difficult task, a factor of how difficult it was for the developer to estimate the same particular tasks and the skill of that developer.

With experience and exposure one can learn some of the traits and characteristics that help improve estimate accuracy. For example, I have to touch the project a few times and know the development team to establish how confident I am in the project and that tests against the project meets an appropriate level.

Focus on documenting discoveries, explaining concerns without bias, and conveying the value of what you offer. Ultimately management needs to trust your judgement and your ability to say testing is done.

Over ten years ago when I was studying to be a music teacher, many of the classes had part of the curriculum set aside on communicating the value of music education to parents, principals, and superintendents. This was about the time when school districts started targeting fine arts and music programs.

Software testers run into the same problem, where there isn’t an obvious and tangible benefit to management so they are easily under-valued. In software development this manifests itself in the form of developing quality software, most easily measured by practices and scheduled time for unit testing, refactoring, and the like.

The inherent problem is asymmetrical information, that both parties do not have the same information available to make decisions. To complicate matters, everyone has their own priorities and agenda. What one person perceives as critically important might not matter a bit to another person in the same company, or even the same department.

But how do you communicate value? How do you explain that something is important, especially if it doesn’t have a tangable, physical value to the other party?

Is it going to guarantee success in the future? Is it going to make things better somehow? Can you prove or quantify that?

I believe the solution is education. Make the time to explain the value. Use facts and resist the temptation to exaggerate or incorporate personal bias as they often have secondary consequences such as loss of credibility or unrealistic expectations.

Understand that education alone doesn’t guarantee that they will agree with you, but at least you can be sure that you supplied the information to make a business decision based on facts.

I am left thinking there is a connection to the health and auto insurance problem, but will save that for another day.

It’s something I knew would happen some day. That a person that has impacted my life so much would leave, but the range of emotions is something I wasn’t prepared for.

The day is darker, the colors are less vibrant, the happiness is less so. Mix that with the desire to be a better person, to spend life doing exactly what you want, and a desire to make the world better.

You will be missed, but your impact is undeniable. Thank you for everything you have done for the world and for me. You are my catalyst.

The Visionary

This is typically the leader you will see in a start-up. They are the brain that started this thing in the first place, saw a gap in the industry and decided to fill it. They aren’t necessarily a founder of the company, but it is more common due to the vested interest in success. It’s this attachment and knowing the business at it’s core that allows them to be creative and come up with ideas.

The Cruise Controller

This is typically the leader with a business background that knows how to run any business. They can do everything necessary to run the day to day, from mergers and acquisitions to globalization, but they are not visionaries, at least not so far as we are concerned.

As an exercise, let’s look and see if we can figure what kind of leaders are driving companies.

Take the recently ousted CEO at Yahoo! Carol Bartz, who was very much a cruise controller. She made no revolutionary ideas or offerings at Yahoo!, simply shuffled things around and continued with business as usual. While she did run a global company, this alone does not allow a company to stay competitive, and as a result they dropped in user base and relevance.

To continue with Yahoo!, consider their founders. They were visionaries to the core, seeing opportunity and seizing it. The problem is that visionaries alone can’t cut it either. Visionaries often lack the discipline or patience required to run a business day to day. To complicate things, most visionaries are driven by a hunger that is usually satisfied when a company reaches some level of success, thus are typically short lived.

HP, Kodak, and Microsoft are some more examples of companies being run by cruise controllers. In their day, they were leading the pack and arguably changed the world. Today they focus on mergers and acquisitions, shuffling around resources and changing for the sake of change.

For all of these companies you can almost visibly see what kind of leadership they had throughout their history. Did they grow and offer new products, or did they just rename what they had and change some pricing? Are they leading the pack or following what everyone else does?

This isn’t to say these companies don’t have any visionaries. Ultimately some entity decides what direction a company goes, and possibly that entity could undervalue or underestimate the value of either side. They are competing forces in a way, risk vs stability, thinking vs doing, new vs refine.

I challenge you to look at any company and see if you can figure out what kind of leadership it is influenced by. Then, go back in that company’s history and see if you spot the shifts in leadership. Ultimately, I believe you need both in balance in order to exist and be relevant in the long run, and that without both you either can’t grow or lose relevance.

One avenue I would like to research more is a possible connection between this visionary / cruise controller concept and the notion in software development that suggests a developer is typically more proficient as either a starter, an implementer, or a finisher.

“How do I decide what to use?”

Now this can translate to what programming language, what persistent data storage, what framework, what third party tools or plugins to name a few. These questions sometimes get labeled under “architecture” or “design”, but really these are decisions we all have to make everyday.

So how do I decide?

Well there isn’t a simple answer. What? It’s simple you say? Use the best tool for the job? I’ve heard this before and it can technically be accurate, but I’m not sure people know how to determine this.

Consider existing expertise. Are you working on this alone or with a team? Is the “best tool for the job” already an existing expertise? If not, there is a risk associated with using the unknown, which could lead project delays or other delivery failures.

Consider the true requirements. Depending on the requirements, a specific tool or technology may be better suited. With frameworks do you need simple common components and methods or a robust MVC framework? With persistent data storage, do you need heavy relational queries or simple data storage?

Consider the project’s inherent risks. Is there a tight deadline? Is management really behind the project’s success? Is there a reasonably qualified team ready to make this happen? I don’t claim having to consider these things is ideal, however if your primary goal is to successfully launch (and it better be), then I suggest you take these things into consideration.

Consider maintenance. How long will this project be expected to run? What kind of functionality are they expecting in the future? What resources (manpower, expertise, money) will be available to work on this when it goes into maintenance mode? This can be a slippery slope, and could even be categorized as premature optimization, but keep in mind project success is not only defined by what launches on day one.

In the end, it is all about risk and what you can do to reduce chance of failure. Every one of the aspects I’ve asked you to consider can either make a project more or less risky. Now I’m not suggesting always play it safe, or always look for the easiest route. I am suggesting that you put thought into it and know how these decisions impact the project’s risk.

We’ve looked at some of the ways on HOW to decide, but one could spend as much effort asking WHEN. Maybe we will look at that next.

What does matter is software development, the crazy misconceptions about it, and it’s future.

Stay tuned…

Step 1: I always start by figuring out who the leaders of the industry are. Admittedly this practice is a bit subjective since it relies on exposure and opinion, but I find it quite useful. When I studied music, this involved learning who the best musicians were. I don’t mean the Kenny G’s of the world that only succeeded because of fat marketing budgets and computer synthesizers, but the “down and dirty” people that make it work every day in the real world. In the testing world, I used blogs as an extremely effective way to get this information since it gave me instant access to their thoughts and beliefs. I used conferences in conjunction with my findings from the blogs to fine tune my understanding since face-to-face contact helps pull back the curtains in many cases.

Step 2: I continue by getting a grasp of the glossary used in the industry, an understanding of the vocabulary used so I can absorb what these people are talking about. I underestimated this task the first few times, but have since learned the intricacies involved. Everyone has an opinion or interpretation of what they think X means, and certainly everyone is entitled to this. The difficulty comes with extremely vocal professionals in the industry with differing opinions who sometimes push their definitions to purposely promote themselves or discredit others. Personally, I use the results of step 1 to help narrow this down to relevant and concise information.

Step 3: I finish with an evaluation of the information that was collected, followed by implementation and use; the literal “doing” what was learned and applying what can be applied when applicable. This is my favorite part because it is like putting in the last few pieces of the puzzle and finally seeing the picture. Equally exciting for me is the realization that this is only a small part of the full puzzle, that there is a whole set of untapped leaders and resources that weren’t even on my radar before. Who inspired the leaders? What resources do they use? Why can’t method X or technology Y be applied?

In my experience, these steps can and should be repeated. Why? The next time through the steps I narrow in on who inspires the leaders and their peers, which inevitably points to a new ring of resources and updates to the glossary. I typically go through the steps 2 or 3 times depending on the depth of the industry, how much I really need to know about the industry, and how much effort I put in the previous time(s).  One observation that I find interesting is when reaching the top tier (and yes, there is such a thing despite the sometimes circular pattern of inspiration), many leaders are inspired by people outside of the industry.  This could be a writer, an artist, someone in a related field, or sometimes it is just plain random.  Why?  My guess is people that apply their life experiences and external inspiration to their current industry make it something bigger and better than it was before.  

Another variation is to select a segment of the industry to focus on when repeating the steps.  For example, I spent 3 rounds learning software testing and feel I have a basic understanding of the industry’s key players and concepts.  My next step is to narrow in on exploratory testing; who the key players are, what they do, who inspires them, how do they define things, etc.

One trap I keep falling into is not letting go of less-relevant information. This is a weakness of mine because I used to think all information is useful to some degree, even if it only teaches me what not to do or give perspective on how others exist.  In retrospect, spending time on the wrong information does not add enough value to my self-learning experience.  Learning something that may or may not provide value pulls me away from the time and opportunity to learn something I know to be relevant and useful.  I also risk absorbing bad information which can lead me off my intended learning path.  Am I saying to ignore this kind of information?  No, I simply say it’s a risk that should have some thought behind it.  

A true life example of this is the list of RSS feeds that I check every day.  I was cleaning them out today and found I had about 15 feeds from sources I no longer consider accurate or relevant.  These 15 feeds didn’t necessarily stop me from reading the other, more relevant RSS feeds, but it did stop me from spending more of my time absorbing, learning, and implementing relevant information.

I’ve used this approach successfully in several industries including: music performance, software development, dog training, software methodologies, software testing, and even cooking. Does it work for everyone?   Does everyone do this already, perhaps unknowingly part of the human learning process?  Not sure, honestly, but I know that while writing this I realized how much of my self-learning experience was summed up by these steps.  I also found myself wanting to write more about this topic, my observations and experiences, and how so many of these concepts transcend every industry I have used it in, but in the end it is just about learning something new.

One might say that person is struggling to find their niche or lacks career focus. I call it my life experiences that make me uniquely qualified: testing software, testing life, and testing myself.

I expose myself as someone with no formal training or certification, an apprentice with no master. That either makes me a fool, or absolutely qualified to tell this story from the beginning with no bias.

And so begins this story, hopefully not to play out like some soap opera or stale documentary, but instead to share what I see, from my eyes, with my mind, and with my 34 years of experience testing life.