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..

 

 

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

·        I went into Software testing thinking I knew it all, as I get older the more I learn the more I realise there is to learn

 

One of the signs of getting older is less tolerance for the less experienced, the less knowledgeable, the “young”.  It is something I see on forums that the experienced people can be terse with the inexperienced.  Maybe we “oldies” should just step back and think “That was me 25 years ago, I needed help with the basics and I didn’t know it”.  I try to be patient with inexperienced people and know that I don’t always succeed, but that is my problem, not theirs.

I know I have got fed up with answering standard questions on forums and haven’t done it for some time, maybe I should start again, with more patience, after all, they will be paying for my pension in a few years time!

 

And, lastly, I remember my first Test department annual budget which was £150k, which was a lot of money in those days.

 

Introverts can’t be managers.

 

I have heard this statement from staff during objectives reviews and career counselling sessions.  I like to ask the question “Do you think I am an introvert or an extrovert?” and invariably the answer comes back that they think I am an extrovert.  Wrong! I have taken a number of personality tests over the years and I am a very strong introvert.  I look at all the attributes of an introvert and I fit them perfectly, yet I have been in managerial positions for 20 years and I like to think I am reasonably successful at it.  So why is there this impression that introverts can’t be managers?

 

I have no evidence for the following, it is merely my opinion based on my observations of people and my own self-analysis. 

 

Let us look at the main properties of an introvert:

 

The natural inclination of an introvert is to hide away in a corner on their own and get on with whatever they have to do; they keep ideas in their heads without vocalising them; they think about things quietly; they are difficult for others to know well and only let a few people in close to them.  

 

The key phrase in the above sentence is “natural inclination”.  This is not a bad thing (says the introvert!) as that is what you are most comfortable with and the way that you are most effective.  However, that is not too good for a manager, especially a test manager, who spends a lot of their day communicating with people.  

 

How do you know if you are introvert or an extrovert?  I would suggest that you take the Myers-Briggs test as I have found it to be the most reliable measure (see http://www.myersbriggs.org/) and get yourself tested.

 

So how does an introvert become an effective manager?  I can only go from my own experience, my own way of dealing with being an introvert and from the advice and guidance I have given to other introverts. 

 

The key message is to break out of your comfort zone.  Force yourself to take on attributes of an extrovert.  Note, I am not saying that you should try to change your personality to be an extrovert as that is not good for you personally, but in your professional life “act” like an extrovert.  A Myers-Briggs consultant called me a “learned extrovert” which means that I learned how to behave like an extrovert when the situation demanded it.  

 

This learned extrovert behaviour is difficult for us introverts and takes time and a lot of practice and you never stop learning.  As an example, one of the worst nightmares for an introvert is giving a presentation, especially to people you don’t know.  I had to give a presentation to 150 people, most of whom I didn’t know.  I was highly stressed before the presentation and dreaded it, but I pushed myself to perform and I got great reviews for the presentation.  I have given training courses in the past, still do the odd one, for people I have never met and this is highly stressful as you are performing for 1, 2, 3 or 4 days.  Again, you have to push yourself to do it.  It gets easier the more you do it, but it never stops being difficult.  One of the training courses I give is on how to do presentations and I inevitably get the introverts saying “but I don’t like doing it and you make it look so easy” Yes, I do, but I am quaking inside, it is a matter of managing your nerves and not giving in to them.

 

You don’t have to give presentations or training courses to “get over” being an introvert, just push yourself to speak out more when with others.  You will feel uncomfortable, that is natural for you, but force yourself.

 

So far, I have concentrated on the negative aspects of being an introverted manager, but there are positives as well.  We are generally better at managing other introverts as we understand them and can empathise.  We think things through before opening our mouths and therefore, hopefully, have a more coherent conversation than the loud mouthed extrovert who thinks with their mouth open.  This can be a useful trait when you are trying to persuade.

 

An important point.  If you are introvert, do not try to suppress your introverted nature, you can make yourself ill (seriously, it can bring on illness).  So make time for yourself, make sure you take a lunch break on your own sometimes, make sure you do have think-time.  Personally, I find that meditation is very effective for me although some people find it useless.

 

Finally, then, a message for all introverts, you can be an effective manager.  If that is what you would like to do, go for it.

Software Development can be a lonely business.  There is the developer sat at his/her desk churning out code day after day with only the compiler to talk to.  The only light relief that a developer has is when the tester finds a bug and needs to talk about it.  The joy of interaction with something that doesn’t just say “Syntax Error” is something to behold.  Watch the developer’s face light up at the chance of human interaction, at the opportunity to exercise vocal chords rusty through lack of use, a conversation!

 

As testers we should support these poor, lonely creatures.  Please give as much time as you can to this worthy cause.

Why do you like being in Testing?

 

This is a question I am asked fairly often by people who both know me and new acquaintances.  Sometimes the question is couched in the “so, you can’t program so you test?”.  As an ex-developer, I can scotch that one!  My answers are various, along these lines:

 

• I enjoy seeing the bigger picture that testing gives you.
• I like the challenge that testing gives you
• I like the variety that you get in testing
• I like finding problems
• I have a questioning mind
• I get a kick out of seeing better quality products than there would have been had I not tested it
• There is so much to learn in the field of testing
• Etc, etc.

 

If I analyse these answers, they are quite bland, they don’t really get to the heart of the reasons and they don’t really say what I feel.  Anyone who has done any consulting or psychology will tell you that there is a technique that you can use with people to “bottom out” an answer, that is, you find out the fundamental reason for why someone does something.  

 

I decided I needed to bottom out why I like testing, just for my own benefit.  After some careful thought and analysis I came up with “I like being in Testing because I like being around testers”.  In other words, it is a people thing, I get a good feeling by being around people who have a testing mindset who are thought provoking who are questioning and who make me laugh (as most testers do!).  My natural instincts are to be with these type of people and always has been, well before I got into testing.  I, like a lot of testers, fell into testing by accident and felt at home once I was there because of the people.

 

I have yet to answer the question honestly in public and say “Because I like testers”, because the questioner probably wouldn’t understand the answer.

 

 

As a Test Manager you get asked all sorts of questions and usually they start with words like “How do I …”, “When should I….” or “What should I…..”.  Occasionally, you get the “Why do I/we….”.  It is these questions that I like.  The How, When or What questions are usually fairly easy to answer, you follow your experience, process, knowledge to answer them.  The Why question is much harder and, therefore, much more interesting because it is these questions that make you think “Yes, why do we…”.  The situation on any project that you have been on for any length of time is that you start to accept the situation you are in, you have done things the same way for some time and it works and where it doesn’t work you try to change it, but you are generally in a comfort zone where everything is familiar and almost routine. 

 

A friend of mine years ago made an interesting statement.  We had been on a project for a couple of years and we were being well paid for a challenging, but relatively routine piece of work.  He said “We are in a fur-lined rut”.  That phrase made me think and ask myself “Why am I staying here?”.  Within a few months I had left the company because my friend was right, I wasn’t moving forward and I wasn’t in a position within that company to change it (long story!).  It is the “Why” question that should keep being asked and if you get the answer “I don’t know” or “Because we have always done it that way” or “If it ain’t broke don’t fix it” then it is time to get things changed and improved.  This is the essence of improvement, be it personal improvement, process improvement or any other type of improvement.  

 

The answer to the “Why” question may be that there is a good reason why and we don’t need to change, but the very asking of the question makes you go back and re-evaluate why.  If you come up with the answer that you don’t need to change, that is OK, but then you have made a conscious decision not to change for good reasons, not because you are maintaining the status quo.

 

What made me think of writing this entry was that recently one of my team asked me a “Why” question that made me do some thinking.  It was a good question and a hard one to answer.  As it happens, I am not changing anything as a result of the question, but it made me think hard and that is a good thing. 

 

Sometimes managers are not good at listening to the “Why” questions with an open mind, especially if the question comes from someone who is less experienced than them.  Sometimes team members are not very good at asking the “Why” question as they think their manager knows better than them or it makes them look stupid or it will seem that they are criticising their manager’s judgement.  

 

Managers should encourage the “Why” question and should take time to ask themselves the “Why” question.  It is often the only way to get us all to think rather than do.

 

Maybe we should have a "Why" question day on a regular basis?

I often try to compare activities outside of the testing world, or indeed software development, with how we behave within testing – see my blog entry on Agile Gardening.  This blog entry is in a similar (slightly whimsical) vein.  I find it useful to do the comparison as testing is such an abstract thing with nothing you can touch, smell or feel at the end of it as it is primarily a set of thought processes.  You might say that the test scripts, the screen dumps, the output files, the bug reports etc. are physical outputs of the testing process and they are, but they are not a record of the behaviours of testing.  It is this behaviour that makes us good/bad/indifferent testers.  Maybe I can explain what I mean with this comparison.

 

I like dancing, I have been Ballroom and Latin American dancing for some years now and I am slowly getting better at it.  I am told that I am one of the better dancers in my club.  I wasn’t always so.  When I started dancing classes I had two left, flat, feet, I shuffled round the floor like an arthritic robot (can robots get arthritis?).  I watched other dancers glide round the floor with apparent ease, looking graceful, masterful and in control and I wanted to be like them.  I have done my academic time (more than I really wanted to) so I know how to read books and learn from them, so I got some books on how to dance.  I read the books and I still couldn’t dance any better.  It took me some time to realise that the only way I could dance better was for me to have a teacher who showed me the basics, who showed me how to do well the simple things, who encouraged me and told me when I got something wrong (which was a very frequent occurrence!).  In short, I had to do, not read.  Now, the books make some sense, I can learn some variations and techniques from them but I then have to practice them repeatedly with someone who already knows them to become good at some of the moves.

 

There is no tangible output from being able to dance, but you know someone is good when you see them.

 

Does this ring any bells as a parallel with testing?  Of course it does – I won’t spell it out here because if you can’t see it, you need to go do some testing and stop reading my blog!

This item has come about following reading this item in qaforums http://www.qaforums.com/ultimatebb.php?ubb=get_topic;f=46;t=002204;p=3 where there was a brief exchange between Jim Hazen and myself on the subject of loyalty.  Loyalty is important to me, it is important as I believe that loyalty is an important part of working life.  I accept that it is important to me and some people do not consider it to be as important and that is fine, we all have different things that are important to us.

 

Firstly, here is a definition of loyalty: “Loyalty, as a general term, signifies a person’s devotion or sentiment of attachment to a particular object, which may be another person or group of persons, an ideal, a duty, or a cause. It expresses itself in both thought and action and strives for the identification of the interests of the loyal person with those of the object”

 

I get annoyed with people who expect loyalty.  You find it amongst some managers who believe that because they have some title that they not only deserve loyalty, it is their right to be given loyalty.  You also find it amongst the “experts” who believe that no-one can tell them anything.  This arrogance annoys me and I am much less likely to be loyal.  That is my personal reaction which other people may or may not consider to be a good reaction!

 

What everyone should remember is that loyalty is a two way street; I am only loyal to someone who is loyal to me.  You have to earn loyalty from your peers, your managers and from your team, you are never given it.  You can’t demand loyalty, it is always earned.

 

So, people are loyal to other people and to companies.  Companies are loyal to their staff and other companies.  The level of that loyalty varies widely depending on a number of factors, which I am going to discuss further.

 

What makes someone loyal to a person or a company is dependent on the person themselves, what “pushes their button”.  Some people are loyal because they have a nice office/cube/desk, some because they have good perks, some because they are paid well.  This is what I call doggie loyalty.  I have a dog, he is a 12 year old cross-breed terrier and he is incredibly loyal.  He would do anything for me, but if I stopped feeding him, how long would that loyalty last?  Not long.  Human beings are not dogs, however, if you stop feeding them what they want (money, benefits, etc.) their loyalty will stop.  Some people will not be loyal even if you do feed them, these people require more.  They require someone or something to give them a purpose in life, like success, acknowledgement, position, which could be called social loyalty.  If you look at Maslow’s hierarchy of needs http://www.businessballs.com/maslow.htm, then you can see what it is that breeds loyalty above the doggie loyalty, or level 1 and 2 in Maslow’s hierarchy.

If you look around the people who work with you, what level of loyalty do they display?  Is it doggie loyalty, or is it social loyalty?  What level of loyalty do you display?

 

It is my experience that there are a number of people who only have doggie loyalty to a company, these are the people who will change company at the drop of a hat if they are offered more money elsewhere, contractors are more likely to show this type of loyalty although some permanent staff also fall into this category.

 

If you show a certain level of loyalty to a company or person, that is the level of loyalty you should expect to receive.  If you only display doggie loyalty, then why should you expect to be given social loyalty?  If you display social loyalty and only receive doggie loyalty (or less), then you are either entitled to be disgruntled or you should re-evaluate the level of loyalty you are prepared to give.

 

I posit that (although I know of no study to back this up) if you show loyalty to your company, they will show loyalty to you. A company may display doggie loyalty, i.e. it is only interested in the profits it can make.  Some are more altruistic and care about their employees.  A doggie company will not care how loyal you are, but a more employee friendly company will reward loyalty with loyalty – again, you have to earn it by your display of loyalty.

 

If you are manager or team leader, you should want to inspire loyalty in your team(s).  Loyal team members work more effectively.  Loyalty means that you will get more out of them, they are more willing to do extra if asked of them.  Determine what it is that gets you that loyalty in every individual and do what you can to give it to that individual.  I strive first for personal loyalty as I believe that loyalty to me is the first step in gaining loyalty to the company.  I don’t always succeed, some people will never be as loyal as I would like, but often I do succeed.

 

Something to beware of, as a manager, don’t confuse friendship with loyalty.  It is very difficult (for me, at least) for a manager to be a friend and a manager of anyone who is working in your team.

 

So, to sum up, loyalty breeds loyalty and if you display it, you will often receive it.  If you display doggie loyalty, then you should only expect to receive doggie loyalty.

 

Agile Gardening

 

I am a keen gardener, I love pottering around the plot and adding plants here, moving plants there, weeding, feeding, watering and then just sitting and looking at it.  Now and again, I get the urge to do something a bit more and redesign part of my garden.  I started redesigning my back garden this year.  I thought about which GDLC (Garden Development Life Cycle) I would use and it came down to a choice of the Waterfall (no, not lots of water features) model or using Agile methods.  I decided on the Agile methods.  I have previously sat down with garden design software and designed my garden in detail, showing the hard landscaping, the shape of the lawn, exactly which plants would go where and using the clever software features of showing what the garden would look like in 10 years.  There is an element of satisfaction when you then print this plan on A3 and pour over it, tweaking bits before finalising the plan.  Then you get a contractor to quote for the work you want doing (I never have the time to do it all myself), you get a timescale, you plan out the deliveries of plants and hard material, work out which plants you are going to keep and where they need to be kept whilst the work is going on.  The work starts and is inevitably late finishing, hampered by the weather, unreliable deliveries, faults in the plan needing rework and the whole project becomes frustrating.  The enjoyment of having a new garden evaporates because of the headaches to get it done and for some reason it never quite looks as good as you had planned it.

 

With Agile gardening, it is much more fun.  I had a broad view of what I wanted, I wanted to screen off my shed and greenhouse, replace the conifer hedge with a fence and make a back border, move the patio from the edge of the garden to the centre and make a woodland garden where the patio used to be.  So, the parts of the product are Back Border, Patio, Woodland Garden and Greenhouse Screen.  I got the landscape company in to broadly quote for the work, within the budget I have and they were very happy to have a broad brief that enabled them to use their creativity to produce a good garden.  As the work started, we discuss the next step at short regular meetings, what had worked so far and what we needed to change and the garden started to take shape.  A problem tracking system has been put in place so that we can record what needs changing (I call it GardenZilla)

 

Of course, I did some work myself.  This was in the form of some Exploratory Digging (or ED). I wanted to see whether the border at the back where the hedge had been replaced would stand some deep rooted shrubs.  I dug that border in a series of Exploratory Sessions and the debriefs with the boss (my wife) happened every 2 hours over a cup of tea or lunch so that we could discuss progress and what further Exploratory Sessions could be done.  I kept learning about the depth of the soil along the border and was able to determine where I needed to add more organic material and where there was enough so I could work out which plants went where.  Having done the ED, I then went on to the Exploratory Planting (EP).  Here all the plants I had bought, grown from seeds or cuttings or saved when other parts of the garden were dug up were placed in what I thought were the best places for them.  I then looked at them and moved a few around.  I then went indoors and looked from the upstairs window to see what the effect was.  This caused some more movement of plants.  Once happy, they were all planted in the border.

 

The back border is now Live and so far there are no problems, but as the summer approaches, I expect there to be some mistakes so they will be added to GardenZilla.

 

The garden is not yet fully complete.  Back Border is Live, Patio is work in progress, Woodland area and Greenhouse Screen are not started,

 

There is some excitement in seeing the broad view coming together, the landscaper is happy, I am happy and the end product looks like it will be good.

 

As each part of the garden goes Live, we can establish the goals of the next part of the garden and work towards them.

 

I now need to ask myself am I bringing my work home or am I taking my hobby to work?

There are a number of ways of measuring the processes in a test organisation, CMMI, TPI being just two. It is all very well having these methods and any way of measuring is useful, but how do you go about determining where your problems are and how to resolve them?  TPI is great and it does provide some useful pointers, but what are you going to do in your shop?

 

A method I have found useful is a SWOT analysis.  For  anyone who does not know , SWOT stands for Strengths, Weaknesses, Opportunities, Threats. 

 

Strengths are those things you as a test team are good at.

Weaknesses are those things that you as a test team are not good at.

Opportunities are those things that are outside of the test team that if happened would be good for you

Threats are those things that are outside of the test team that if happened would be bad for you.

 

I have run this exercise a number of times in order to improve the processes that we use in test teams and it has proved quite successful.

 

You run the SWOT analysis as a workshop, or series of workshops and you will invite some of your key team members to participate.

 

The last time I ran the exercise at the end of 2005, I split the workshops into the following subjects:

 

• Test Preparation
• Test Execution
• Interfaces and communication
• Bug process
• Test Management
• Releases to Testing

The first set of workshops identified the SWOT for each of these subjects and then the second set of workshops identified the actions that we could take, who would take the actions and when they should be done by.

 

The actions were then monitored over a period to ensure that they got done.

 

It is difficult to measure the effect of each of the individual actions, but following the workshops, I can see that we are getting more effective and better at what we do.  The exercise will be done again soon, so that we should get a new set of actions to continually improve.

 

An example of the output follows:

 

Test Process under examination:  Bug Process

 

Strength:  Good Level of detail in bug reports

Weakness: Analysis of No Fault Founds take too long

Opportunities: Fix fail rate is improving

Threat: Bug reports from Help Desk have insufficient detail making them difficult to retest

 

Actions: Educate Help Desk into better bug reporting.  Analyse fix fail rate to improve further.  Work closer with developer on No Fault Founds,.

 

 

On the last exer