You know sometimes you just need to rant.  I was reminded of King Midas’ barber and Midas’ donkey ears today

From Wikipedia:

“Once Pan had the audacity to compare his music with that of Apollo, and to challenge Apollo, the god of the lyre, to a trial of skill (also see Marsyas). Tmolus, the mountain-god, was chosen as umpire. Pan blew on his pipes, and with his rustic melody gave great satisfaction to himself and his faithful follower, Midas, who happened to be present.

Then Apollo struck the strings of his lyre. Tmolus at once awarded the victory to Apollo, and all but Midas agreed with the judgment. He dissented, and questioned the justice of the award.

Apollo would not suffer such a depraved pair of ears any longer, and caused them to become the ears of a donkey.^[15] The myth is illustrated by two paintings "Apollo and Marsyas" by Palma il Giovane (1544-1628), one depicting the scene before, and one after the punishment.

Midas was mortified at this mishap. He attempted to hide his misfortune with an ample turban or headdress. But his hairdresser of course knew the secret. He was told not to mention it. He could not keep the secret; so he went out into the meadow, dug a hole in the ground, whispered the story into it, and covered the hole up. A thick bed of reeds sprang up in the meadow, and began whispering the story and saying "King Midas has a donkey's ears."

Today I feel like King Midas’ barber – I can’t keep this in any longer.

Something that really makes me cross is when so-called industry experts believe that they know better than you how to solve your problems.  You see it in response to questions in forums, you see it in people’s blogs, you hear it at conferences and you hear it in conversations.

An example:  I was at a conference and in the evening got into a conversation with one of the speakers.  This speaker (who I will not name) is well known in the testing world, has written articles and books, teaches and speaks and is well respected.  We talked a bit about generalities of testing and then got talking about what I was doing and his only retort was “I’ll give you my card, I would sort it out”.  How could he possibly know he could sort it out?  Why did he think he could do a better job than I could?  He didn’t know what the context was, the constraints or anything about the project.  The arrogance just stunned me and I couldn’t think of a suitable response. 

My particular problems are split into a number of categories:

1)      Those that are imposed as constraints on me from higher up.  Things like the project’s budget, company policy.  I can’t solve those, I have to live with them and make the best of them.

2)      Those that are caused by the project methodology.  The project uses a Prince 2-like methodology, which means that there are some things you just have to do.  Whether you think Prince 2 is good, bad or indifferent is irrelevant, as with any methodology, problems are caused by it.  Some I can work around, some I can’t.

3)      Those that are caused by people working on the project but not in the test team.  They have their own priorities, ways of working, constraints, etc.  Some of those may cause me problems.  Some I can resolve, some I can’t.

4)      Those that are caused by people within the test team.  These are totally within my control and I can work towards resolving them (e.g. skills gaps).

5)      Those that are caused by me.  Much as it pains me to admit it, I am not perfect and I cause some of my own problems.  I try to work towards self-improvement, but perfection is probably about 300 years away.

I am sure that I am not the only one with this set of problems.  I am glad there are problems; otherwise I would be out of a job!

I don’t believe that any one person can solve all of these problems for me.  I most definitely believe that anyone could come into the project with no knowledge of its history, culture, methods and sort out my problems.  If I had a free hand, had a lot of time and a lot of money I might, just might, be able to solve some of the problems this project has, but that is not going to happen.

I ask for help, advice, like most people.  I am not afraid to listen to people who have tried things and found them to work.  I have tried some of these methods, some have worked, some haven’t, but no-one, I repeat, no-one, could tell me how to sort out the problems I have.  

So my plea to the experts is “Don’t tell me you would know how to solve a problem, give me pointers to how I can solve the problem”

Finally, here is a counter-example to the one I gave above.

I spoke to Johanna Rothman at a conference and asked her a question which was related to the talk she had just given.  She did not give me the answer, nor tell me how to solve it.  What she did was ask me questions about the problem and made a couple of suggestions of how I might approach solving the problem.  It was wonderful, I was able to take that away and work on solving the problem myself.

Rant over. The reeds have finished their story and can now die.

I am so EXCITED!! We got a new version of the bug tracker yesterday to replace our 8 year old version.  The new version does so much more, it does things that previously I had to dump data out to Excel, it looks better – bliss! I have even spent my lunch break playing to see what else it will do for me.  

Yes, there have been a few teething problems, I managed to crash it once and some things have had to be tweaked, but I am so happy with it.

I know, I shouldn’t be so excited about a tool, but I can’t help it.  Boy, is my wife going to get so bored with me tonight when I tell her all the great things I can now do so much easier.

Can’t stop to write any more, got to go play with my new version….

I had a problem posting my last entry, it appears that copy and paste of a Word table doesn't work too well here.  It looked fine on preview, but not once it was in there. 

My only excuses are that it worked on my machine and I ran out of time to test it - Aaaargh, I am going back to my developer days!

Now re-posted, not as a table. 

In my last entry, Joe commented on me assigning emotions to bugs.  That got me thinking that sometimes we testers do assign characteristics to bugs which are, after all, inanimate.  However, just for fun, I tried to come up with the type of emotions that bugs might have if they could feel.  I am sure that others could improve on these and/or add more.

Acceptance             A bug that accepts it will be found.  Typically a bug that is obvious as soon as you login (or even one that prevents you from logging in!

Affection                 A bug that loves other bugs.  Some bugs are gregarious and like to live together, these are generally found all in one place

Alertness                A bug that is alert to being found.  It shifts its position so that just as you think you have it nailed down, it moves somewhere else.  Memory leaks are good examples.

Ambivalence          A bug that doesn’t care whether it is found.  Typically a bug that you come across by accident

Anger                      A bug that hits you whenever you get near it, e.g. the blue screen of death

Angst                      See Anxiety

Annoyance             A bug that gets cross when it is found and causes another bug to be created once fixed

Anticipation            A bug that expects to be found and looks forward to it.  Typically a bug that keeps showing up throughout the application

Anxiety                   A bug that worries about being found.  These bugs hide in the corner and have to be winkled out with specially designed tests

Apathy                    See Ambivalence

Awe                         A bug that is amazed you have found it.  It pops up with unusual error messages like “Error: This should never happen!”

Boredom                 A bug that just gets fed up with being there.  These bugs usually go away of their own volition in the next release

Calmness                A bug that can’t get you excited.  Typically, a cosmetic bug, such as a mis-spelling

Compassion            A bug that cares about you.  This type of bug gives you an indication of what the problem is with a sensible error message.

Confusion               A bug that is not sure whether it exists or not.  Typically this type of bug can cause endless arguments with developers

Contempt                A bug that really thinks testers are lowly creatures.  Usually manifests itself with incomprehensible techno-speak in the error message

Contentment          A bug that is happy with its lot, it likes being there.  Usually these bugs are difficult to eradicate as they just like being there.

Curiosity                 A bug that looks for different parts of the application to get into to see what sort of damage it can do there.  This type of bug is often due to a continual bad coding practice throughout the application

Depression             A bug that throws itself at you suicidally.  Normally found early on in the testing cycle

Desire                     A bug that finds testers incredibly attractive.  Every tester on the project keeps finding this bug, usually finds its way into the bug tracking system multiple times.

Disappointment      A bug that is disappointed you didn’t find it.  Usually shows itself in Live

Disgust                   A bug that finds testers disgusting.  Generally gives a supercilious error message

Doubt                      A bug that doubts its cause.  Could be one of a number of different reasons why this bug exists

Ecstasy                   A bug that is high on illegal substances.

Embarrassment      A bug that is embarrassed to be found.  Generally has error messages like “Sorry, you can’t do that”

Empathy                 A bug that feels for the tester.  Typically shows itself after you have had your morning coffee and never last thing at night

Emptiness               A bug that has no content.  This type of bug is where functionality is missing that should be there.

Enthusiasm             A bug that has to show itself spectacularly, typically a system crash

Envy                       A bug that wishes it could be like other bugs.  Typically this is a bug that looks serious, but in reality is only a minor problem

Fanaticism              A bug that goes round telling other bugs how to create mayhem.  Typically a comms bug that goes round multiple systems.

Fear                        A bug that fears being found.  A particularly difficult bug to find and has to be tempted out into the open

Frustration             A bug that wishes it could be a working system Tries hard to work, so only shows itself intermittently

Gratification           A bug not found until system in Live.  This is a happy bug has defeated all attempts to find it and has finally achieved its aim of thwarting you

Gratitude                A bug that thanks you for finding it.  When it is found it shows you the position of other bugs, so you get multiple bugs shown on one screen

Grief                       A bug that is inconsolable at the death of one of its fellow bugs and gives up trying to hide.  Found when a previous bug, now fixed, was hiding this bug

Guilt                        A bug that regrets being there.  These bugs are keen to atone for their sins and are, therefore, easily fixed

Happiness              Found during “Happy path” testing.

Hatred                    A bug that hates you is one that you think you have found, but keeps coming back to haunt you in every release

Hope                       A bug that hopes not to be found.  This type of bug just sits there and waits.  It may be an easy bug to find or a difficult one, but is always obvious

Hopelessness         See Despair

Hostility                  A bug that shouts at you.  Usually shows itself with an error message ALL IN CAPS

Humiliation             A bug that is so ashamed at being found that this part of the system never displays any bugs ever again

Hysteria                 A bug that shouts and screams all over the application, causing all around to react with panic.  Usually a shows as a system crash

Inspiration              A bug that is as a result of some really clever coding brought about through an inspired developer….who got it wrong.

Jealousy                 A bug that shows the symptoms of another type of bug which is superior to it

Kindness                A bug that is kind to the developer by being easy to fix

Loneliness              A bug that is a hermit.  This type of bug is isolated from the rest of the application in an area that has no other bugs

Love                       Another gregarious bug.  Not only does this bug congregate with other bugs, it actively hangs on to them, so you find two, three or more all doing the same thing

Lust                        This is a bug that spawns other bugs.  A prolific breeder which means both tester and developer are forever chasing its children

Nostalgia                Bugs aren’t what they used to be.  This bug bemoans the fact that it hasn’t been found by Grace Hopper

Panic                       This bug causes all the parts of the system to go into meltdown.  Typically this is a tight loop that consumes all of the CPU

Patience                  This bug just takes its time.  Often seen as a Performance bug

Pride                       A bug that thinks it is the best bug in the whole system. Often surfaces before a fall-over

Repentance            A bug that feels bad about existing and once fixed, fixes a number of other bugs as a side effect

Resentment            A bug that does not like to be found, such that once fixed it re-appears again and again

Shyness                  A bug that is really hard to find and only surfaces in rare circumstances

Suffering                 A bug that causes the entire system to suffer.  Often found as a result of security testing

Surprise                  A bug that does not expect to exist.  Typically a simple bug that should have been found in unit test

Wonder                   A bug that is amazed to exist and cannot understand how a developer could possibly have coded it that way

My dog, Rusty, is getting old, he will be 14 years old next month and we have had him since he was 12 weeks old.  He is a terrier cross with all the bad traits of the terrier, but all of the good ones too. He has always been “good” at killing; rats, mice, rabbits have all fallen victim to him over the years.  He is now blind in one eye, mainly deaf and gets out of breath after playing for more than about 10 minutes, but he still enjoys life and otherwise is very healthy for his age.  Recently, we have had a rabbit visiting our garden every day and Rusty tried a couple of times to catch it, but the rabbit was too quick for an aged dog.  After the first couple of failures, Rusty gave up chasing the rabbit.  The rabbit was eating my plants and despite putting down animal deterrent chemicals, sharp sticks, cages round valued plants, the **** thing kept eating the plants.  It started to become more and more blasé about me, my wife or Rusty coming into the garden when it was there, lolloping off slowly rather than fleeing in panic.  Rusty kept eyeing it up, but didn’t chase it.  Last night, Rusty got it – the rabbit got too close, was too slow and too complacent.  Part of me was delighted to get rid of the pesky thing, part of me was saddened at the death of such a marvellous creature.  I got to thinking, however, did Rusty play the game of letting the rabbit get more and more complacent with the thought in his mind that sooner or later he would get it? Or, did he just see the opportunity and go for it?  He is an intelligent dog.  Yes, I know everyone thinks their dog/child/pet is the best/most intelligent/etc. but he really is intelligent, so maybe he did play the patient, long term game.  

What has this got to do with testing?  As often happens, my mind turned to the similarity between life and testing.  Bug hunting is not just about going full blast as fast as you can hunting down those pesky bugs, sometimes that fails, sometimes we have to play the long term game.  If we are suspicious of an area in the system, we may have to be patient, try a different strategy.  Intermittent bugs are one area where this strategy is best employed.  Patience is key to finding an intermittent bug, determining what are the conditions that cause the bug to appear, trying different strategies, minutely changing some parameters to see what might cause the bug.  Finally, to complete the analogy, the bug becomes too complacent at not being found and we are able to catch it and kill it.  Strangely, there is delight at finding the pesky thing, but some sadness over the death of such a marvellous creature.

Real life and testing sometimes are too close together! Or maybe I need to get a life and stop thinking about testing….

Who would have believed that it would be so difficult to recruit decent test automation staff?

I have now been looking for someone to beef up my automation team for over 3 months and only just found someone who is worth hiring.  I have not been looking for someone out of the ordinary; at least I don’t think so.  I have been looking for someone who is experienced in test automation, minimum of 3 years, has written automation frameworks and who has a reasonable idea of testing principles.  QTP experience was desirable, but the key attribute was ability to automate.  Salary would not be too much of a problem for the right person.

I have had over 60 CVs to go through, about 20 telephone interviews and face to face interviews.

Firstly, the CVs.  Many people putting themselves forward for automation roles have only used capture/replay.  This surprised me as I had the, obviously mistaken, belief that the days of doing only capture/replay had gone years ago; it appears not and the old myth of capture/replay being the way to automate seems to be alive and well.  And some of the salary requests were outrageous.  Many CVs were from software testing consultancies or outsourcing companies and the level of knowledge displayed by these people was woeful which only went to strengthen my opinion that software testing consultancies and outsourcing companies mainly body-shop and are only interested in placing people not skills.  But, I digress.  Many CVs came from people who had just arrived in the UK from India, which has given me the impression that there is quite a few migrants coming this way; which was interesting but most of the skills were not up to the mark and the CVs were, generally, quite badly written – although, having said that, the person I am going to hire has only just come to the UK from India.

Secondly, the interviews.  I find telephone interviews useful to weed out the obvious no-hopers and people who do not tell the whole truth on their CVs.  Being an interviewee over the phone is as difficult as interviewing over the phone, but the number of people who just could not communicate over the phone was staggering.  The ones I got in for face to face interviews faired not much better.  I don’t much like tests in interviews, but for an automation role, a very brief test was given, to write a short VBscript to solve a common problem (finding one item from one array in another array, finding the maximum of three numbers) and I was amazed at how many either could not do it or got it hopelessly wrong – one candidate even wrote the “VBscript” in “C” and that was wrong!  There were some that had blagged the telephone interview that soon came unstuck.  Most had (or said they had) the ISEB foundation certificate and could not answer simple questions that ISEB poses.

Thirdly, the recruitment agencies.  I was explicit in my requirements, I even provided some sample questions with expected answers for them to ask candidates before I even got to see the CV.  However, the agencies persisted in sending totally unsuitable CVs and people who could not answer the sample questions – not one single agency has been good that we have used.

But the thing that really makes me think about this whole exercise is that there are a lot of people out there who don’t know how to do a testing job and/or an automation job.  They have been working, most for over 3 years, doing a testing job.  The skill level is, therefore, low.  No wonder that some people think anyone can do testing.  It saddens me and I wish I knew how we testing professionals could change that.

My wife has an interest in “New age” beliefs, some of which she believes in, some of which she is sceptical about.  Me?  I’m always sceptical, however, I try to be as open-minded as possible and see what I can gain from any beliefs.  Last night, we watched a DVD called “Law of Attraction” which, if I boil down 1hr 50 minutes into a single sentence, is “if you want something, focus on it until you get it”.  OK, I think I was taught that when I about 5 years old, but hey, maybe some people need a reminder.  

One of the analogies used interested me from a testing perspective (yes, I am getting to testing eventually!).  The analogy was of a Satellite Navigation system in a car.  You tell the Sat Nav where you want to go (your goal), it works out the best route for you and then tells you how to get there.  The premise in the DVD is that we all have messages being given to us by non-physical means to guide us to our goal and all we need to do is listen to these messages and we will get there and achieve our goal. Personally, I found this hard to stomach, but maybe that is just me; there are too many variables in life for this to make any sort of sense and do I believe that I have this non-visible, non-physical “presence” sat with me all the time trying to guide me as to what to do?  No, I do not.

Getting back to having a goal, the Sat Nav and testing.  I got to thinking; do we have one overriding goal when we are testing? Wouldn’t it be great if there was a system where we can plug in that goal and it will tell us how to get there?  Call it the Test Sat Nav (TSN)

I got to thinking that probably we do have a goal and that goal is to complete the testing successfully.  The problem with that statement is what does “successfully” mean?  I would guess that every Test Manager has their own, slightly different, interpretation of what “successfully” means and every Project Manager has their own interpretation that will be different from the Test Manager and every customer will have their own interpretation that will be different from the Project Manager and the Test Manager.  So if we can’t agree a common meaning for the goal, how can we ever achieve it? And, therefore, how could we ever design a TSN that would enable us to plug in that goal and come up with the means of getting there?

So, maybe the goal is wrong, maybe it needs to be better defined, indeed if I put into the Sat Nav that I want to go to Birmingham, Birmingham is a big place and the chance of getting exactly where I want is not high. So maybe my goal is to meet the exit criteria?  Possibly better in terms of being able to tell the TSN, it might be easier.  But the problem with that is that we all do things during testing that are not directly related to the exit criteria.   Imagine putting No 10. Broad Street, Birmingham into my Sat Nav and deciding halfway up the motorway that I need to use the men’s room in the service centre?  That isn’t catered for in my instructions to the Sat Nav and it gets confused when I turn off the road it told me to go on and it isn’t part of my exit criteria.  In testing we go in a different direction than planned because we feel we have to, something needs a different focus, priorities change.  If on my road to Birmingham, the water company has decided to dig up the road and I get diverted round different streets, the Sat Nav is continually trying to get me back to where it thinks I should be, but I can’t because the road is blocked off.  In testing we get diverted by what happens to us, bugs being found that cause us to stop testing, changes that happen to the project and we have to take a different route.  The exit criteria haven’t changed, but the route there has. 

By this time, I am now wondering if we have a goal in testing at all that we can quantify, plan for and know we have met.  My idea of the TSN looks dead before it has started, if we don’t know where we are going, how can we plan to get there?  

Then, the “Eureka” moment occurred.  The totally unrealistic goal we have is that everything is tested 100% and there are no bugs of any kind in the delivered software. We, therefore, cannot get to that goal, it is an impossible goal; all we can do is travel towards that goal and at some point decide we have gone far enough.  So, testing does not have a destination that can be measured in the way of knowing you have got there, definitively.  All you know is that you have got sufficiently close to the destination and you do not need to go any further and you know that because of the measurements and metrics that you have been taking and, in the final analysis, by using your judgement. 

Having decided that, the TSN is easy, all I need is a program that will predict the changes that will happen along the way, the diversions that will happen and be able to predict the judgement call.  In fact, all I need is another New age belief, that of psychic prediction – I’ll get my wife to sort this out for me.

I went to an interview last week.  I was looking forward to the interview as I had heard good things about the company and they knew what good testing was all about.  It looked like a good opportunity and the project sounded interesting.

I liked the interviewer and I answered all the questions as honestly as I could.  Most of the questions were situational, of the format “what would you do if….?” Which makes you think about what you would do based on your own experience.

At the end of the interview, the interviewer told me that I would not be getting the position.  I asked why and was told that I was “too nice” for the role.  I know a few people who would disagree with any sentence that had my name and the word “nice” in it, however, the interviewer explained that the role required someone who, in the interviewer’s words, was a “b*****d” due to the nature of the project and the personalities involved and I didn’t have the personality required.  It became clear that the project had an aggressive character; there was a lot of political manoeuvring; conflict was the norm.  A female friend of mine calls such projects TDD.  No, not “Test Driven Development” but “Testosterone Driven Development”.

I left the interview somewhat disappointed and deflated.  One the way home, I reflected on the answers I had given in the interview and tried to work out what answers the interviewer was looking for.  I came up with some answers that maybe would have fit the bill and worked out that, had I given them, they would not have been a true reflection of the way I like to work.  I finally had to agree with the interviewer, I was not the right person for the position and I would not have done a good job in it.  Clearly, the interviewer was a good judge of character!

However, I was still non-plussed by the “too nice” tag.  I have been called a few things as a Test Manager, but “too nice” has never been one of them!  So, I examined the answers I had given and compared them with the ones that the interviewer wanted and I came to the conclusion (which I knew already) that I like to work in a co-operative environment where everyone is working as a team towards a common goal.

A co-operative environment does not mean that you are always nice to each other, hugs and kisses around the meeting room are not going to help the project, and I have my fair share of violent disagreements and arguments but they are almost always concerned with the project, not personalities.  I firmly believe that the co-operative environment gets the job done with better quality, lower cost and quicker than in a non-co-operative environment.  If you are all pulling together with the same aim and following the same agenda, things work better.

But, what do you do if you find yourself in an aggressive environment?  It has happened to me as I am sure it has happened to a number of us.  My first reaction is to be co-operative, even in that environment, and it can work, I have proved it.  I have one particular example where I turned an aggressive environment into a co-operative one.  OK, it took me some months and a lot of hard work, but I got there.  If trying the co-operative approach does not work, then you may have to get aggressive yourself, but if it is not in your nature you will find it difficult – I find it difficult and can only keep it up for a short period of time.

So, going back to this position I didn’t get.  A part of me wonders if I could have turned it around and made it into a co-operative environment.  I will never know.  The interviewer would not take the risk with me and in the interviewer’s place I wouldn’t have taken the risk with me either, the interviewer made exactly the right decision, in my opinion.

I’ll stick with believing in the co-operative environment, but I doubt I will ever hear anyone call me “too nice” again!

I have found a way of making my millions.  I have a problem with moles in my garden; they dig up my flower beds and leave hills in my lawn.  I don’t like to kill the little creatures as all they are doing is what is natural to them and surely I can put up with a bit of inconvenience, it is not worth an animal’s life to stop that is it?  But, I would like them to stop, so I want to deter them. 

I have tried sonic devices that moles don’t like the sound of, I have tried scent related deterrents, but the following morning, there is another one or two mole hills in my lawn.

I have discovered a method of removing moles from my garden that is as effective as all the proprietary methods and is considerably cheaper.  My method is to put posters around my garden with slogans saying “Moles keep out”, “Moles go home”, “This is a mole free garden”.  Believe me when I tell you that this is as effective as anything you can buy, i.e. it is not effective at all – just like anything else you buy!!  I am sure if I market this “solution” as well as all the other products I have spent a fortune on that haven’t worked, I could make millions.

Slogans are pointless, they do nothing to improve any situation.  Around our office, the Account Manager had posters put up saying “Are you the key to the next release’s success” and “Do it right first time every time” and my all time hated poster “Are you at peace with your piece of the next release?”  What on earth does anyone think these will do for the project? 

I find it incredible that any reasonably intelligent human can think that a slogan on a poster will make a difference to another reasonably intelligent human being.  It may work in a factory where the work is mind-blowingly boring and repetitive, I don’t know, but it will not work in a creative environment like an IT shop.  I tackled the Project Director about these posters and he stated that they were intended to keep people focussed.  Oh, that is alright then, so people would not be focussed if the posters were not there?  Of course they would, all the posters have done is give some amusement and a lot of irritation, can’t you high-ups see that?

I tore down the two posters put into my area and put them in the recycling, see, I knew I would find a use for them!  It is my job to motivate people and keep them focussed and I do not need posters to do it for me.  I didn’t see any lack of focus afterwards.

By the way, if you want to see some posters that are the exact opposite, go to www.despair.com, they made me laugh.

Moles, however, are much less intelligent beings, they are sure to be affected by my posters and they will be deterred from my garden.  Please email me with your order.  I can accept cash, cheques and I am just about to set up a PayPal account.  Only £2.00 per poster or 5 for £8.00 – you won’t regret it..

A few years ago, I went into a large multi-national bank to perform a consultancy task to review their testing practices.  As a consultant, you get one of three types of reactions when you enter the building:

1. A Groan – This is often because they have had bad experiences with consultants before and think this one will be no different.  I don’t mind a groan, this often tells me that they have decent practices already and you won’t find much to worry about.  This type of assignment is generally praising what they have done and recommending improvements in some areas.
2. A Hurrah – This is the juicy assignment.  A hurrah usually means that the workers know that what they are doing is insufficient and are hoping that the consultant will finally tell the bosses that they need to get their act together.  This assignment often means that there are no (or very bad) practices and you are starting from ground zero.
3. No reaction – These are the worrying and most hateful assignments.  This often means that someone high up has called in a consultant with no buy-in from the staff and they are not going to co-operate with a single thing you do.  You have an up-hill battle to even find a desk or get told where the toilets are.  Your best bet is to do what you can, write the report and get out.

Anyway, back to this bank.  I got the “Hurrah” reaction when I walked in.  I soon found out why.  In the section I had been called into, there was a development team of about 80 and 2 testers, yes, count them, 1, 2.  These 2 testers were from one of the high street branches and had been called in a couple of years previously to give the system a quick once over before it went live.  2 years later, the system was still a mess.  Some releases had gone to live and some of it even worked, but the system had some chronic problems.

I started doing the usual things for gathering information and it quickly became clear that the main problem was not only the testing (surprise!) but the Project Managers.  One Project Manager, during my discussion with him stated “We incentivise our staff with a bonus which gets more the fewer bugs are found in the code”.  I asked him how the tester was incentivised and he replied with a puzzled look on his face “The same, of course”.  So, the testers got a greater bonus the fewer bugs they found!

The testers had been given no training in testing, they were both intelligent people but they were not IT people, they were business people.  I asked them for their test plans and test scripts and it came as no surprise to me that I got a 1 page test plan and 2 pages of test script.  

The reaction to the presentation I gave to the senior bosses was extremely positive.  You could almost hear the sighs of relief around the room that the problems had been identified and that an action plan had been proposed.  This came as a surprise to me as I was expecting some hostility (I had pulled no punches).  It turned out that Director had not been with the bank for very long, which I knew, and he had been haranguing the senior managers about the lack of quality and they just didn’t know what to do about it – now they had a way forward.

That 4 week assignment to review their testing practices turned into a 4 year stint with them as they asked me to put the action plan in place.  And a very happy 4 years they were for me.  And I kept on the two business people, trained them and they became very effective business testers.

The lessons I learnt from this experience were:

·        Just because it is a large company, it doesn’t mean they have good practices

·        Senior IT managers do not always understand how to improve quality, they need telling.

·        The situation of lack of testing in an organisation is an opportunity, not a reason to be depressed.

·        “Shooting from the hip” sometimes works!

Should testers execute their own test cases?

Ask this question and you will get a barrage of differing views all with their reasons for a “yes” or “no” answer.  It seems that this is an area that testers and test managers just can’t agree on.  

So maybe there is something we can agree on, or at least debate, without having the poles apart yes/no extreme to the question.

Can we agree that test cases should be created?  No, we can’t. James Bach would argue that test cases have no place in doing testing.  If I read him correctly, he believes that formally written test cases have limited value and can actually be counter-productive to good testing and their only use is if there are legal reasons to create them (apologies, James, if I have mis-represented your view and you ever read this).  I have a lot of sympathy with that view and like to reduce (note, not eliminate) the number of test cases that my team writes to a minimum level necessary.  Key phrase there is “minimum level necessary”.  I believe there are occasions when the most effective way of testing something is by writing a test case.

Ok, so we can’t agree on whether we should write test cases, hmm, where to go from here?

Perhaps we can agree that tests need to be designed?  If we take the definition of “designed” as meaning that the tests are thought about before actually executing, then I think we can agree.  Even if you are doing Exploratory testing you are designing tests, by jottings on pads of paper, frameworks in your head or bright ideas that just pop-up as you learn more about the system you are testing.  Ad hoc tests are not designed, but I would argue that Ad hoc testing isn’t testing, it is playing around and has no place in the professional tester’s thinking.

So, if we can agree that tests need to be designed, then what is the implementation of that design?  

Before we determine that, maybe we need to look at what is the purpose of the test.  The widest view of the purpose of any test is to find a bug.  OK, we can argue about risk, control, confidence level, etc. but at the end of the day we are trying to find bugs.  But, it isn’t quite as simple as that.  From a project perspective, yes you are trying to find bugs, but there are supplementary purposes which are valuable to the test team, the project and the company.  Some examples:

·        Teaching a tester how to test.  The only way I know of teaching someone how to test is to get them to test.  Training courses are all very well, but they only give pointers on how to test.

·        Teaching a tester about the product.  It would be nice if every tester knew everything about a product before they started to test it.  Some testers may, but some (maybe all) will not.

·        Improving a tester’s skill set.  This may be in terms of getting the tester to use a previously unknown/unused technique; it may be in terms of getting them to lead a test effort.

The implementation of the test design, therefore, should be dependent on the purposes of the test. 

But we still do not have a full answer on how to implement the test design, because now we should consider what is the approach taken to testing?  By this I mean are you a test case shop, an Exploratory shop, unstructured or a mixture of approaches.  Your implementation of the test design will depend on your approach and your approach may change depending on the product you are testing this week.

When you have implemented your test design, then you need to execute the implementation.  Part (a small part) of me argues that if your design is good, then your method of execution is irrelevant, because you have done all the hard work of thinking and the rest is mechanical.  The rest (and more dominant part) of me argues that all you have done is laid a framework, no matter how good your test design is, the system under test is going to surprise you and you will not have covered everything you find you need to cover.

If that is true, that your test design implementation is only a framework, how do you determine who executes the test?  That decision should be made on who is the most appropriate person to execute the test, based, again, on what is the purpose of the test and the method of test design implementation.

No doubt in twenty years time people will still be arguing about whether the test case author should also execute the test.  Me?  I’ll stick with saying that “it depends” and take each situation on its merits.

I turned 50 last year.  No big deal, no big party, I didn’t want one.  After all I don’t feel I am getting old or even middle aged, in many respects I still feel the same way I did when I was in my 20s.  There are signs, however, of getting a bit older.  I was reminded of these signs over the holiday weekend just gone in the UK when I was out shopping with my wife:

·        I look at some of the young people and think “how can they wear those clothes?”

·        I hear some of the popular music and think “but it all sounds like noise to me”

·        I reminisce with my wife and friends and we talk about things that we did when we were “young” and realise that we saw things that happened well before current teenagers were born

·        I used to think I knew it all, as I get older the more I learn the more I realise there is to learn

·        Conversations often end with the phrase “which was a lot of money in those days”

Maybe I am turning into my Dad, they say we do eventually.

I was thinking more about this today as I drove to work listening to a Jimi Hendrix CD and realised he has been dead for 36 years.  My first major row with my parents was over him, they wouldn’t let me go to see him in concert because he took banned substances and they said I was too young to go to Woodstock (they were probably right, but what a gig that was and how envious I was of the people I knew who did go!).

What has all this rubbish got to do with Software Testing, you may well ask!  I was thinking, whilst listening to “Voodoo Chile”, about my early days in Software Testing and there are signs of getting older:

·        I see a question on a forum from a newbie and think “how can anyone not know that?”

·        I hear someone talk about how they found a bug and think “but that is how we have always found that type of bug”

·        I reminisce with colleagues and we talk about how software development used to be and realise that some of the computers we used were built well before some of the current new testers were born