Introverts and Extroverts - stop labeling yourself.

This post maybe a little controversial and uncomfortable to some readers.  As social creatures we like to label ourselves as certain types.  We like to be part of groups, tribes and social circles. The issue is when we, or others, use these types to defining ourselves and limit our potential.

The focus of this article is looking at two specific personality types which always seem to pop up in conversations.

'Oh I am an Introvert"

'They are they the life and soul of the party, surely they are an extrovert'

If we ignore the fact that most personality testing are flawed, especially Myers-Briggs

"Generally, although not completely unscientific, the MBTI gives a ridiculously limited and simplified view of human personality," Nothing personal: The questionable Myers-Briggs test - Bean Burnett - The Guardian - March 2013" 

 Then what we are left with is the human desire to 'fit in' and be part of a group.  At the same time by using these labels we can provide excuses for our behavior.

What does it really mean when we say Introvert or Extrovert.

The merriam webster dictionary defines them as follows:

Introvert -  a shy person : a quiet person who does not find it easy to talk to other people
http://www.merriam-webster.com/dictionary/introvert

Extrovert -  a friendly person who likes being with and talking to other people : an outgoing person
http://www.merriam-webster.com/dictionary/extrovert

For those people who know me personally, how would you label me?

I am sure the majority would define me as an extrovert, an outgoing person who like to socialize and talk to others.

However there are times and situations in which I can by shy and find it difficult to talk to others.  For example at large social gathering I can become very inward.  A recent example of this was at Testbash in Brighton where they organize a social event by the beach.  I find these situations very difficult and draining.  I put on a brave face but inwardly I just want to run and find a quiet corner  and be by myself.  The classic signs of an introvert?  Then the next day I am on stage in front of 200 plus people giving a talk and feeling wonderful, relaxed and enjoying the moment.  Wow now I am classed as an extrovert!

For me the key here is we need to stop limiting ourselves by defining our behavior with a label.   Depending on the context you can be an introvert or extrovert, and there is nothing wrong with that.  However if you use these labels to the extreme you could limit opportunities, growth and fulfilling your true potential.  Throw away the label and use your instinct to drive what you want to achieve and then anything could be possible.

Oh and a message to those who work in HR please stop using personality tests to meet some unreasonable arbitrary 'will they fit' tick box.  You may be excluding people just because of how they feel on that day rather than based upon the merits and skills  of the individual.

This article was first publish in Jan 2015 on the Ministry of Testing Website - http://www.ministryoftesting.com/2015/01/qualitative-research-coding-software-testing/

Qualitative Research Coding and Software Testing

Coding is used extensively in the field of social science for qualitative analysis.  Coding is not defined in the same ways as it is for software development.  The following quote by Saldaña provides a useful definition of coding within the social science world:

A code in qualitative inquiry is most often a word or short phrase that symbolically assigns a summative, salient, essence capturing, and/or evocative attribute for a portion of language-based or visual data  [1]

“By “language-based or visual data”, Saldaña means video, audio recordings or written notes.   Once the information has been gathered the researcher then assigns ‘a word or a short phrase’ to represent sections of the data. Then the researcher examines and categorises the codes to see what patterns and theories emerge.  These activities together are known as qualitative research coding.   For example if a researcher were studying the morals of teenagers, the researcher would record conversations and then use coding activities to see what patterns emerge.  Based upon these patterns the researcher would form theories about the morals of teenagers.

Testers using this type of coding may find it helps to label; organise and classify their testing observations.  It provides structure not only to the testers’ observations, but also to the process of observing.  Observation and gathering information are important aspects of testing.

The changing minds website describes qualitative coding as:

Coding is an important technique in qualitative research such as anthropology [2), ethnography [3] and other observer and participant-observer methods. [4]

Strauss stressed the importance of coding when carrying out qualitative analysis:

Any researcher who wishes to become proficient at doing qualitative analysis must learn to code well and easily. The excellence of the research rests in large part on the excellence of the coding. [5]

The same can be applied by testers when analysing their testing effort, there is a need as a tester to be able to ‘code well and easily’. Testers should examine the testing evidence that has been gathered and use coding to formulate flexible theories and ideas of the behaviour of the software.

There appears to be some comparisons between qualitative research coding and exploratory testing [6]; the table below describes some of these comparisons.

Social Science	Exploratory Testing
Evidence based upon immersion in the culture under investigation	Evidence based upon exploring the software under test
Theories formed based upon the evidence gathered during immersion	Theories formed based upon the evidence gathered during exploration
Theories adjusted and altered as new evidence is gathered	Theories adjusted and altered as new evidence is gathered
Further investigations take place to uncover evidence that may support or disprove current theories	Further exploration takes place to uncover evidence that supports or disproves current thinking about the behavior of the software under test
Coding and classifications of evidence to identify patterns	Coding of evidence from exploratory sessions to identify patterns and risks

Table of comparisons between social science research methods and exploratory testing

Testers can utilise social science coding to analyse the testing evidence gathered to help form theories about the behaviour of the software. These theories can be presented to stakeholders to provide valuable information and support decision-making.

When people first start to use social science coding they can find it complex and daunting.  To help simplify coding Chris Hann created the following diagram:

Coding pyramid [7]

The diagram shows the different levels of coding that social scientists go through to form and reform theories.

Testers can use social science coding not only for test execution, but also for other testing activities such as test planning, testing discussion and test reporting.

Coding in action

The following is an example of using level 1 coding for user stories.

User Story

As a user

I want to login in securely

So that my private information is kept private

A tester using coding uses the following codes for this user story. (Each code is separated by the | symbol)

Codes

Security | Login | Operations |Function

The tester then looks at more user stories and codes:

User Story

As a user

I want to record a currently playing live show

So that I can watch the show at a later time

Codes

Recording | Live TV | Device Remote | Operations | Data |Time | Platform | Functions

User Story

As a user

I want to playback a currently recorded show

So that I can watch the recorded show now

Codes

Recording | Playback | Device Remote | Operations |Time | Data | Structure | Interface

The examples above make use of the SFDPOT [8] heuristic.  This heuristic is a useful way of utilising social science coding to identify testing coverage gaps.   When coding it is acceptable to assign multiple codes to each piece of information or evidence gathered.

1. The process of coding can be defined in the following steps: (taken from [9])
2. Decide which types of coding are most relevant
3. Start coding
4. Create a start list of codes
5. Generate categories (pattern codes)
6. Test these categories against new data (start with contrasting data early on!)
7. Write about categories/pattern codes in a memo to explain their significance

The following is an example of a tester using these steps:

The testers’ initial testing effort showed that a particular API appeared to work correctly with the customer data set used.  The tester coded this as ‘API interface: customer data set ingests’.  The tester formed a theory that the API had been implemented and appeared to work for that data set. The tester then tested their theory using a different customer data set and the behaviour was inconsistent, this led to a change in the testers’ theory based upon the evidence gathered. This is level 2 and 3 on the coding pyramid diagram.

Memos and questioning

Testers when carrying out coding can use ethnographic research methods [10] by asking themselves the following questions.

• What is the software doing?
• What is the software trying to accomplish?
• How does the software accomplish this?
• Does the user understand what is being accomplished?
• What assumptions does the software make about the user?
• What surprises you about how the software is behaving?
• What do I see going on here? (To track your assumptions)
• What did I learn from the notes I have taken?
• What intrigued me? (To track your positionality [11] – where do you stand, what biases could be at play?)
• What disturbed me? (To track your tensions, beliefs, attitude)

These questions have been adapted based upon work by (Sunstein and Chiseri-Strater, 2007: 106) Field Working: Reading and Writing Research. [12]

Categorisation, level 4 on the coding pyramid, is the concept of tying together a number of observations and seeing if they have any common characteristics. These characteristics or connections in social science coding terms are called memoing.

Glaser defines memoing as:

(A memo is) the theorising write-up of ideas about codes and their relationships as they strike the analyst while coding… it can be a sentence, a paragraph or a few pages… it exhausts the analyst’s momentary ideation based on data with perhaps a little conceptual elaboration (Glaser, 1978: 83) [13]

The following gives a testing example of this:

After testing a User Interface, the tester defines the following codes from the gathered testing evidence:

UI inconsistent | error messages unclear | undermined feature behavior

The tester memos these codes as ‘unwarranted user behaviour.’ Ideally though, the tester should write more detailed memos than the example given.  The purpose of a memo is to write down your thoughts and reflections on the information you have gathered.

The more extensive the testers’ memos are the more they can form concrete theories.  This aspect of coding can prove to be valuable for testers, since the completed memos can be used as evidence of what the system they are testing is really doing.

Coding can be used when analysing the evidence gathered during testing; the tester can group together and code similar behaviours and observations to see if there are any patterns.  These patterns can be used by the tester to guide their testing effort and provide focus for areas that they may find useful to explore.

Ian Day in his book Qualitative Data Analysis – A user friendly guide for social scientists [14] makes the following statement about coding.

The term ‘coding’ has a rather mechanical overtone quite at odds with the conceptual tasks involved in categorising data. This arises from the association of coding with a consistent and complete set of rules governing the assignment of codes to data, thereby eliminating error and of course allowing recovery of the original data simply by reversing the process (i.e. decoding). Qualitative analysis, in contrast, requires the analyst to create or adapt concepts relevant to the data rather than to apply a set of pre-established rules.

Since coding is a conceptual approach, having pre-defined rules or processes before the tester has the evidence is not something that fits easily in to a qualitative research approach.   Codes are relevant to the actual evidence that has been gathered rather than based upon assumptions of what that evidence may be.

Summary

The use of qualitative coding in testing provides many benefits that testers can utilise across all testing activities, some of these benefits include:

• Pattern Recognition
• Theory Forming
• Critical Thinking
• System Thinking
• Testing Gap Analysis
• Meaningful reporting
• Evidence gathering

Learning about social science coding and applying it in practice can be a powerful tool in a testers testing skills portfolio.  Those who promote that testers should learn to code are correct; nevertheless they may want to explore alternative coding approaches.

For those who wish to learn more about the connection between social science and software testing I recommend the following articles and books as useful starting points:

• A complete beginner guide to qualitative analysis – Taylor and Graham R. Gibbs University of Huddersfield (web site)
• Analysis of Qualitative Data for Beginners – Demola Akinyoade – Department of Peace and Conflict Studies Afe Babalola University, 30th June 2005 (Web PDF)
• Software Testing as a Social Science – Cem Kaner – STEP 2008 (Slides)
• What Testers can learn from Social Sciences – Huib Schoots – TestBash 2.0 – 2013 (Video)
• What Testers can Learn from Social Sciences – Part 1 – Huib Schoots – 2013 (Series of Web Articles)
• Looking to Social Science for help with Metrics – Justin Rohrman – CAST 2014 (Video)

With special thanks and appreciation for their help and patience in making this a much more complete article than it was to begin with:

• Michael Bolton: http://www.developsense.com/ Twitter: @michaelbolton
• Huib Schoots: http://www.huibschoots.nl/wordpress/ Twiiter: @huibschoots
• Duncan Nisbit: http://www.duncannisbet.co.uk/ Twitter: @DuncNisbet

References

1. The Coding Manual for Qualitative Researchers – Saldaña, 2013 –http://www.amazon.com/The-Coding-Manual-Qualitative-Researchers/dp/1446247376
2. What is Anthropology – American Anthropological Association (website – Last accessed (Aug 2014) – http://www.aaanet.org/about/whatisanthropology.cfm
3. Brian A. Hoey. “A Simple Introduction to the Practice of Ethnography and Guide to Ethnographic Fieldnotes” Marshall University Digital Scholar (2014): 1-10. Available at:http://works.bepress.com/brian_hoey/12
4. Changing Minds – Ethnographic coding –http://changingminds.org/explanations/research/analysis/ethnographic_coding.htm
5. Qualitative Analysis for Social Scientists, 1987, p. 27 – Anselm L. Strauss –http://www.amazon.com/Qualitative-Analysis-Social-Scientists-Strauss/dp/0521338069
6. What is Exploratory Testing – James Bach –http://www.satisfice.com/articles/what_is_et.shtml
7. Techniques and Tips for Qualitative Researchers – Chris Hann –http://qrtips.com/faq/FAQ–code%20terms.htm
8. How Models Change – Michael Bolton –http://www.developsense.com/blog/2014/07/how-models-change/
9. 8 Qualitative codes and coding (2014) – Heather Fordhttp://www.slideshare.net/hfordsa/qualitative-codes-and-coding
10. Are testers’ ethnographic researchers? Stevenson (2011) –http://steveo1967.blogspot.com/2011/01/are-testers-ethnographic-researchers.html
11. What is positionality in practitioner research? – Dissertation Scholar (website Last accessed August 2014) http://dissertationscholar.blogspot.mx/2013/04/what-is-positionality-in-practitioner.html
12. Field working Reading and writing research – Sunstein and Chiseri-Strater (2007: 106) – http://www.amazon.com/FieldWorking-Reading-Writing-Research-Edition/dp/0312622759
13. Theoretical Sensitivity: Advances in the Methodology of Grounded Theory – Glaser (1978: 83) http://www.amazon.com/Theoretical-Sensitivity-Advances-Methodology-Grounded/dp/1884156010
14. Qualitative Data Analysis: A User Friendly Guide for Social Scientists – Ian Day (1993)http://www.amazon.com/Qualitative-Data-Analysis-Friendly-Scientists/dp/041505852
    X

Tacit and Explicit Knowledge and Exploratory Testing

"We can know more that we can tell". - Michael Polanyi(1966)

Having finally read the excellent book Tacit and Explicit Knowledge by Harry Collins which I personally found to make a significant impact on my thinking of how we learn and record information (knowledge).  The book is not an easy book to read and it took me a few times of re-reading some sections to work out what the author may have meant.  

I will start by saying that this article is based upon my own interpretation of the book and the links I make between what the author writes and what I connect with regarding testing are entirely my own and could be flawed.

So what do we mean when we say tacit and explicit knowledge means?

Harry Collins in his book describes in great detail what he means by these terms and I could not find a clear definition that would be useful for this article.  So I used some of the research references I had used when reading the book.  One of the better ones I came across was the following website 

Explicit Knowledge: Knowledge that is codified and conveyed to others through dialog, demonstration, or media such as books, drawings, and documents.

Tacit Knowledge: Deeply personal experience, aptitudes, perceptions, insights, and know-how that are implied or indicated but not actually expressed — it resides in individuals & teams.

The site also has a great diagram showing visually the difference in the amount of knowledge we have in each type with explicit being quite small part of our total knowledge and tacit being the majority.

Diagram from http://www.cognitivedesignsolutions.com/KM/ExplicitTacit.htm

 In her study of organisational knowledge L Wah stated the following:

According to Buckman of Buckman Labs,, 90% of the knowledge in any organization is embedded and synthesized in peoples’ heads. Unleashing this knowledge- which is tacit in nature-presents a big challenge. (Wah, 1999b;)

We will revisit this later

Another article I found which tried to define the terms was the following:

http://www.hec.gov.pk/InsideHEC/Divisions/RND/HLIB/PublishingImages/Explicit%20Knowledge%20vs%20Tacit%20Knowledge.pdf

Explicit knowledge is formal and systematic. It can be easily communicated and shared. Typically, it has been documented. Articulated knowledge, expressed and recorded as words, numbers, codes, mathematical and scientific formulae, and musical notations. Explicit knowledge is easy to communicate, store, and distribute and is the knowledge found in books, on the web, and other visual and oral means.

Tacit knowledge on the other hand, is not so easily expressed. It is highly personal, hard to formalize and difficult to communicate to others. It may also be impossible to capture. The challenge is to identify which elements of tacit knowledge can be captured and made explicit—while accepting that some tacit knowledge just cannot be captured. For tacit knowledge that cannot be captured, the goal is to connect the possessors of tacit knowledge with the seekers of that knowledge

Another useful link that I came across was this one

Tacit Knowledge is highly personal and hard to formalize, making it difficult to communicate or share with others.

Explicit Knowledge is codified knowledge that can be transmitted in formal, systematic language.

With this in mind I started to look at how it applied to testing, immediately I started to see a relationship between exploratory and scripted testing. My research found that ‘The test eye people’ have talked about this here.   I highly recommend reading this since it goes much deeper into the kinds of tacit knowledge and how that relates to testing than I do in this article.

My thoughts then turned to how it relates to our everyday testing job and I found that the information we know and can write down works well for scripted testing.  This is what explicit knowledge implies, if we can document it (codify) it then we can script it.  However testing is about testing the information we do not know or cannot explain (the hidden stuff) to do this we have to use tacit knowledge (skills, experience, thinking) we need to experience it to be able to work it out.  This is what is meant by tacit knowledge – learn it by doing it rather than reading.

Harry Collins stated that all explicit knowledge comes from tacit and I agree with this.  Once we have done some exploratory testing and documented the tacit knowledge becomes explicit.  However this accounts for a very small portion of the whole wealth of our tacit knowledge and as we do exploratory testing we uncover more areas that will require our tacit knowledge skills to be used.

One interesting point that is that tacit knowledge can become explicit as we communicate and socialise more.  As our society evolves and our ability to put into words our thinking and thoughts, more of our tacit knowledge becomes explicit.  This appears to have happen over the lifetime of existence on the planet.  We started with primitive sketches and marks which involved into handwriting.  We appear to be going back to using sketching as a tool to make knowledge explicit .  Are we going back to our historic past to help turn tacit into explicit?  As history appears to show as we become better at documenting and writing down our thoughts and thinking, our ability to turn more of our tacit knowledge into explicit knowledge becomes easier.   

Ikujior Nonaka and Hirotaka Takeeuchi talk about how to turn our tacit knowledge into explicit knowledge in their book – The Knowledge Creating Company – How Japanese companies create the dynamics of Innovation.  They explain  the use of the “Knowledge conversation process and the knowledge spiral details of this can be found in this article. .  Their explanation of the knowledge conversation process diagram is reproduced below:

1. Tacit-to-tacit (socialisation) - individuals acquire knowledge from others through dialogue and observation

1. Tacit-to-explicit (externalisation) - the articulation of knowledge into tangible form through elicitation and documentation

1. Explicit-to-explicit (combination) - combining different forms of explicit knowledge, such as that in documents or databases

1. Explicit-to-tacit (internalisation) - such as learning by doing, where individuals internalise knowledge into their own mental models from documents.

Taken from: http://www.skyrme.com/kmbasics/kspiral.htm.

If most of our knowledge is tacit (90%) then it would make sense to ensure that software development processes were aligned to where the majority of our knowledge lies.  This would indicate that the majority of our testing effort should be spent on using the exploratory testing approach to increase our explicit knowledge.  Currently within the industry we seem to be spending a lot of our testing time utilising our explicit knowledge by means of requirements coverage, test automation checks, scripting without realising that we are only using 10% of our total knowledge capacity.  In any business utilising 10% of any resource would be seen as commercial suicide, yet this practise is being carried out across the majority of the software testing profession and supported by many testing organisations in the way they ‘certify’ their testers.  People need to be made more aware of the way in which human beings store and use their knowledge.  It is not by documentation but by doing, immersing, taking part, practising, experimenting.  It is time we started to recognise that testing is a tacit activity and requires testers to think both creativity and critically.

I feel that the way in which we use and share knowledge is going to become more important within the testing world and many others within the testing community are talking about the subject of tacit and explicit knowledge. I have already mentioned within the article a post by the test eye people ,  Michael Bolton posted an article about this subject recently  in turn which was  based upon a future prediction post Michael wrote in  2011.  Simon Morley talked about using peer conference to help turn tacit knowledge into explicit knowledge.  Marcus Gartner has written a great post about how automaton can help turn tacit into explicit and why exploratory testing is still vital. The Eurostar testing conference in Sweden this year has an underlying social science style feel to it especially with Harry Collins being one of the keynote speakers.  Jeff Lucas posted an article about the relationship between tacit and explicit knowledge and testing on the software testing club website.  I feel it may be prudent of anyone involved in testing to learn more about tacit and explicit knowledge and how you can use your understanding of this to help you add value to your team, project and organisation.

This is an exciting time within software development  and one in which testers with their ability and skill in turning tacit into explicit knowledge already have a lead and the way we utilise this expertise and ability will determine the success of the project or the organisation we are working within.

Ethnographic research feedback

Sometime ago I wrote an article about the relationship between ethnographic researchers and testers and how similar they are.  Recently Peter H-L (@Unlicensed2test) on twitter reminded me that I had also presented at the UNICOM  conference on using some aspects of ethnographic research to aid feedback when we are testing and from this I came up with a new mnemonic and a set of testing related social science questions.   I had thought that I had already posted this but it seems I had not.

What follows is taken from the talk I did.

*************

Within the article there was a section that dealt with questions that the researcher should be asking when studying the subject.  I changed this to make it relate to software testing and came up with the following:

• Substantive Contribution: "Does the testing carried out contribute to our understanding of the software?"
• Aesthetic Merit: "Does the software succeed aesthetically?" Is it suitable for the end user?
• Reflexivity: "How did the author come to write this test…Is there adequate self-awareness and self-exposure for the reader to make judgements about the point of view?"
• Impact: "Does this affect me? Emotionally? Intellectually?" Does it move me?
• Expresses a Reality: "Does it seem 'true'—a credible account of a requirement'?"

Lynne Mckee has been updating a list of testing mnemonics on her blog site  so I thought about this and came up with the following mnemonic:

R.A.I.S.E

From this I created a list of questions under each of these heading that can be used to aid feedback when you have been testing, ideally when you are following session based test management.


Use the following template to do a personal review of the testing that you carried out during the day.
Please try not to answer using yes and no, expand on your reasons for either it being yes or no.
This debrief/review is more about your views, opinions and feelings rather than the product you have been testing.
It should only take you 10 minutes to complete this feedback – try not to write essays.

_______________

Reflect

Personal reflection:

• Could you have done things better if so what? (Both from a personal and testing perspective)
• Have you learnt new things about the product under test (That are not documented)?
• Has your view of the product changed for better or for worse? Why has your view changed?

‘Epistemological reflexivity’ (What limits did we hit?)

• Did your defined tests limit the information you could find about the product?  (Did you need to explore new areas that you had not defined)
• Could your tests have been done differently? If yes how?
• Have you run the right tests?
• If you did things different what do you think you would have found out about the product?
• What assumptions have you uncovered to be true/false?
• Did the assumptions you make impede or help your testing?

Aesthetic:

• In your opinion is the product suitable for the end user?
• In your opinion is the product appealing at first look?
• In your opinion is the product confusing?
• In your opinion does the product flow?
• In your opinion are there any ugly areas?
• In your opinion does the product succeed aesthetically? Does it meet the image the customer is trying to portray?

Impact:

(this section is intended to be used to say how you 'feel' about the product, your first impressions, if you answer yes you should provide more details)

• Does this affect you?
• Emotionally?
• Intellectually?
• Does it move you?
• Does it cause you negative/positive feelings?
• Does it frustrate you?
• Does it annoy you?

Substantial:

• Have we covered a substantial amount of the key product areas?
• Has the testing contributed to your understanding of the product?
• Do you think you have a substantial understanding of the system and sub systems?
• Does your knowledge of the system have any substantial gaps?
• Could you easily explain the system to a first time user?

Expression:

• Does the product seem 'true'—a credible account of a requirement'?
• Does the product express what will happen in ‘real’ world?
• Does the reality of the product match the expectations of the product?
• Does the product express unexpected ways of working?

_______________

To make it easier I have create a MS word document with the questions in which you can download from Google docs here.

*************

Testers should learn code

At the Eurostar conference in Amsterdam  Simon Stewart (@shs96c) presented a keynote on Selenium over the years

During the key note Simon made the following comment

"If you are testing the web you absolutely need to be able to code"

Now I am sure that out of context this could be taken in many ways and Rob Lambert has produced a very good discussion on this same subject here which takes on both sides.

I will add is that Simon did follow this up with the following line.

"If not become a specialist so you can add value"

This led to some interesting exchanges on Twitter (search for #esconfs) in which people came down on either side. I had concerns that people would only hear the first bit and this could cause barriers to some great people being able to be involved in testing just because they have no interest in coding or even wanting to learn to code.

IMO I am not sure about this statement and it caused much debate after the key note.  If you have an interest in learning code then do so otherwise do something that can add value. The discussions continued during lunch and the rest of this article is my own thoughts on this subject.

After talking to Simon afterwards it appears his message had got taken the wrong way.  He said it is helpful to code and that if all you do is test (check) scripts then you may not have a job.

My concern is forcing people to code if they have no interest could be a block from great people wanting to enter the world of software testing.

Dot Graham stated the following "Lose a good tester but gain a poor programmer".

I am not convinced that everyone needs to code, it can have its advantages but there is another perspective. If you do not understand the code you may test in a different non-confirmatory way.  You may be able to ask the difficult questions of why did you do it this way and made it complex?  You may not have a bias built up from your coding experiences and knowledge.  I think for some it can be useful but insisting on it is a very dangerous path to follow.

Some of the discussions that followed went along the lines that if testers refused to learn we should not employ them.  This is where I had a WTF moment.....  I have not said anything about testers not wishing to learn what I was saying was some people may not have an interest or a knack for coding or find it impossible for whatever reason to grasp.  However they make one hell of a tester and show a great thirst for learning new ways to exercise the software that are novel, unique and valued.  This was the second point that Simon was making and sadly appeared to have been missed.  As long as you can find ways to add value then you can be a tester.

I am afraid that a statement of this sort can be used as a filter to prevent people entering this great world of software testing.  There are many other things that IMO testers could learn about such as grounded theory, anthropology, social sciences, humanities, creative arts and the list goes on.  There are some great testers who have learnt these things and should we prevent them for working as software testers because they have no desire to learn code?

I will finish this on a positive note and that it was great to chat with Simon even if our views are slightly different and that he is a very thoughtful and  passionate person.  I look forward to meeting up again sometime  in the future and finding another topic to discuss.

PS Thanks to Rob Lambert for being the referee!!

(edited some of the grammar :o( )