Last week I attended the BCS SIGIST (no, that isn’t the bad thing!).  As usual, the day was well spent and enjoyable – Michael Bolton was excellent, as expected.

 

One of the presenters was Lloyd Roden.  Lloyd is a very good speaker, I have heard  speak him a few times and I like to listen to him.  Lloyd belongs to Grove Consultants and I have enormous respect for Grove and the people in it, having recommended them to a number of people and I will continue to recommend them.  His presentation this time was on his top ten controversies in Software testing and it was very entertaining, Lloyd is good at that.  I agreed with his view on 8.5 of his top ten.  The one I had a major disagreement was on certifications.  Lloyds view is that they are useful, I disagree.  That is not a bad thing that I disagree, however, I became incensed by his argument, interrupted rudely and argued with him whilst he was doing the presentation – that was the bad thing.  I should have talked to him off-line, not interrupted and argued during his presentation, especially not argued with him whilst annoyed, as I was.  Lloyd did a very good job of shutting me up politely, well done to him.

 

I have emailed Lloyd with an apology, and let this be a public apology.

 

What got me annoyed?

 

Lloyd argued that other professions use certifications, and he gave examples, therefore we should too.  He also said that ISEB/ISQTB are good because they give common terminology.  There are fallacies in this argument, as I see it, as follows:

 

Other professions do use certifications, it is true.  There is a big difference, however, between the examples given and what we have in ISEB.  The big difference is that professional certifications, like CORGI (now the Gas Safe Register), which was one of Lloyd’s examples, require the person who is certified to not only undergo training, but to show their competency.  They can also have their work inspected to show that they do good, safe, work.  From my own life, as I have mentioned before in this blog, I enjoy Ballroom and Latin American dancing (see http://www.sqablogs.com/petenairn/783/Dancing+is+like+Testing.html).  I am currently training to be a Dance Teacher.  I will (hopefully) get certified and to get that certification, I need to know the theory but also to demonstrate that I can actually dance as part of getting my certification.  I cannot even study to become a teacher until I have passed other tests that show I can dance to a reasonable level.  These are measures of competency and knowledge

 

What do you have to do with ISEB?  Turn up to a testing station, answer some multiple choice questions and hey presto, you are a certified tester!  Yes, you can go on a training course and even if you don’t then you will have to do some self study.  But, you do not have to show you can test.  This certification is, therefore, a measure of knowledge, not competency.  See my previous entry for where the two can become confused http://www.sqablogs.com/petenairn/2296/Certifications+don%26%2339%3Bt+give+competency.html

 

To be fair to Lloyd, he made it clear that you can be a good tester with no certification and you can be a bad tester and have certification, which I agree with.  So, I have to ask, what is the value of having the certification in that case?  I find it difficult to respect a certificate if someone who has never tested software can pass the exam – and I personally know of two people who have done just that.  If I know of two people, how many other people have also passed the exam who have never tested? How is that certificate valuable? 

 

Is there a way of measuring the competency of a tester by the use of an independent body?  This is where it is very difficult for a national or international certificate to be devised.  I don’t have an answer to it, except to say that when I was at IBM, we had an internal certification program whereby you had to show competency before getting that certificate.  It worked reasonably well, I was on the board that examined testers request for certification and we were very stringent in making sure we understood whether the person was competent enough to get that certificate.  Certification wasn’t done by the use of a test, but by examining the actual work that the tester had done on one or more projects.  That has its flaws too and I am not convinced in my own mind that the flaws outweighed the benefits, but it is a better measure than only sitting a test.

 

The real problem with the certification of testers, is the view that companies and recruiters take with respect to the certificate.  I see a number of job adverts with certification as a requirement to even apply.  This tells me that that the industry ascribes more weight to the certificate than it deserves. 

 

Being able to apply for jobs is the only reason I got the certificate! Does that make me a hypocrite?  Possibly, probably, but feeding my family is more important than principles to me.  I wonder how many other testers took the test for the same reason?  Is that a good reason for having a certificate? It appears to me to be the only valid reason I can find, but it isn’t a good reason.

 

Turning to the point about common terminology, which is another argument for doing certification, this is also fallacious.  Common terms exist, but what people mean by them is different in the context of the company, project, test manager involved, culture, etc, etc.  I don’t believe we will ever all agree on what is “common” because it always varies, even if slightly, depending on what you are doing at the time.  In some professions common terminology is vital, e.g. if one surgeon calls an organ a “heart”, it is useful if the assistants on the operating table know what is meant.  If we were all doing the same project at the same time, then common terminology would be important, but software development isn’t like that.

 

One other point I would like to make is that there is a difference between getting the certification and getting the training.  I have heard the argument that certifications are a good way for consultancies and training companies to make money out of training courses.  This may be true for some organisations where they only teach people to pass the exam.  Some organisations, however, provide education on testing and also teach people how to pass the exam.  The former are doing the industry no good, the latter are definitely performing a good service.  I put Grove in the latter category – I have not been on one of their training courses, but people I know and respect have and from what they tell me and from the course materials I have seen, the courses are good.  And, no, I do not have any affiliation to Grove whatsoever!

 

The arguments both for and against certifications can get emotional (as I did at SIGIST); I suspect the arguments will continue for some time and there will not be a successful conclusion for either viewpoint.

 

Last point from Lloyd’s presentation was the other 0.5 I disagreed with.  He stated that Test Managers should set aside time each week to test.  I think this is something we managers should do, but only if it makes sense on the project.  When I have over 50 testers to manage, my time is better spent on managing than doing.  By “better” I mean better for the project, better for the company, better for me and better for the testers – I am paid to manage, not to execute tests.  I will expand on this in a future blog entry.

 

So, once again, sorry, Lloyd, for my behaviour – I won’t do it again. Shall we agree to disagree?

There are a lot of people arguing for and against certifications for testing.  Personally, I don’t like certifications as I don’t believe they tell me anything about a tester’s ability to do the job.  Here is an example of where certifications can give a tester a false sense of security.

 

My customer has sent all of the User Acceptance Team onto the ISEB foundation course and they have all taken the exam.  Some have passed with no problem and some have failed, a couple more than once.

 

I was doing some fairly basic testing with one of the UAT testers the other day.  We were testing out a change to some data rules whereby the data was shown to the user, or not, dependent on dates and class of data.  I drove the system for a while and then he did.  When he was testing, I noticed that he was using dates that were way earlier or later than the boundary at which the rule kicked in.  I asked him why he had chosen those dates and he said that he was using Equivalence Partitioning such that any date would do.  OK (ish) except that the rule was very boundary dependent and the better test would be to chose dates on, just before and just after the boundary.  He also was testing every class of the data.  Again, I asked why and he said he needed to check every one.  Here was a good case of where equivalence partitioning made sense as the groups of classes behaved the same way.  I had some difficulty in persuading him that different values would be a more effective way of testing the changes as he had convinced himself in his own mind that what he was doing was right – after all, he had been on the course and had been trained in how to use these techniques, had passed the exam and therefore he knew what he was doing.

 

So, although the tester had understood the concepts of Boundary Value Analysis and Equivalence Partitioning he did not understand the applicability in a real world situation. 

 

It confirmed, in my mind, that the value of doing the training and taking the certification was low.

 

This is the problem with a knowledge-based exam/certification, it has no bearing on the competency of the person who has taken the exam.  Competency can be trained, but not by the use of certification training.

One of the things I try to impress upon my testers is that when testing it is important  not to “prove” that the system works correctly, but to find the weaknesses, faults, bugs.  If a tester tests looking for the system to do what it is supposed to do, then that is what they will find – nothing (or very little), whereas if they are testing to find faults they are more likely to find them.

 

It is too easy to think “that is what the specification says, therefore, that is what I will test against”.

 

I fell into that trap this week.  We have a lot of faults that have come back from Development and we have a short timeframe to re-test them. All of the faults are allocated out to team members to retest.  One of my testers needed to complete some other work before starting on the re-tests and so I agreed that work needed finishing first, then I said “And then you can close off those faults”.  After a short pause, he said “Don’t you mean that I should find the faults in the fixes?”.  It was said in a jokey sort of way, but it was a good point!

 

Two things hit me.  First, of course that is what I should have said and it was embarrassing that I had fallen into the trap.  Secondly, I was very pleased that the tester had pulled me up on what I said, it means I am getting the mindset of the testers better.

 

Isn’t it odd though how even seasoned professionals like me can make that type of mistake?  

 

FACTS:

- The customer is always right

- Automated testing always gives the right answer

- I don’t believe in coincidence

 

Maybe these facts aren’t correct?

 

Here is a cautionary tale of something that happened to us over the last two weeks.

 

We have a process with our customer in order to update some reference data on the database periodically.  This data gets updated maybe a four or five time a year, data is amended or added to (never deleted).  This is their data, spe******ed information that, quite frankly, we don’t claim to understand nor do we need to (hold that thought!). Over the years we have made this a pretty slick process; the customer provides a spreadsheet with the additions and the amendments which gets folded into the data on the database.  We, the test team, have an automated script which compares what the customer wanted with what we have on the database.  The automated script takes minutes to run (for those interested, this is a VB script in Excel).  If all matches, we sign it off.  Up until last week, we have had no problems with this in over 4 years.

 

Last week, we found a discrepancy when the automated script was run.  Two values did not match.  No big deal, a bug report was written and the database team corrected the data in the database, we closed off the bug report as the automated script now said that the two matched.

 

End of story…..

 

Well, not exactly.  The changes went into the UAT environment, the users started using it and the system started behaving very strangely in a key application.  By coincidence, there was a fault raised in Live at the same time on this same area.  Aha!  Duplicate fault from UAT in Live – not a problem, not too serious, don’t panic chaps!  Upon investigation, the Live fault was found as being a user error so that’s OK then….

 

Well, not exactly.  To their credit, the UAT team stuck to their guns and insisted that the problem in their environment was analysed.  We sighed, grumbled about picky customer, you know the sort of thing, but we started investigation.  It quickly became apparent that the problem that the automated script had seen was not a problem in the database at all, but a problem with the spreadsheet that the customer had given us.  The database had, therefore, been incorrectly “fixed” to be equally incorrect.  Causing the problems in the UAT environment.  Also, this showed that the problem was not the same as in Live.

 

No problem!  Uncorrect the database and everything will be fine…

 

Well, not exactly.  The change was backed out of the database and the UAT environment was still behaving strangely.  There was much scratching of heads, tut-tutting, sage experts poring over complicated SQL and even more complicated COBOL programs.  After some considerable, stressful, hours, the problem was found.  The misbehaviour due to the incorrect values in the database had caused flags to be reset so that when the correct values were restored, these flags were still set incorrectly.  We corrected these and everything was OK – with 5 minutes to spare before the customer pulled the plug on an important release.

 

Debunking the facts!

 

- The customer is always right.  Not really, the customer can make mistakes too.  The real fault is believing that the customer has NOT made a mistake and jumping to the conclusion that the system is at fault.  More thought required in diagnosis.

 

- Automated testing always gives the right answer.  I never, ever, believed this one.  Automation without thinking about the problem is not testing.  It is, however, very easy to get complacent about an automated test that keeps giving you answers that look correct (discrepancy or no discrepancy).  We got complacent about this process of updating data.  We won’t make that mistake again AND we need to understand more about what this data does so that we don’t rely on UAT to determine whether it is right or not!

 

- I don’t believe in coincidence.  Here, there was a real coincidence that threw us off the scent for some time.  Coincidences DO happen!

 

Some interesting lessons learned (or, maybe, re-learned).

 

 

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

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

 

 

I, and others, have written a couple of blog entries on how activities outside of software testing can help understand testing (I refer to my entries on Dancing and Gardening).  Here is a story that has happened to me over the last couple of weeks that show the reverse, i.e. where testing skills have helped in my non-work life.

 

My wife is very interested in alternative therapies, herbal remedies, Reiki, crystal healing and the like.  This in turn has made her interested in the more mystical aspects that seem to go along with these alternative therapies, such as reading and understanding Auras, Angels and so on.  Their overriding philosophy is one of openness and honesty in all dealings – remember this for later!

 

Because my wife has this interest, I have also now got a (mild) interest although I am much more sceptical than her.  It is interesting, though, how a lot of the written works in this area have a direct correlation with some of the management books I have read, particularly on managing people, motivation and intuition.

 

However, I digress.  There is a company local to us that has a shop selling things like crystals, incense sticks, books, etc.  They also run a number of courses on the types of healing and how to become more in tune with yourself.  My wife is a frequent visitor to the shop and knows the owners quite well.  

 

A couple of weeks ago the company sent out an email asking for an investor/business partner and were offering a third of the business in return for the investment as well as asking for the investor to participate in the management of the business.  My wife was interested, so we asked for information.  They told us that they wanted £x for the third of the business and that the investor could expect to make about 6% return.  I thought £x was a bit high, so after some thought, we asked the following, basic, questions:

 

·                What was the investment to be used for

·                How was the business value of £3x calculated

·                What was the percentage return on investment for the previous year.

 

I also told them that depending on their answers I would then want my accountant to get involved.

 

All went quiet for almost a week.

 

We then got an email saying that they had decided to put the business up for sale.  The price?  £x/2.  So they had valued the business for an investor at £3x, but were prepared to sell it for a sixth of that value.  It smelled very fishy.  We suspect that the £x investment was to clear debts and the business is in trouble.  So much for openness and honesty, it feels like they were trying to con us.

 

So, by asking simple questions that you would expect a tester to ask (or, indeed any potential investor) we avoided a potentially damaging financial loss.

 

The lesson from this story is that even though someone would appear to have the highest values, you still cannot fully trust them.  This can be true in Testing.  Even the most honest appearing Project Manager can try to hide things from you to get what they want.

 

Bottom line:  If it looks like a duck, walks like a duck and quacks like a duck, you still need to do a DNA test to show it really is a duck!

I like IDMTDT testing, it can be a rich source of errors and can show up data integrity faults and usability problems that you might not otherwise find.  The big advantage is that you can then see how the system handles CRUD activities in unusual combinations.

 

Oh, sorry, IDMTDT stands for “I didn’t mean to do that” and is a set of tests that try to recover from when the user has done something stupid and wants to undo somewhere down the line in the Business process. 

 

A simple example:

 

User creates a new record for a new customer

User enters name/address/Post code

User then creates new accounts record for new customer

User puts credit limit on new customer account

User enters sales representatives name

User activates new customer.

 

At this point, User finds that the Post code is mistyped.  How do you recover?  If the system allows an edit of the customer field, then it is easy, but lets say, for the sake of the example, that there is no edit function for the Post code, it maybe a primary key in the database that is uneditable.  Let us also assume that deletion of customer records is not allowed as the system requirement is to keep all records for audit purposes and the design assumes that the user does not make this type of mistake. 

 

The recovery from this type of problem in a real world situation can be a nightmare (I have seen this type of scenario in a number of systems).  The testing can, however, be quite fun as you have a number of points at which you can try to recover the situation; after the new record created, after the account set up, after the sales rep entered, after activation.  Each of these scenarios will have a different set of tests and may involve exercising different functionality.

 

Planning and scripting such testing tends to be difficult as it is often the type of scenario not covered well in requirements or business scenarios (because people don’t make mistakes, do they?), so the best technique I have found is to include it in Exploratory tests.

 

It is a type of testing that can be forgotten or is done haphazardly.  It also, as a general guideline, should be done once the software is relatively stable as you are not trying to find functionality bugs, but business flow bugs.

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.

Following my entry entitled “Are you positive about being negative”, Joe Strazzere asked what do I call the tests that we execute when we run out of time.  This is a good question and one that I should have answered in the original entry as Joe has correctly pointed out that I now don’t have a name for them.  

 

One of the reasons for not putting a tag on this type of testing is that it can cloud the thinking when determining what tests to run.  “Happy path”, for example, would indicate a certain type of test.

 

If you need some type of “tag”, the best I can come up with is MAT, which stands for “Most Appropriate Tests”.  Let me explain what I mean.

 

Whenever you are short of time for some tests you have to determine what tests you will run to make the best use of the time available. The thought processes go along the lines of:

 

• What are the risk areas of the system
• What are the areas that have spawned the most bugs recently
• What are the most business critical areas
• What are the areas that would be most embarrassing if they failed
• What has changed recently and therefore could have de-stabilised the system

 

So, the upshot is that I can’t give these tests a generic term, the answer is “it depends”, you should run your MAT suite!