"The Effects"

Patterns are funny things. Sometimes it is so easy to jump to silly conclusions because we notice the obvious even if we know there might be valid explanations for them.

Take for example patterns of behaviour. Here are a few things that I see on a regular basis:

• The Developer Effect - The software application always works as expected on a Developer's computer.
• The IT Effect - Any weird or unexpected computer behaviour (e.g. unable to print) will suddenly start to work correctly when you call an IT Helpdesk person over and they are looking over your shoulder as you retry the steps.
• The QA Effect - Any normally working system will suddenly stop working as expected when a Tester starts to look at something.
  

The "QA Effect" was my most recent addition to this list. A programmer sent me a link to a web site today and when I followed the link from the email message a new browser window appeared with the message: "We're sorry - an error has occurred. It has been logged and will be attended to shortly."

Ha ha. Is that Murphy's Law, or what?

I wonder how many other "Effects" there are in this industry? Write back a Comment to this Blog entry to let me know if you've come across any other immediate patterns. I'd be very interested to hear them.

Cheers!

I Know What I'm Doing!

This will sound weird but I had a strange realisation the other day. I thought to myself: "I know what I'm doing!"

Okay, this didn't just come up out of the blue and I wasn't practicing some sort of confidence-building exercise. It all started when I happened to notice a bug in the software I was testing and I decided not to report it.

What?! But you're a tester, man! Report the bugs you find!

Ah, well, yes, I plan to. But you see, I was busy at that particular moment thinking about something else, and I didn't want to distract myself by following up on a different thread that might make me lose my train of thought. To justify not reporting it I had to reflect for a moment as to how likely it would be that I would find the bug again. I had absolute confidence that I would find the bug again, so I simply forgot about it and went back to what I was working on.

I think it was later that night that the event started to settle in my mind and it started to make synapse connections with other memories in my brain. One particular memory came to me from my teenage years, some 20 years ago.

I recall one time when I was at a party and was talking to some of my older sister's friends. Coincidentally enough I think the topic of conversation was (creepy, crawly) bugs. There was this one guy who said that he was playing a video game in his home when he saw a millipede scurry across the floor. He said that his reaction was to pause for a moment, smile, and then keep playing his game. Someone asked him why he didn't just drop what he was doing and catch the icky bug right away?

His reply? He said that he knew those bugs and that he would easily find it later and take care of it then. He wasn't worried, so he didn't let it interrupt his game since there was no pressing need to take care of it right away.

I remembered that story for a long time and I always thought that if I ever saw an undesired bug I would simply take care of it then and there. Too many variables in life to let opportunities pass you by.

And so I have. For many years, I have always taken care of the bugs that I've found right away - both the creepy crawly kind, and the software kind.

So then, what happened this time? Why did I let a software bug go and not report it right away?

I realised that I was absolutely confident that I would find that bug again, and since there was no immediate need to take care of it, I let it go for the time being.

Sure enough, I got around to testing that particular area of the application and I had the opportunity to properly focus on the bug and report it with sufficient detail (it was a tricky one). I felt really great about it too.

When you do Exploratory Testing you are faced with the reality that none of your tests are pre-scripted. Exploratory Testing is kind of like what improvisation is to acting: there's no script. It certainly doesn't mean that the Improv people don't know how to act. In fact, it's quite the opposite. They are very talented actors. They just happen to know how to react to the circumstances that arise and can adapt to it with style.

I must confess that I've still been a bit nervous about Exploratory Testing. It doesn't help that I am bombarded with doubt by every other tester in the profession still doing it the traditional way: What if you miss something? How can you be sure of coverage? How do you know when to stop testing? and so on.

Well, I now *know* that I know what I'm doing. If I can totally forget about a bug and then stumble upon it again at a later date, then there must be something to this "improvisation" stuff after all.

Do you feel like the Stanford Bear?

I was asked just now if I felt like the Stanford Bear. I had to laugh, because sometimes I do.

What's the Stanford Bear, you ask? That's a good question. I'll tell you what I know..

I heard a story recently of an introductory computer class at Stanford University where the Teaching Assistants were so tired of answering the same questions over and over again that they programmed a machine to answer all the commonly asked questions. They added voice-recognition software to it and packaged it up nicely in a large teddy bear that sat on a shelf at one end of the class. Now, when a student had a problem or question, the TA's wouldn't help the student unless they knew that they had gone to the bear first. This relieved much of the workload from the TA's so that they could focus on the problems that really required their attention.

I'll admit that I don't know how much truth there is in this story. I spent some time scanning the internet and I couldn't find any pages to corroborate the tale. I'd like to think that it's true though.

True or not, it got me to wondering as to whether or not you could program something to give out canned answers on Software Testing to commonly asked questions.

I don't think that you could do it so that it would recognise every possible context and provide you with an appropriate response for every situation. (While a cool idea, let's be realistic here!) However, within a particular context - say revolving around the particular testing procedures for a particular class or industry, I'd think this might be do-able.

Better yet, I think it might be cool to program a Testing Bear that's hooked up to a central database somewhere. That way, people could program the Bear to answer all the common questions within their context, but then people all over the world would have access to the same questions and answers.

Now that might be something! Hmm.

Software Testing is more like Fencing

I got into a discussion with my colleague at work the other day about Martial Arts and Fencing. He asked me if they were similar and I said that based on my experiences with both that I didn't think so.

Martial Arts is about the harmony between mind and body. Different Martial Arts stress different skills and techniques but there is always the spiritual side, and with your mind focussed and at peace you can do almost anything. I remember some of my first Kung Fu lessons as a teenager when I was taught that my first reaction to a fight situation should always be to find a quick way out of it. Fighting should only be the last resort.

Fencing, on the other hand, is like both a Science and an Art. I remember learning the blocks (the "parries"), the lunges, and all the other technical maneuvers, but I also remember that when I was in an actual duel my mind almost forgot everything and I went with my instincts. You see, an actual duel is *much* faster than you can imagine. You almost don't have time to think or you're toast. With lots and lots of practice the technical moves become part of your instincts and then you become better at fencing.

So what about Software Testing? Despite the fact that some people amicably refer to it as a Martial Art, I don't see the spiritual side of it. When I see a bad application my first reaction isn't to run away. ;-) I dive in and go with my instincts. And project schedules are almost always faster than you'd like them to be.

With lots and lots of practice, my testing techniques have become part of my gut reaction now, so I usually make my own luck when it comes to dealing with bad programs.

Perhaps Quality Assurance is more like Martial Arts. You need a belief system to keep you motivated when you do *real* QA. You need to believe that you can eliminate the defects, the inefficiencies and the variances from the development process by applying certain methods and models.

I don't believe that. Not for a moment. We could stand here and talk about how we're going to do something or we could just do it and tweak things as we go along. Me? Let's dive in and do the best we can because time is running out. =)

En garde!

A bit about Software Testing Certifications

Recently I was asked about my "certification". Here, more or less, is the response that I gave. I thought I'd note it here in case I was asked again.

Back in June 2002 I received my certification through the American Society for Quality (ASQ) as a "Software Quality Engineer". While I may use the term "Certified Software Quality Engineer" in the US, due to Canadian laws, I may only refer to myself as an ASQ-CSQE here in Canada.

Here is a link where you can find out more information about this certification: http://www.asq.org/certification/software-quality-engineer/

Of particular interest to you may be the Requirements for this certification and the Body of Knowledge covered by it. (FYI: Note that "Software Testing" is merely a subset of section "VI - Software Verification and Validation" to the "QA" folk. Many people use "QA" and "Testing" interchangeably, but to me they are quite different.)

This ASQ certification covers many different aspects of Software Quality throughout a Software organisation (i.e. from defining Quality in the Business Goals, through to the Engineering methods, Requirements, Development, Testing, and Configuration Management). The exam itself was interesting in that many of the questions were designed in such a way as to demonstrate application of knowledge. (So people without experience who can memorise well may not pass the exam.) I spent about 4 years preparing for the ASQ exam by applying the principles, techniques and advice from the reading list materials into my regular work duties.

Why did I get this certification? It was applicable to what I was doing at the time.

Over the last few years I have changed my focus from Quality Assurance to Software Testing.

Most of my energy is currently on the Software Testing profession and I am an active member of the Association for Software Testing (AST). You can find out more about the AST at their web site: http://www.associationforsoftwaretesting.com/

I find it interesting that my ASQ involvement has provided me with a good knowledge of Quality-related issues that are, in general, quite difficult and complex to apply and manage on a day-to-day basis in a Software organisation. By contrast, the AST aims to provide us with the knowledge and support we need to be effective Software Testing practitioners. (i.e. the former is laden with bureaucracy and paperwork while the latter aims to make us useful employees.)

There are several Software Testing certifications available to the public, but none of them are particularly meaningful right now. The AST does not yet have any certification program, but we have discussed the development of a certification that would be based on demonstration of skill and not just one's ability to memorise the terms and definitions from an assigned reading list (which is what all of the current Testing certifications are based upon).

In the past, when I have interviewed candidates for Tester positions, I have used "Testing certifications" as an indicator that someone has more than a passing interest in this profession. Unfortunately, I can confirm to you that the certification itself has absolutely *no correlation* to testing ability whatsoever.

Too bad.

Team Leads need to be Potion Masters

Okay, maybe it's because I just read the latest Harry Potter book, but in discussing Test Team leadership recently with someone, I used this as an analogy.

I'm always surprised to meet people who think that the stages of team development (i.e. "Forming, Storming, Norming, and Performing") are some kind of kiddie joke or else they may not have heard of them at all. That's too bad. I believe that anyone who's serious about team leadership/management should take these stages very seriously.

If you are not prepared to recognise the moments when your team members start to pick each other apart or are challenging and questioning everything you do (in a bad way), then your team will never grow into a constructive, cohesive whole. As a team lead, you need to detect the poisons and provide the antidotes.

Most importantly of all, if you at least notice the poisons, but if you don't know what to do then ASK FOR HELP!! I'm tired of meeting people with EGOs so large that it prevents them from asking for help from others. ("Pride" is one of the Seven Deadly Sins, isn't it?) If you had seen someone fall but didn't know what to do you would call an emergency number (like "911"), wouldn't you? After all, that would be the right thing to do.

So why is it different when it comes to team management? If you notice that your team is falling apart and you don't know what to do to make it better, ask for help.

The biggest problem that I've noticed in this industry is not the managers who don't ask for help though - it's the managers who don't even notice that there's a problem. I've seen many teams just completely fall apart because the team members picked each other apart by getting on each others' nerves right in front of an oblivious team lead/manager.

Perhaps there's only a certain type of person who makes a good manager. Perhaps there's something in the MBTI that correlates with the traits of a good leader or manager. Perhaps I'll have a chance to look into this some more in the near future. Something to think about.

Shego: The first thing that every villain needs is...

"The basic tools of the trade."

There's a kids show that I watch with my sons every now and then called Kim Possible. It's a smart, unoffending show that empowers youth to face their fears and foes in a creative and humourous way.

There was one episode where a villain (Sr. Senior, Jr.) was getting trained by another more-experienced villain (Shego, pronounced "She Go"). Shego started her lesson by asking Junior what's the first thing that every villain needs. The response got me to thinking about how I might answer that question if I were in a similar situation.

What are the "basic tools of the trade" for a Software Tester?

I think that in our case, we need to:

1. Arm/prepare ourselves with Testing Techniques that uncover bugs
2. Be able to effectively communicate our findings and testing information
3. Be able to identify Risks.

What else? I think those 3 are the most basic, and they don't cover things like attitude, motivation, or the ability to deal with stressful situations. You'd think that a Villain wouldn't ask for training in those, and I don't think a Tester would either.

I'd be curious to know if there are any additional "basic tools of the trade" that I've left out from my short list above. I tend to lean towards the "softer skills" during interviews and when assessing potential testers, but I'm not sure which one(s) are worth identifying as "Basic Tools". Many of the ones that I've been exploring are not "basic" -- they are more "intermediate" or "advanced."


Shego: "The second thing that every villain needs is a Plan."

Good advice. =)

Welcome to the Knowledge Age

Okay, maybe I'm splitting some hairs between "Information" and "Knowledge", but I'm choosing to define "information" as simply the summary or statement of the raw data itself (i.e. observed facts without opinion), and "knowledge" as providing you with the ability to make good use of the available data.

You can see some of this beginning to take shape right now. Blogs, like the one you are reading right now, are a key factor in helping us to interpret fact through opinion and personal experiences.

How do you know which car to purchase? Pick up the Lemonade Guide. Make an informed decision before you buy!

How do you know which company to work for? Research them first. There are many places to look.

How do you know which TV or Stereo to buy? DON'T start by asking the sales staff at your local electronics store. Start by asking your friends or family their preferences and experiences. If you can, check out some of web forums where they talk about their purchases.

If we're going to survive in this world, we're going to have to know how to make the right decisions. To do that, we're not only going to need access to timely information, but we're also going to need access to the risks involved in certain situations.

Want to travel abroad? Don't just look at the pretty brochures! Take into account the weather conditions, health risks and the political conditions. If you don't, you might get lucky and have a good time. If you're not so lucky, you might end up in a foreign hospital, jail or even dead.

Do you still want to let a coin flip make that decision for you?

We need more than just Information. We need to know how to process that information to help us make good, informed decisions. When we can do that, we will truly have "Progress".

I do believe that we are on the cusp of a new "Knowledge Age". The signs are appearing around us every day. Unfortunately, the capitalists and war mongers are also out there helping to drag us back into the Dark Ages. We can get through these challenging times if we're strong and help each other out. Not everything needs to be about who's right, who's wrong, and how you can make a fast buck. (Note that I don't think that making money to provide for yourself, your family, and/or to enjoy life is a bad thing. Making money solely to achieve power, prestige, or at the expense of other life is wrong in everybody's books.)

I've read enough Science Fiction stories to know that there are probably an infinite number of ways that we can make the Earth a really bad place to live. It's my planet too, so I'd like to think that we can make the best of it if we just work together.

Okay, so what's the connection to Software Testing? If we apply this idea to what we do, a good Software Tester provides information. Good, credible information is unbiased and reproducible (whenever possible). That doesn't excuse the Software Tester from their responsibility to provide additional opinions, alternatives, and risks that may not be apparent simply by looking at the testing information that we provide.

Testers are a part of the development team, and therefore a part of the overall decision-making process. If you don't care enough to play an active role in the decisions affecting product releases and the future of the company you work for, then you waive your right to complain if things don't turn out the way you think they should.

I've no patience for whiners. They shouldn't work in the Software Industry at all. Neither should scapegoat-hunters. Next time a problem arises at work, how will you react? What will your contribution be?

Welcome to the End of the Information Age

I remember having some discussions about 15 years ago about the Internet and what it was useful for. At the time I was still in University, and the Internet was primarily used to link together educational institutions and government agencies.

We didn't have the Windows operating systems that are so common (rampant?) today, so most of the applications we had were text/character based. Applications like "gopher" and "telnet" were used to navigate the various libraries and information sites on the 'net, and programs like "Pine" and "Elm" were popular for checking email from our Unix accounts.

For the most part, if you were in college or university and you needed to do research on some topic, the Internet was likely to provide you some limited access to information databases online. (Real libraries provided the really useful information though.. no shortcuts.) Other than that, email was very useful for trying to get a hold of authors and researchers anywhere in the world. (Cool!) That was it though. If you weren't into Newsgroups, then you probably had a life and never gave the Internet a second thought.

By the early 1990's the Mozilla web browser appeared on the scene (running on the X-Windows interface on our Unix accounts) and changed the way we viewed information forever. The gopher sites were slowly replaced by more flexible and visually-appealing web sites. By the mid-90's, commercial businesses were jumping on the HTML-bandwagon and starting to make use of the Internet to appeal to a slightly different market - the technologically-savvy! Email accounts were gaining in popularity, as graduating students started to expect these accounts as a standard part of their professional lives too.

Sometime before anyone really started to worry about the "Year 2000" (Y2K) problem, the Internet was already becoming the "Information Superhighway" and the World Wide Web was becoming the standard interface to that information.

With any advancement in Communication we usually have Progress. When information travels faster, we can work with it sooner. Just think about what the Telegraph, Telephone, Radio and Television did for the world. Now we have the Internet, and the world is a smaller place once more. We can watch News as it happens from anywhere in the world. We can research the latest papers, articles, journals, and theories. We can shop and start a business within a global market. We can be entertained, post our thoughts, send messages instantly to others, and more! The Internet is truly a rich, multi-media opportunity to express our ideas and share information with everyone on the planet.

There's just one problem. There's a lot of crap out there too. I don't just mean the obscene material that some people of little intelligence or low moral standards think we should know about... I'm talking about the poorly-researched, incomplete, often-misleading, assumption-driven, over-hyped, or just plain incorrect information that is passed off as "fact". If you don't know how to tell the good information from bad, then just remember this simple rule:

ALWAYS IDENTIFY THE REFERENCES AND CHECK THE SOURCES!

"Houston, we have a problem!"

So, now we find ourselves floundering in a sea of information, and we can't always tell the useful from the useless. Welcome to the end of the Information Age.

Just knowing the facts (true or otherwise) isn't going to help you. You have to know what to do with that information. You have to know what the assumptions were that the information was based upon. You have to know when the information you are reading is incomplete. You have to know how to separate the useful from the useless. You have to know how to act upon receiving the correct information. In essence, you have to know how to process the information into useful action.

Welcome to the beginning of the Knowledge Age.

Some incomplete thoughts...

There are a series of related ideas that I want to discuss, but I don't think I'll have the time to properly describe them here. I'll make a quick attempt to put some of my unpolished ideas down in upcoming blogs, but I'll have to save the clarity and completeness factors for a later date and/or forum.

As with all ideas, discussion helps me bring out the best arguments. If you have any ideas or comments to share, please do so with the functionality available through this blog mechanism.

Thanks. Cheers!

Use your BRAIN!

I bumped into an old colleague last week and found out that he's expecting his first child in a few months. He asked me if I had any advice for the delivery "experience".

I had to think about it for a minute, but then I recalled a lesson I learned before my first child was born.. useful advice that worked for me at the time, and advice that I continue to apply in other areas as well today.

Since you don't really know what will happen, you kind of need advice that will prepare you for just about any situation that might arise. In that case, use your BRAIN.

BRAIN is an acronym - a mnemonic for some heuristic advice. Here's what it stands for:

B = Be aware - of everything going on around you.
R = Know the Risks (Don't know them? Ask!)
A = What are the Alternatives?
I = What do your instincts tell you?
N = What if you say "No"?

There are times when you will find yourself alone in a situation where an important decision needs to be made. Don't forget to use your BRAIN.

Sometimes your heart tells you one thing and your head tells you something else. This handy little mnemonic should help you find a reasonable compromise between the two. It's worked for me.

New Tester's Hardware Research Tool -- eBay

Ever come across a piece of hardware in a lab (like a modem or network hub) and you don't know which power supply goes with it? If you can't find the spec sheet for it, you might be out of luck. Or are you?

I picked up an inkjet printer out of a junk pile last week. It looked like it was in good shape but it had no power supply. I checked the manufacturer's web site for some technical spec sheets and I found them, but they were useless when it came to telling me the exact specs of the power supply.

So I googled the web and I found a few hits on eBay. Why not? It's worth the look. Turns out it was my lucky day! Not only did I find the exact power supply for sale on eBay, but some really thorough sellers include close-up photographs of the power supplies too. Spankin! =)

I printed up a copy of the photographs and rummaged through a bunch of boxes of miscellaneous mice, power supplies, cables and other small parts. Bingo! I found the matching power supply. I brought it home, plugged it in and, presto, my kids now have a new inkjet printer all their own. (Of course, there's the added cost of the overly expensive inkjet cartridges, but considering the printer was free, I'll overlook that for now.)

Marketing Research - How to make your meetings work better

I got a phone call yesterday. I was contacted by a Marketing Research group that periodically holds Focus Groups on particular subjects in my town. I signed up with them a few years ago and I get a call from them maybe a few times a year, so it's not really a bother. (I like to contribute to research and data whenever I can.)

There are usually the pre-screen questions though to make sure that you are a part of their target group. Turns out that I didn't fit the profile they were looking for this time around (I'm a Generation-X, and they're looking for a Gen-Y), but I asked them the details of the Focus Group anyway. It was to be a 2-hour discussion forum on some topic and it pays $50.00.

Wow. That's cool. $50.00 for sitting around in a meeting room and talking for a few hours? I can do that. (Too bad I didn't qualify this time.. better luck next time.)

Hey, wait a minute!

How come when I sit in a Project status meeting for 2 hours at work I don't get $50 spending cash?!

How much more efficient do you think these status meetings would run if the Meeting Chairperson had to dole out cash for each attendee for each hour? I'm pretty sure that these meetings would run a lot quicker and be far more productive! ;-)

Maybe there's a lesson in there somewhere.

Interlude

I haven't forgotten about this blog.. I've just been crazy busy at work for the last month. We had a major software release at the end of March, followed shortly afterwards by a planned "hotfix" release to patch the last remaining things that we couldn't finish in time for the deadline. So between long work hours and spending my remaining waking hours with family, I've let this chill for a while.

That reminds me.. I think some of my friends called about 4 weeks ago.. I should probably get back to them.. maybe get out, go see a movie. I need some air.

I've got lots to write about here, so I'll probably be adding several entries over the next few weeks. One thing that I should mention is that one of my hard drives has also failed on my home computer. Just happens to be the one that has all my email on it. (That kinda sucks.) I'll be [carefully] taking the computer apart this weekend to see if I can recover the data before I replace the drive.

I actually unplugged the drive several weeks ago, so if I can go almost a month without retrieving my email, I think I can wait a few more days before I start writing entries. ;-)

Cheers! Write soon.

The Paradoxes of Software Development

When you've been working in Software Development for a while, you eventually wise up to the three important factors that drive any project: Time, Money, and Scope. (Sometimes people replace that third option with "Quality", but I think that the three of them together make up the three sides of a "Quality" triangle.)

They are certainly the three things that drive any Project Manager, although you sometimes hear them talk about it using different words:

1. Schedules, Milestones and Deadlines
2. Budgets, Resources, People, Equipment, Tools, Training, etc.
3. Features, Requirements, Work Breakdown Structure

When you start any project, you always desire lots of each of these. In reality, you are constrained in each. You can't have all the time in the world. You can't have all the people, tools, training, or equipment that you'd like. And someone is always trying to sneak in more features, but there are limits to what you can put into any software release if you ever want to get it out the door and make some money from it.

Consultants use these three factors (Time, Cost, and Scope) during contract negotiations. The experienced consultant will be able to take any two fixed factors and give you a practical estimate for the third.

So what are the paradoxes? These three factors are, but not for the reasons listed above so far.

Time

You never have enough time. Never. Live with it.

It's more than that though. When you are at work, your time is always interrupted. This is unfortunately unavoidable. It is the nature of Software Development that we miraculously create a complex masterpiece through a process of continuous interruption.

Interruptions come in different forms. Everybody expects to take bathroom and mealtime breaks. But what about the interruptions by email? What about when someone calls you on the telephone or shows up at your desk? Bam! There goes your train of thought!

Of course, it's not polite to yell at people to go away and leave you alone. (Although it may be very tempting with some people.) The reality is that, as a complex human activity, software development requires that a lot of people get the information they need to do their part of the project. Everybody has a part in creating information, so everyone has a responsibility to make sure that the information they know is passed onto the people who need it.

You could be on the verge of solving a complex problem that has eluded you for days, when all of a sudden a Project Manager shows up at your desk to ask you your opinion on the risks involved in making a change somewhere. Or it could be an impromptu meeting. Or a technical writer asking you to review some documentation that you have some familiarity with.

I knew a programmer once who said that he was far more productive when he worked at home for two reasons: (1) he didn't have to get up and leave the building whenever he needed to smoke (he could just smoke at his desk at home), and (2) no interruptions.

The problem of course is that when he does get back into the office, he will eventually be inundated with questions about the work that he did -- in order to pass that information onto the next person who needs it. He also eventually needed to collaborate with other programmers to understand the integration of his work with theirs.

Try as you might, you cannot make software in isolation forever. You may need to get away from others for a while to help you focus on a problem or goal, but you cannot stay away for long. You just can't.

Money

This is a funny one. Not everyone is immediately aware of the importance of the money available for a project until they try to get something and realise they can't. For example, it would be really cool if we could get this "super analyzer metrics-reporting database-query problem-solving automatic-tester all-in-one XML-friendly scriptable-API user-friendly reliable coffee-making appointment-remembering time-saving dry-cleaning fully-customizable easy-to-use tool" ... until they see the price tag.

Or worse, you realise that you can get some of the tools you need cheaply, but you don't have the time to spend figuring out how it can be integrated into your project or environment. Is there any way that we can hire a contract person (e.g. a high school or university student) to figure it out for us so that we can reap the benefits of the tool without actually spending any of that time figuring it out for ourselves?

What? No money in the budget for extra hires? But how can we meet the deadlines if we don't have the help/tools/equipment/training/whatever that we (think we) need?!

Start-up companies generally have a harder time with budgets and available finances than larger, more established, global organisations, but big companies have their share of money problems too.

The funny thing about needing money is that often you get it - but at a price! You will end up "owing" someone, in one way or another. Nothing comes free, and money is at the top of the list.

Many years ago, I had a terrible experience working for one company when we had a person leave our test team. I approached the Director of Development about when I could start hiring her replacement, but then he started giving me the run-around, talking about the "return on the value" of our test team, and that perhaps the funds allocated to the test team salary budget could be better reallocated to hire another programmer instead. After all, we would certainly be more productive with another programmer and one less tester, wouldn't we?

I quit a few months later. I have been extremely happy with my decision and never regretted it. That company no longer exists since it lost all of its customers a short time after I left.

Money is a tricky thing. It should never be placed in the hands of fools, because they will always do foolish things with it.

It's about more than just the Economics of the business though. "Time to Market" can have a BIG impact on the price of the Shares in your company (if it is a Publicly traded organisation). You don't meet the release deadline for a particular Quarter >> share prices drop >> No bonuses this year! In fact.. there might even be "restructuring" in the near future.

To do a great job, you may need more people, tools, training or equipment, but those things all cost money. You may or may not have money "in the budget" for these things. Getting those things may come at the expense of a lower salary or absence of financial bonuses. Not having those things may mean that you will miss the important deadline and cause your business to miss its Sales goals... which in turn mean lower salaries, no financial bonuses, or even layoffs.

Money. How do you want it?

Scope

It all starts innocently enough with the customer. This "customer" may take different forms depending on the industry you are working in.

You start with a list of features. These features are deemed to be the critical success indicators for the software if it is to be bought and used.

Software Development is a complex and iterative process whereby some really smart people take that feature list and break them down into hardware and software components from a particular technology. Suddenly that list of ten or so items, is now broken down into hundreds of smaller pieces that all need to work together in harmony to make up the features that the customers want.

Think of it this way: In Ancient Egypt, a Pharaoh once said: "Build me a Pyramid! I want a tomb of magnificent proportions that will leave a legacy for eons to come!" The Architects designed it, and then the Engineers built it.

Have you ever looked closely at a Pyramid? It's made up of thousands of stone cubes! Where did these stones come from? How did they get there? How did they put them together to make the finished product? What about the workers? How did they feed and clean up after thousands of slaves?

Thinking about some of these questions will begin to give you an idea of the orchestra at work in a software company to produce a product that the customer needs and will pay for.

But then a funny thing happens. Someone looks at the software. It might be a Product Manager, a Software Tester, or even the customer. And they discover something that isn't quite right. Sure, perhaps the big, important features are there, but the little details between them might be clunky, incomplete, or too complicated to make sense.

Uh oh. We need to make changes to the software.

And we keep "testing". And we keep discovering more "little things". And before you know it, that "critical list of ten features" that was broken down into hundreds of components is now tied together with thousands of little details!

It takes a keen mind to be able to keep all of these details in perspective of "the big picture". That is, does it make sense to make a particular change now, or should we put it off until the next release or version of the software?

I've met many testers who believe that every bug they find should be fixed right away. That's a foolish and narrow-minded perspective, in my opinion. I believe that if the problem is worth reporting, it should be worth fixing (whenever feasible), but each problem needs to be assessed for the risks involved and the priority or relevance for that particular release.

For example, I once tested a client-server application and found a bug that crashed both the client and server at the same time. (This is unusual because usually you only find bugs that affect one or the other.) In the Project Status Update meeting that week, I argued that we should NOT bother fixing the bug for that release. That is, even though it was a serious crash, I knew that no customer had ever reported the problem in the five years that the software was on the market. This led me to conclude that no one was in fact actually using that feature. So, I could only conclude that it would be a waste of time to fix a feature that no one was actually using.

Being able to keep things in perspective like this is what helps you to avoid one of the strongest Failure-factors in the business: "Scope Creep." Changing Requirements.

It's just a game sometimes. I've seen it many times. It goes something like this..

You ask the customer what they need to do their jobs. They tell you and you make the list. You come up with the requirements and double-check them with the customer to make sure it looks right. You make the software, work out the bugs, and release it to the customer for approval.

Now that the customer has the working software in front of them, the bar has been raised. "Oh well, it almost does what we need. It just needs these many more features, and then it will be perfect."

The smile falls from your face, but you go back and work to get these new features into the product. When you bring the software back to the customer, the bar has been raised again! "Well, it's almost perfect, but it still needs these features for it to actually work for us with the way we do things."

Just for the record, these are the kinds of customers that cause software companies to go out of business. More importantly, the Project Managers who don't recognise this situation and allow these scenarios to play out late in the development cycle are really the ones who cause the software companies to fail.

"Scope Creep" or "Feature Creep" simply refers to the changing of the requirements while the product is still in development. What may seem like a straightforward list of requirements at the outset may suddenly become conflicting requirements by the time you expect to release the software.

Changes may be subtle and sneak up on you in inconspicuous ways, or they may just hit you in the face like a closing door when you are looking the wrong way.

Getting a handle on Scope requires you to understand: (1) the Development Models (Life Cycles) used to provide the guidance in the way you build the software, (2) the customer and their appropriateness to help you achieve your desired results, and (3) the Requirements gathering process and the iterative nature required to truly flesh out the useful features from all the unnecessary "Bells and Whistles."

Scope. Feature list. You think you know what you need to do. You will be wrong every time. Software Development is a process whereby you usually engage on a journey with nothing more than a general sense of direction but no clear understanding of the final destination. That's the way it is.

Go to the ocean and learn to surf. Things will become clearer.

New Year's Revolution

I'm at an interesting crossroad in my career. Allow me to think out loud and recap a few things..

On the one hand, I have a formal Science education. I love Science. I got into it because of Physics. I loved the problem solving. However, I didn't see myself as a Lab rat for the rest of my life, despite the coolness factor.

Enter my second love: Teaching. I went to Teacher's College and became a High School Science teacher. Interesting thing about teaching is that you actually learn more about a subject than you ever did as a student. There's something about looking at a particular concept from many different perspectives to try and explain it to a variety of students with a range of skills and interests. I learned even more about Science and I loved it even more. However, the reality was that I needed a break from school so the timing was a bit off. I can always return to it later if I choose.

Somewhere in between all this, a hobby of mine (fooling around with computers, and software in particular) turned into something of a recurring job. I did the programmer thing for a few years. Did my time in Tech Support for almost a year, and then I fell into QA almost by accident. I liked Testing. It was somewhere in between the programmers and the customers, but there was something I couldn't quite put my finger on that kept me interested in it.

When I chose to not teach anymore, I decided to go back to QA & Software Testing. I didn't know what the difference was (between "QA" and "Testing") but I knew that: I enjoyed doing it, that I could do it, and that not a lot of people really wanted to do it. I spent about 6 years trying to figure it all out. Eventually I came to understand what Quality Assurance (QA) really was about and how different it was from Software Testing. At that moment, I chose to continue to pursue learning and doing Software Testing.

The years have passed, and I have become quite Senior in this field now. That means that I can be dropped in pretty much any situation now and have a reasonable chance of success (but more on that later). One of the problems when you reach this point though is that there aren't many people you can turn to when you have questions. As luck would have it, I stumbled across the right set of email discussion forums where all of the industry experts hang out and discuss ideas. These are some of the smartest and nicest people I have met in my life -- outside of the circle of Physicists I once knew who still ponder the mysteries of "Life, the Universe, and Everything in it" today.

I gotta say that being able to talk with some of these people is really cool! I don't think I've ever been this close to the cutting edge of creating a new profession and affecting an entire industry as I am today.

Here's my dilemma: I'm enjoying my work as a Tester too much, but the "teacher" side of me is aching to get out and spread the word! BUT.... to become a teacher here, it would mean either becoming a trainer/consultant of some kind or going into an educational institution of some kind (a university or college).

Going the independent consultant route involves risks that I'm not prepared to handle at this particular moment. I could do the consulting and training part, but I don't have the business skills I would need to keep myself busy. There's a recipe for disaster! So, until I find a partner who can help me with the marketing and finances side of things, I'll keep this one on the back-burner for a bit.

Going the educational institution route has it's own interesting problems too. If I wanted to teach at the local college, I could probably do that. There's not a lot of money in that though, so I don't know how long I would be able to keep it up. Teaching at the university has a great many attractive qualities. Just one thing: I don't have a Ph.D. Oh ya, I'd need one of those.

The funny thing is that I know exactly where I would go to get one (can you say the Florida Institute of Technology?), but there's a few things keeping me from packing up and doing that right now.

Okay, so fine. I have a few options, but I have relegated them for the time being in favour of staying where I am to see what else I can learn and help contribute to the Testing Profession as a "practitioner".

So, what now? I wrote an email to the Software-Testing mailing list a few days ago asking for a sense of direction. Maybe it was an unfair question to ask. Maybe it wasn't the right place to ask it. But I felt that I wanted to open myself up and see what kind of response I would get.

I got some good replies, but one of the best by far came from James Bach when he wrote:

We are headed toward a world that recognizes and respects testing as a skilled investigational activity, and is able to systematically describe and foster those skills.

• Can you list your testing skills?
• Can you demonstrate how to develop testing skills?
• Can you describe a model of the testing activity as you see it?
• Can you explain and defend your work without appeals to authority?
• Can you relate testing and testing skills to other established fields of intellectual work?

Let these questions, or others along the same vein, guide you. Anyway, they work for me. Please suggest others, if you want.

I like James. He makes me think. =)

I'm pretty sure that's why I love Testing so much. It really is the closest thing (for me) to Physics when it comes to the think-work required to do a good job of Testing. I've met so many drones in my career and only a few who ever gave testing a passing thought. But here, now, is the paradigm we are striving to communicate: to do a good job of testing, you have to use your head.

Imagine that!

Well, of course it's actually a bit more complex than that, and smarter people than me can explain it really well, but I'm content to just know what I'm doing right now.

This is it. The beginning of a movement that will change the way Software is developed forever. (Welcome to the Revolution!) Historians will look back at the early 2000's one day and try to piece together the events that led to the paradigms that affected future thinking on the subject of Software Development and Software Testing in particular.

That history - our future - isn't written yet. Someone's gotta make it happen. In the words of William Shakespeare:

All the world's a stage, And all the men and women merely players: They have their exits and their entrances; And one man in his time plays many parts..

This is my part and the curtain hasn't fallen yet. So I have some improvisation left to do.

At least I can use James' questions as a guide in the short-term.

Let's see where it takes me, shall we?