In my previous blog I touched upon a term called Confirmation Bias and how as testers we should be aware of this. I stated that I would put a blog together on the subject so here it is.
I should start by defining what confirmation bias is.
Confirmation bias refers to a type of selective thinking whereby one tends to notice and to look for what confirms one's beliefs, and to ignore, not look for, or undervalue the relevance of what contradicts one's beliefs:- http://www.skepdic.com/confirmbias.html
The reason I started to look more into confirmation bias was due to the following article in Ars Technica - http://arstechnica.com/science/news/2010/07/confirmation-bias-how-to-avoid-it.ars
A good example of this is if you are thinking of buying a new car and all of a sudden you seem to notice lots and lots of the model of the car you was thinking of purchasing. You mind is conditioning itself to notice this make and model of car and making you notice them more, even if there are no more than there was before – you appear to be seeing them everywhere.
Another example is if you start talking to a friend about a certain film and actor and then suddenly notice lots of coincidences, the actor is on a advert, the film is being shown again on TV, a support actor is in another film you just started to watch. The following gives a good example of this. http://youarenotsosmart.com/2010/06/23/confirmation-bias/
If there was no such thing as confirmation bias there would be no conspiracy theories. Conspiracy theories are based upon information which proves the theory correct; those who believe in the theory ignore the evidence that debunks that theory.
So why is there any concern for testers?
Let us start with an example.
You are working closely with the development team and you start to ask them questions about the release you are about to test. You ask their viewpoint on which areas they feel are the most risky and which they feel are the most – so you can adjust your priorities as required, a pretty standard exchange between developers and testers. You now start testing beginning with the area of high risk and work your way to the low risk areas.
You find a few serious bugs in the high risk areas (as expected) and you find no problems in the low risk areas.
After release a major bug is reported in the low risk area you tested. How did you miss the bug? Did you see the bug but your thinking was that everything was working alright? Did confirmation bias play a part? Did your subconscious hide the bug from you? Now this gets very scary, most people who work in software testing know that some bugs try to hide from you, we expect them to hide in the software. What happens if they decide to hide in your brain?
So how can we try and prevent confirmation bias?
The quick and easy way to try and prevent confirmation bias is to ensure that more than one tester tests the same feature, they may bring in their own confirmation bias but hopefully it will be different from the previous testers bias. There is more chance that it will be different if the testers have not discussed the area under test beforehand.
Another way to try and prevent confirmation bias is to do ‘paired testing’ either with a software engineer, another tester or a user. That way you can question each other with regards to what is true and what is false. There is a chance that you could cross contaminate each other with your own confirmation bias, but the risk should be less than if your are working on your own.
It is not easy to remove confirmation bias since it is infectious. The way of working on a software development project requires testers to communicate more and more with other areas of the business and at each stage and with each conversation confirmation bias could be introduced.
So should we lock ourselves away in a dark room with no communication with anyone else on the team? I think I would get out of testing as a career if that happened, the Social Tester (@Rob_Lambert) would now be the anti-social tester, time to get him a ASBO (For our non-UK readers - http://en.wikipedia.org/wiki/Anti-Social_Behaviour_Order)
My view is that there is no realistic way to prevent confirmation bias due to the way software development projects work and that there is a need for everyone to be able to communicate with each other. However if testers are aware that there is such a thing as confirmation bias then they can try and take steps to ensure it does not creep into their testers. That is the whole concept and point of this blog – to help to raise awareness of confirmation bias and how it can effect your testing.
Tuesday, 27 July 2010
Monday, 19 July 2010
The Emotional Tester (Part 2)
The first part of this blog looked at how our emotions could affect how we test. This second part will look at how we could capture our feelings when testing and could this provide us with any useful information about the product we are testing. Could it prove to be a useful oracle when testing?
On twitter @testsidestory said the following:
That is done regularly in usability labs: capture emotions and facial expressions of the users as they use the s/w
This was in response to a question that I posted on twitter:
…. - what I am thinking is that we need to capture our mood when #testing it could indicate a problem in the s/w…
The concern with this is that it would be very expensive to implement for the majority of people. I thought how we could implement a system that could capture emotional state and be effective and inexpensive.
One idea I had was to use a concept from the book Blink by Malcolm Gladwell, in which Malcolm talks about how important our initial emotion/reaction is when we first encounter something. There is a discussion about how often our ‘gut reaction’ proves to be correct and he uses an example of a statue that a gallery had bought after a lot of scientific experts, who had tested the statue, had said the statue was genuine. A couple of art experts who got to see the statue before it was unveiled in private viewings had a ‘feeling; that there was something wrong about the statue, their initial gut reaction was telling them it was a fake. Several months latter it was discovered to be a fake.
The above is a concise retelling of the story within the book, however why did the scientific experts get it so wrong? Could it be that conformation bias played a part? The scientific experts wanted so much to believe that it was real and not fake they caused bias in the results or avoided obvious facts that pointed to it being a fake. I think confirmation bias is a great subject and one I will look at from a testing perspective sometime in the future.
I should state that I have not tried any the following ideas and that if anyone would love to volunteer within their organizations to ‘trial’ the ideas out I would be most interested. Due to circumstances I currently do not have the ability to try this out on a large scale.
The first problem we face is how we capture out initial reaction to what we are testing. The requirements for this are that it is:
My thought is to use different smiley’s which are simple and quick to create and capture thus covering all the requirements.
My idea would be to use three different smiley’s:
Why use smiley’s?
The idea as to why use smiley’s is that anyone can draw them no matter how artistic and from the perspective of measurements it is very easy to recognize and see pasterns when using such well known symbols. The other longer term thought was that it is easy to extend to add sad, angry, and extremely happy if you wish to improve the range of emotions and feelings.
Capturing the initial feeling/emotion.
If you are working in an environment in which you are carrying out exploratory testing and following mission statements (Session based testing) then this is very simple to implement. The idea is that when the tester starts their mission (session) they should within the first couple of minutes (5 at a max) record their emotion/feeling of the software by the use of the smiley’s.
If this was done for every session being run and captured in such a way that it would be easy to see at a glance which areas (test charters) testers are unhappy with it could provide some useful information.
So you now have a whole set of data with regards to the testers initial feeling about the software there are testing, what does this information tell you?
For example a certain test focus area shows that all the testers are unhappy in that area would this indicate a problem? I feel it could indicate something wrong in that area but you would need to talk to the testers and gather more information (obtain context) I think the great thing about capturing initial feelings towards the software could help the development teams to focus on areas where there could be implied problems based upon initial feeling.
This approach could be taken a step further and get the testers to add another smiley when they have finished the session to see how they feel about the software after they have finished their session. You now have two sets of data and can compare any discrepancies with the two.
What would you think if the majority of testers were happy about a certain test focus area but at the end of the session they were unhappy?
Does this indicate a problem?
Or what if it was the opposite mostly unhappy and at end of session they were happy?
Also if they were unhappy at the beginning and at the end, their gut reaction proves to be correct, does this give an indicator that there are some major issues within that area?
Could this indicate frustration with the system, lack of knowledge maybe?
In my opinion this approach could provide to be a very useful oracle to the quality of the software.
What do think?
Could this prove to be useful?
I would love some feedback on this idea - good or bad.
On twitter @testsidestory said the following:
That is done regularly in usability labs: capture emotions and facial expressions of the users as they use the s/w
This was in response to a question that I posted on twitter:
…. - what I am thinking is that we need to capture our mood when #testing it could indicate a problem in the s/w…
The concern with this is that it would be very expensive to implement for the majority of people. I thought how we could implement a system that could capture emotional state and be effective and inexpensive.
One idea I had was to use a concept from the book Blink by Malcolm Gladwell, in which Malcolm talks about how important our initial emotion/reaction is when we first encounter something. There is a discussion about how often our ‘gut reaction’ proves to be correct and he uses an example of a statue that a gallery had bought after a lot of scientific experts, who had tested the statue, had said the statue was genuine. A couple of art experts who got to see the statue before it was unveiled in private viewings had a ‘feeling; that there was something wrong about the statue, their initial gut reaction was telling them it was a fake. Several months latter it was discovered to be a fake.
The above is a concise retelling of the story within the book, however why did the scientific experts get it so wrong? Could it be that conformation bias played a part? The scientific experts wanted so much to believe that it was real and not fake they caused bias in the results or avoided obvious facts that pointed to it being a fake. I think confirmation bias is a great subject and one I will look at from a testing perspective sometime in the future.
- So can we use this ‘gut reaction’ concept in testing?
- Would it be of any value?
I should state that I have not tried any the following ideas and that if anyone would love to volunteer within their organizations to ‘trial’ the ideas out I would be most interested. Due to circumstances I currently do not have the ability to try this out on a large scale.
The first problem we face is how we capture out initial reaction to what we are testing. The requirements for this are that it is:
- Easy to capture
- Simple
- Quick
My thought is to use different smiley’s which are simple and quick to create and capture thus covering all the requirements.
My idea would be to use three different smiley’s:
- Happy
- Neutral
- Unhappy
Why use smiley’s?
The idea as to why use smiley’s is that anyone can draw them no matter how artistic and from the perspective of measurements it is very easy to recognize and see pasterns when using such well known symbols. The other longer term thought was that it is easy to extend to add sad, angry, and extremely happy if you wish to improve the range of emotions and feelings.
Capturing the initial feeling/emotion.
If you are working in an environment in which you are carrying out exploratory testing and following mission statements (Session based testing) then this is very simple to implement. The idea is that when the tester starts their mission (session) they should within the first couple of minutes (5 at a max) record their emotion/feeling of the software by the use of the smiley’s.
If this was done for every session being run and captured in such a way that it would be easy to see at a glance which areas (test charters) testers are unhappy with it could provide some useful information.
So you now have a whole set of data with regards to the testers initial feeling about the software there are testing, what does this information tell you?
For example a certain test focus area shows that all the testers are unhappy in that area would this indicate a problem? I feel it could indicate something wrong in that area but you would need to talk to the testers and gather more information (obtain context) I think the great thing about capturing initial feelings towards the software could help the development teams to focus on areas where there could be implied problems based upon initial feeling.
This approach could be taken a step further and get the testers to add another smiley when they have finished the session to see how they feel about the software after they have finished their session. You now have two sets of data and can compare any discrepancies with the two.
What would you think if the majority of testers were happy about a certain test focus area but at the end of the session they were unhappy?
Does this indicate a problem?
Or what if it was the opposite mostly unhappy and at end of session they were happy?
Also if they were unhappy at the beginning and at the end, their gut reaction proves to be correct, does this give an indicator that there are some major issues within that area?
Could this indicate frustration with the system, lack of knowledge maybe?
In my opinion this approach could provide to be a very useful oracle to the quality of the software.
What do think?
Could this prove to be useful?
I would love some feedback on this idea - good or bad.
Friday, 16 July 2010
The Emotional Tester (PART 1)
This blog is going to be in two parts, the first will focus on the question of do emotions affect the quality of testing. The second will look at ways in which we can gather information about how we feel about the product we are testing to see if there is any value in capturing this information.
I have an amateur interest in psychology and how some of the ideas and thoughts from this area of science can be used in software testing. I was reading ‘The Psychology of Problem Solving’ by Janet E. Davidson & Robert J. Sternberg and it had a section on how emotions affect the way we think and focus.
So I decided to tweet a question based on some of the information I had read:
Emotions and #Testing:-Do we find more bugs when we are in a bad mood? Psychology research shows we are more negative when in bad mood.
It would be interesting to have feedback from #testing community on this - Does this mean a good tester has to be a grumpy so and so... :o)
It was not long before I started to receive replies on this.
@Rob_Lamber: @steveo1967 I don't really attribute negativity to being good at finding bugs. Positive attitude, passion, inclination...not negativity
@nitinpurswani I @steveo1967 i cannot think when i am in bad mood and i guess sapient testers think
@ruudcox @steveo1967 This article might help: Mood Literally Affects How We See World. http://www.medicinenet.com/script/main/art.asp?articlekey=100974
This turned in to a lively debate on which mood is better for testing.
After reading various articles there appeared to be some common ground on how we think and see things based upon our emotions and mood.
Looking at the article suggested by @ruudox this suggested that when in a good mood we can see the whole picture and when in an unhappy mood we narrow our focus.
This appears to be backed up by research from Foless & Schwarz
Individuals in a sad mood are likely to use a systematic, data driven bottom-up strategy of information processing, with considerable attention to detail In contrast, individuals in a happy mood are likely to rely on pre-existing general knowledge structures, using a top-down heuristic strategy of information processing, with less attention to detail (foless & Schwarz, 1999;).
This now leads to some complex dilemmas, and the whole point of this blog.
Which mood is best for someone whose is a professional tester?
Which mood is more than likely to find more bugs when testing?
What other influences can affect our ability to test well?
My thoughts indicate from the information and research I have read that to be really good at testing and finding defects we need to be in a sad or unhappy mood.
Research concludes that when in a sad or unhappy mood we are more than likely to focus in on the task and step though in a data driven way. When happy we are more than likely to see the whole of the picture and look at the task from a top down approach.
Now in my opinion both of these traits are needed to be excellent testers. So do testers need to have split personalities that they can switch on or off?
The point made by @nitinpurswani about being in a bad mood stops him thinking and that to be a sapient tester he needs to think. This got me thinking and I asked him a question back.
@nitinpurswani I like that idea. However if you're in a bad mood with what u are #testing would it make you want to break it more?
My thought behind this is that if something is annoying me or irritating me I feel I am more than likely work harder to find out why it is annoying me. I become deeply focused on the problem in front of me. Does this mean I am in a bad mood? Not necessarily so – it could be I am annoyed at what I am testing but not in a bad mood in general.
When in a happy mood when testing it is easy to just let things go, we unconsciously think well that is not too much of problem we can forget about it. This is a dangerous attitude to have as a tester because this simple little problem can come back to be huge problems. Someone in an unhappy mood is more than likely to investigate why this thing is annoying and find the underlining cause.
@Rob_Lambert made a very valid point that there are environmental issues that could come into play. How many testers when testing listen to music? Rob suggested that the type or style of music you are listening to can influence the mood you are in and as a side effect the way you are thinking. I had not thought about this very much but going deeper than this – if you are working in a open office and everyone around you is having a laugh and joking would this make your testing better or worse? What if a tester and a developer are having a heated debate about something that has just been tested? Will this influence your testing?
Does any of this article back up my earlier tweet that testers need to be grumpy so and sos?
However I think this view is too simplistic. I am often asked about testers and how they are different from developers. (There is still a big drive within testing that developer and tester can be the same person and be able to switch between the different roles). I have a feeling that some of the best testers can switch between different psychological emotional states when testing. They have the best of both worlds. Able to remain focused when something is bugging them and then when they have solved what is bugging them able to switch to a whole picture view of the system they are testing.
When I started to write this article I thought it would be very simple to come to a conclusion about how emotions can affect our ability to test and what is the best mood to be in to get the best out of testing. It has proven more difficult than I thought and I still have not come to any firm conclusion about which is the best.
The one interesting point that should be made is that as professional testers we need to be aware of our emotions and how they can affect the quality of the testing we are doing. Part 2 of this blog will be looking at how we can capture our emotion and feelings about the product we are testing and see if this could provide useful information.
I have an amateur interest in psychology and how some of the ideas and thoughts from this area of science can be used in software testing. I was reading ‘The Psychology of Problem Solving’ by Janet E. Davidson & Robert J. Sternberg and it had a section on how emotions affect the way we think and focus.
So I decided to tweet a question based on some of the information I had read:
Emotions and #Testing:-Do we find more bugs when we are in a bad mood? Psychology research shows we are more negative when in bad mood.
It would be interesting to have feedback from #testing community on this - Does this mean a good tester has to be a grumpy so and so... :o)
It was not long before I started to receive replies on this.
@Rob_Lamber: @steveo1967 I don't really attribute negativity to being good at finding bugs. Positive attitude, passion, inclination...not negativity
@nitinpurswani I @steveo1967 i cannot think when i am in bad mood and i guess sapient testers think
@ruudcox @steveo1967 This article might help: Mood Literally Affects How We See World. http://www.medicinenet.com/script/main/art.asp?articlekey=100974
This turned in to a lively debate on which mood is better for testing.
After reading various articles there appeared to be some common ground on how we think and see things based upon our emotions and mood.
Looking at the article suggested by @ruudox this suggested that when in a good mood we can see the whole picture and when in an unhappy mood we narrow our focus.
This appears to be backed up by research from Foless & Schwarz
Individuals in a sad mood are likely to use a systematic, data driven bottom-up strategy of information processing, with considerable attention to detail In contrast, individuals in a happy mood are likely to rely on pre-existing general knowledge structures, using a top-down heuristic strategy of information processing, with less attention to detail (foless & Schwarz, 1999;).
This now leads to some complex dilemmas, and the whole point of this blog.
Which mood is best for someone whose is a professional tester?
Which mood is more than likely to find more bugs when testing?
What other influences can affect our ability to test well?
My thoughts indicate from the information and research I have read that to be really good at testing and finding defects we need to be in a sad or unhappy mood.
Research concludes that when in a sad or unhappy mood we are more than likely to focus in on the task and step though in a data driven way. When happy we are more than likely to see the whole of the picture and look at the task from a top down approach.
Now in my opinion both of these traits are needed to be excellent testers. So do testers need to have split personalities that they can switch on or off?
The point made by @nitinpurswani about being in a bad mood stops him thinking and that to be a sapient tester he needs to think. This got me thinking and I asked him a question back.
@nitinpurswani I like that idea. However if you're in a bad mood with what u are #testing would it make you want to break it more?
My thought behind this is that if something is annoying me or irritating me I feel I am more than likely work harder to find out why it is annoying me. I become deeply focused on the problem in front of me. Does this mean I am in a bad mood? Not necessarily so – it could be I am annoyed at what I am testing but not in a bad mood in general.
When in a happy mood when testing it is easy to just let things go, we unconsciously think well that is not too much of problem we can forget about it. This is a dangerous attitude to have as a tester because this simple little problem can come back to be huge problems. Someone in an unhappy mood is more than likely to investigate why this thing is annoying and find the underlining cause.
@Rob_Lambert made a very valid point that there are environmental issues that could come into play. How many testers when testing listen to music? Rob suggested that the type or style of music you are listening to can influence the mood you are in and as a side effect the way you are thinking. I had not thought about this very much but going deeper than this – if you are working in a open office and everyone around you is having a laugh and joking would this make your testing better or worse? What if a tester and a developer are having a heated debate about something that has just been tested? Will this influence your testing?
Does any of this article back up my earlier tweet that testers need to be grumpy so and sos?
However I think this view is too simplistic. I am often asked about testers and how they are different from developers. (There is still a big drive within testing that developer and tester can be the same person and be able to switch between the different roles). I have a feeling that some of the best testers can switch between different psychological emotional states when testing. They have the best of both worlds. Able to remain focused when something is bugging them and then when they have solved what is bugging them able to switch to a whole picture view of the system they are testing.
When I started to write this article I thought it would be very simple to come to a conclusion about how emotions can affect our ability to test and what is the best mood to be in to get the best out of testing. It has proven more difficult than I thought and I still have not come to any firm conclusion about which is the best.
The one interesting point that should be made is that as professional testers we need to be aware of our emotions and how they can affect the quality of the testing we are doing. Part 2 of this blog will be looking at how we can capture our emotion and feelings about the product we are testing and see if this could provide useful information.
Sunday, 11 July 2010
Managing Exploratory Testing with Mercury Quality Center
I thought I would write about my experiences of using Mercury Quality Center (MCQ) to help manage my exploratory testing sessions
When carrying out exploratory testing I use the James and Jon Bach approach of Session based testing (http://www.satisfice.com/sbtm/). What I found is that the tool provided did not match the needs of the company and was hard to sell to management since we already had commercial tools for capturing testing effort (MQC). I had to re-think how I could get buy-in from management on using the exploratory testing approach whilst making use of the tools we already had.
One of the first things I did was implement a structure within the test plan section of MCQ. So I defined the following folder structure for each project
Project Name
Test Charter
Mission Statement
Test Ideas
e.g.
Project Name -->
Test Charter -->
Mission Statement -->
Test ideas(s)
So under the planning section testers can define a folder name for the test charter they are working on and then add a folder for each mission statement and then add their test ideas.
The thinking behind this was at a glance anyone can see what has been covered under each test charter and see if their any gaps. Reports can be pulled off and used during debrief sections to act as focus points when discussing the testing that has been done.
I created a Test Plan Hierarchy using a standard numbering scheme for the folder and test idea names. This helped with traceability and navigation around the test plan.
e.g.
Project Name -
01 – Test Charter 01 -->
01.01 – Mission Statement 01
01.01.01 – Test Idea 01
01.01.02 – Test Idea 02
01.02 – Mission Statement 02
01.02.01 – Test Idea 01
01.02.02 – Test Idea 02
02 – Test Charter 02 -->
02.01 – Mission Statement 01
02.02.01 – Test Idea 01
02.02.02 – Test Idea 02
MQC is setup for a formal test case and test step scripted form of testing, I have not found a way to get around this however instead of test cases I use test ideas and needed a quick way to create new test ideas without being bogged down in writing details about lots of steps. So I suggested that each test idea has ONLY the following information:
- Test Idea Name
- Test Idea description (This should be as descriptive as possible – include any models/heuristic thinking/problem solving ideas)
- A single test step - This is required by MQC so that the user can run the test and record its status (Pass/Fail etc)
Since we use a different system for capturing defects (Don’t ask!) I also added a folder to each project called 99- Defects – so that I could trap any defects that needed testing.
The next step was to have a structure for the test lab (this is where details of tests are run)
I implemented the following structure:
Project Name -->
Project Release Version X.Y -->
01.01 - Mission Statement 01 -->
01.01.01 - Test idea 001
01.01.02 - Test case 002
01.02 - Mission Statement 02 -->
01.02.01 - Test idea 001
01.02.02 - Test case 002
It is recommended that X.Y numbers in Project Release Version name are provided as a multiple digit left zero padded integers. This is to ease sorting by name. This was basically copied over from the test plan section.
For exploratory testing I suggested that as a minimum the following columns are included when recording the execution of the test idea.
- Plan.Test Name
- Result
- Defect (For recording CQ defects raised within that test script)
- Priority * (How important is this test idea , what risk is it to the project by not doing this test idea)
- Status
- Execution Date
Once this had been setup it was then easy to run a session based upon a mission statement for the session I was running. Each mission statement had multiple test ideas. I found this very useful since it was very quick to create test focus areas based upon test charter names and mission statements. These could then very simply be turned into session sheets within MQC test lab.
One of the key elements of session based testing is to capture what all the evidence of the exploratory testing session. I implemented the following to capture details of what went on the testing session. Each test idea was run from within MQC and recorded if that test idea passed or failed. (I am aware this can be very subjective and depends on context however to ease transient to ET it is necessary to have some familiar ways of recording progress). I ensured that all session notes, log captures, screen prints, videos etc were captured by attaching them to the test idea.
THIS was very IMPORTANT – since if anyone needs to follow your test idea in the future they now have a record of what and HOW you executed your test idea. This is an issue with biases here and people carrying out testing afterwards could just follow your notes and repeat what you did which is not really exploratory testing but that can be mitigated by mentoring.
You now have a tool in which you can capture what you have done during your exploratory testing sessions.
There are a few issues I find with MQC and I am sure people out there in the testing community may have the answers. I want to use MQC to record the time spent on each session (As short, medium, long). I also I wanted to capture how much as a percentage of that time was spent on:
- Test execution
- Bug reporting and investigation
- Test environment set up
- Test data setup
This would help in the telling of the story of what is stopping the testers actually testing. I am sure there is a way to do this is MQC and I just need to do some more investigation. I hope readers of this find it useful, I know it has helped me to persuaded management to take exploratory testing seriously.
To finish this is working for me, it is not perfect and I am investigating other ways/tools that can make this more efficient. Looking at using a java application to create the session sheets and report back via the MQC API directly – but that is in the future. I am also investigating ways to customize MQC so that I can have the columns I wish to have. I will let you know it that works.
Friday, 25 June 2010
Testers are the bearers of Bad News
I read an interesting blog by James Christine yesterday (24-06-2010) (http://clarotesting.wordpress.com/2010/06/23/challenging-the-culture/) in which organizations which promote a positive/good news culture could be doing themselves harm by trying to encourage people not to report any bad news and how dangerous this is. I loved the alternative take on this and it got me thinking about a blog post I intended to do about how testers are perceived as the bearers of bad news and how we could change this perception. The article by James has spurred me to put the blog together.
I have an amateur interest in psychology and human behaviour and as such I am fascinated by reading articles in which as a person we can learn to adjust our outward persona to help benefit ourselves and those around us. For example Beth Lane wrote an interesting article on perception checking: http://improving-relationships.suite101.com/article.cfm/improve_your_relationships
From such a small article I learnt a lot about myself and how others may perceive me. I use many methods to ensure I can communicate with others to the best of my ability. I apply this to my job as a software tester (note homage to Michael Bolton here not a QA - http://www.developsense.com/blog/2010/05/testers-get-out-of-the-quality-assurance-business/)
I try to have a good working relationship with software engineers/developers/programmers (still struggling with what these highly talented people want to be known as) since most of the time I go and speak to them it is to say something is not working or it has crashed.
I had an eureka moment one day and took a step back to see why the relationship between the testing team and the software development teams were fragile and highly strained. I put myself in the shoes of the development team and how they perceived the testing team I asked the team how they felt about the testers and the responses I received all seemed to have a common ground.
‘I get a feeling of here we go again whenever a testers phones or comes to see me’
‘I dread it when a tester comes to see me’
‘They are always complaining that something does not work’
‘They only phone me when something goes wrong’
It got me wondering about how as testers we could improve this critical relationship and form a much better relationship. I thought that if everyday the same people are visiting/phoning me and giving me bad news I would soon develop a negative perception of those people.
So what can be done to change this?
I decided to try something a little different – someone once said from small acorns mighty oaks grow. I decided that instead of phoning or visiting the software development team when I had a problem I found the time to go and visit and ask how their weekend was or how the family is or what they thought of such and such in the news just a general chit-chat. One important thing I made sure I never did was to start to talk about general things and then say ‘Oh by the way … such and such does not work’ I cannot emphasize enough NOT to do this. My reasoning behind this was to build up a relationship and stop the feeling of dread when I turned up that something was wrong again.
The effect of this was amazing, the development team soon started to say hey have you seen this we are working on and start to talk with a passion about what they were working on. From a testing viewpoint this is valuable knowledge gathering. The attitude of the development team changed, when I did contact the team with a problem or something was wrong they would listen, emphasize and take a real interest in the problem rather than just dismiss it. The relationship between the teams improved tremendously.
So to conclude as a tester you do not need to always be the bearer of bad news to the development team. Take an interest in them as a person, take an interest in their lives and what they enjoy, take the time to learn about the people you work with. The benefits could be outstanding.
A word of caution on this – it has to be genuine – you really do need to be interested when you are talking to people about their personal lives. Otherwise you will come across as being cynical and shallow. If this happens then I am afraid you will cause an even bigger resentment and maybe even hatred of you.
I have an amateur interest in psychology and human behaviour and as such I am fascinated by reading articles in which as a person we can learn to adjust our outward persona to help benefit ourselves and those around us. For example Beth Lane wrote an interesting article on perception checking: http://improving-relationships.suite101.com/article.cfm/improve_your_relationships
From such a small article I learnt a lot about myself and how others may perceive me. I use many methods to ensure I can communicate with others to the best of my ability. I apply this to my job as a software tester (note homage to Michael Bolton here not a QA - http://www.developsense.com/blog/2010/05/testers-get-out-of-the-quality-assurance-business/)
I try to have a good working relationship with software engineers/developers/programmers (still struggling with what these highly talented people want to be known as) since most of the time I go and speak to them it is to say something is not working or it has crashed.
I had an eureka moment one day and took a step back to see why the relationship between the testing team and the software development teams were fragile and highly strained. I put myself in the shoes of the development team and how they perceived the testing team I asked the team how they felt about the testers and the responses I received all seemed to have a common ground.
‘I get a feeling of here we go again whenever a testers phones or comes to see me’
‘I dread it when a tester comes to see me’
‘They are always complaining that something does not work’
‘They only phone me when something goes wrong’
It got me wondering about how as testers we could improve this critical relationship and form a much better relationship. I thought that if everyday the same people are visiting/phoning me and giving me bad news I would soon develop a negative perception of those people.
So what can be done to change this?
I decided to try something a little different – someone once said from small acorns mighty oaks grow. I decided that instead of phoning or visiting the software development team when I had a problem I found the time to go and visit and ask how their weekend was or how the family is or what they thought of such and such in the news just a general chit-chat. One important thing I made sure I never did was to start to talk about general things and then say ‘Oh by the way … such and such does not work’ I cannot emphasize enough NOT to do this. My reasoning behind this was to build up a relationship and stop the feeling of dread when I turned up that something was wrong again.
The effect of this was amazing, the development team soon started to say hey have you seen this we are working on and start to talk with a passion about what they were working on. From a testing viewpoint this is valuable knowledge gathering. The attitude of the development team changed, when I did contact the team with a problem or something was wrong they would listen, emphasize and take a real interest in the problem rather than just dismiss it. The relationship between the teams improved tremendously.
So to conclude as a tester you do not need to always be the bearer of bad news to the development team. Take an interest in them as a person, take an interest in their lives and what they enjoy, take the time to learn about the people you work with. The benefits could be outstanding.
A word of caution on this – it has to be genuine – you really do need to be interested when you are talking to people about their personal lives. Otherwise you will come across as being cynical and shallow. If this happens then I am afraid you will cause an even bigger resentment and maybe even hatred of you.
Thursday, 24 June 2010
Training in India
I recently ran an exploratory testing workshop in India and I thought I would blog about this experience.
There are many differing views about Indian software development teams, some which are unfounded and some that are characteristics of the working style of Indian teams.
From my experience of working with many different teams around the world the statement above can really be applied to any team no matter where they are in the world how people interact and their style of working is dependent on their culture and way of working.
The workshop I was running had a lot of interaction and required engagement from those attending otherwise it is hard to gauge if the audience understands what you are trying to deliver. I was worried due to what I had been informed about the culture within India that there would be little if any engagement and everyone would agree with what I was saying, even if what I was saying was wrong. (I like to set little traps in my presentations and say things which anyone in testing will know is stupid and start a debate.)
I remembered an article that Jon Bach had written about his viewpoint on working with Indian testers and how he ended up making an apology. (http://jonbox.wordpress.com/2009/12/17/to-india-an-apology/). This article was KEY in how I ended up presenting the workshop to the teams in India.
So taking on board the lessons Jon had learnt I started to change my presentation a little to become more personal more about who I was rather than what I was trying to deliver.
I changed the start of the presentation and included a lot of personal information about myself including photos which I had of my family. When I started to run the workshop I explained that this was just an approach, a possible way of working I was not going to say to anyone attending that this is how you MUST do things and if you disagree with anything I am saying then please let me know. I then spent the next 20-30 minutes explaining about myself and my family. I think that this part was the key element – the need to reach out to the India team on a personal level, family in India culture is very important (Joint Family). I talked about our daughter and granddaughter coming to live with us when her husband was away for six months with the army and lots more. I then asked people attending to talk about themselves and their families. Suddenly the atmosphere in the room changed it become more relaxed and people appeared more receptive.
Can this one little change make such a difference?
So I begin delivering the workshop and found the engagement and interaction of those attending to be amongst the best I have come across whilst I have been delivering this workshop. There was passion, interaction, thoughtful questions and in some cases surprising answers. In my opinion it was one the best workshops I have ever been involved with.
Was I just lucky?
If I had not changed the start of the presentation would I have still ended up with the same reaction and interaction?
I cannot really say since I have no comparison – this was a one chance to deliver to a team in India, I was on a tight schedule, so it was important to get it right.
I really must say a big thank you to Jon Bach, since without reading about his experience I think I would have blindly gone and presented and not got the response I required nor would anyone have really learnt anything.
So the tip for anyone working or dealing with teams from India is to make sure you can engage with them on a personal level , open up and let people know who you really are.
There are many differing views about Indian software development teams, some which are unfounded and some that are characteristics of the working style of Indian teams.
From my experience of working with many different teams around the world the statement above can really be applied to any team no matter where they are in the world how people interact and their style of working is dependent on their culture and way of working.
The workshop I was running had a lot of interaction and required engagement from those attending otherwise it is hard to gauge if the audience understands what you are trying to deliver. I was worried due to what I had been informed about the culture within India that there would be little if any engagement and everyone would agree with what I was saying, even if what I was saying was wrong. (I like to set little traps in my presentations and say things which anyone in testing will know is stupid and start a debate.)
I remembered an article that Jon Bach had written about his viewpoint on working with Indian testers and how he ended up making an apology. (http://jonbox.wordpress.com/2009/12/17/to-india-an-apology/). This article was KEY in how I ended up presenting the workshop to the teams in India.
So taking on board the lessons Jon had learnt I started to change my presentation a little to become more personal more about who I was rather than what I was trying to deliver.
I changed the start of the presentation and included a lot of personal information about myself including photos which I had of my family. When I started to run the workshop I explained that this was just an approach, a possible way of working I was not going to say to anyone attending that this is how you MUST do things and if you disagree with anything I am saying then please let me know. I then spent the next 20-30 minutes explaining about myself and my family. I think that this part was the key element – the need to reach out to the India team on a personal level, family in India culture is very important (Joint Family). I talked about our daughter and granddaughter coming to live with us when her husband was away for six months with the army and lots more. I then asked people attending to talk about themselves and their families. Suddenly the atmosphere in the room changed it become more relaxed and people appeared more receptive.
Can this one little change make such a difference?
So I begin delivering the workshop and found the engagement and interaction of those attending to be amongst the best I have come across whilst I have been delivering this workshop. There was passion, interaction, thoughtful questions and in some cases surprising answers. In my opinion it was one the best workshops I have ever been involved with.
Was I just lucky?
If I had not changed the start of the presentation would I have still ended up with the same reaction and interaction?
I cannot really say since I have no comparison – this was a one chance to deliver to a team in India, I was on a tight schedule, so it was important to get it right.
I really must say a big thank you to Jon Bach, since without reading about his experience I think I would have blindly gone and presented and not got the response I required nor would anyone have really learnt anything.
So the tip for anyone working or dealing with teams from India is to make sure you can engage with them on a personal level , open up and let people know who you really are.
Thursday, 10 June 2010
The story of organizing a charity event.
*********
I think I may have been a little remiss over the past couple of month by not updating my blog as much as I should be. I see posts by other great bloggers appearing every week or two but mine appear about once a month. I thought I would take time away from testing issues and blog the reason why I have not been as actively involved in the testing community as I would like to have been. This is a subject close to my heart and some may read and feel it is a little self indulgent however the cause IMO is more than worthwhile.
On Saturday 5th of June 2010 my wife and I organized in conjunction with the Amateur Poker Players League Europe (APPLE)
a poker tournament at the Prince of Wales Pub, Bishopstoke, Eastleigh to raise money for the Help for Heroes Charity.
Apart from running the main poker tournament we had a pool tournament, a raffle and various other fun events. The support of local business was outstanding and overwhelming they could not do enough to help and given the current economic climate it was extremely humbling It was a different story with the large companies who I shall not name here who were not interested at all so when you think you need to pop out to get a pint of milk or buy something try to think of your local community businesses first rather than the big uninterested corporations.
The reasoning behind this is that our son-in-law (Lance Corporal Matthew Wellington) who is in the Royal Engineers returned from his tour of Afghanistan. His role with the Royal Engineers is with the EOD (Explosive Ordnance Disposal,) which as you can imagine is a highly dangerous and stressful job. He has a daughter who is now 2 years old and unfortunately has only seen her daddy for about 1 year of her life since this is Matthews’s second six month tour of Afghanistan within two years.
He has done his duty whilst the family at home, apart from the natural worry, felt helpless, so organized this day to help provide something back to those who are serving and the unfortunate ones who return injured. During his current tour he had to go through the trauma of losing some colleagues and a few who came back suffering from horrific injuries.
So you can imagine my wife Tracy and I had lots to organize and do, which took our minds away from the worry of our son-in-law whilst he was on tour, dreading watching the news and of hearing another member of the armed forces had been injured or killed. It has been a very stressful time and to be able to do something good has helped a great deal. At the end of the day the final amount we raised for this cause was over £1500.00 not bad for a single day event.
Part of this blog is to raise awareness of Help for Heroes and all that they do. They are not politically motivated and are doing a wonderful job and ensuring members of the UK armed forces are rehabilitated in an environment suitable for such heroes. SO if nothing else after reading this blog please visit the Help for Heroes website and maybe just maybe make a small donation.
Subscribe to:
Posts (Atom)