Are Testers’ Ethnographic Researchers?

People who follow me on twitter or via my blog might be aware that I have a wide range of interests in areas outside my normal testing job. I like to research and learn different things, especially psychology and see if it may benefit and improve my skills and approaches during my normal testing job. One area I have being looking at for awhile is the social science of ethnography. The approaches used when carrying out research appears to have many similarities to software testing and I feel we could benefit and maybe improve our testing skills by examining ethnography.

In my opinion, there are two areas in which we can learn from ethnography:

  • To improve our understanding of users and how they differ by using ethnographic methods
  • Use ethnographic methods to test software in an exploratory way.

I should start by explaining what my understanding of ethnography is according to anthropologist Brian Hoey. He defines ethnography as “equated with virtually any qualitative research project…where the intent is to provide a detailed, in-depth description of everyday life and practice.” He continues to state that an ethnographer is more than documenting events and details of everyday life but that the ethnographer attempts to explain how such occurrences represents the cultural construction an individual or community lives in.

The problem with trying to describe and define ethnography is that it has wide and varied meanings. To me, it is a branch of the study of humanity (anthropology) in which the researcher actively gets involved and participates with the study group rather than just sitting back and observing. The reporting is using qualitative (words) measurements rather than rely on quantitative (numbers) measurements.

One of the key factors when approaching ethnographic research is to be aware that participation, rather than just observation, is one of the keys to the approach. Does this not sound familiar to testing, especially exploratory testing? Actively using the software under test to find out about its characteristics and behavior are similar to an ethnographic researcher living within a community and participating with that community to learn about its beliefs and characteristics. There appears to be very close parallels between ethnographic research and exploratory testing. Wikipedia states that “one of the most common methods for collecting data in an ethnographic study is direct, first-hand observation of daily participation.”

How similar is that to testing software?

Another approach within ethnography is the use of grounded theory to explain the results from the participation. This is when the data is used to provide theories about the data. This is different from grand theory in which the theory is defined without the use of real life examples and therefore has a danger of not fitting the actual data gathered afterwards. Is this similar to scripted and exploratory, grand theory vs. grounded theory?

Grounded theory is a constantly evolving set of conclusions that can continue indefinitely based upon the changing data being obtained by the ethnographic researcher. One of the questions that are asked about ethnographic research is: When does this process end?

One answer is: never! Clearly, the process described above could continue indefinitely. Grounded theory doesn’t have a clearly demarcated point for ending a study. Essentially, the project ends when the researcher decides to quit. (http://www.socialresearchmethods.net/kb/qualapp.php) How similar is this to testing? When do we stop testing?

Many articles have been written on this subject and mainly we stop when we can learn nothing new, no time or ran out of money. See Michael Bolton’s article where he lists twelve heuristics for test efficiency methods. I feel that ethnographic research stops because of similar reasons.

One interesting section I saw within the Wikipedia article on ethnography was about the process of ethnographic research in which to aid the researcher areas were split and the research asked questions:

  • Substantive Contribution: “Does the piece contribute to our understanding of social-life?”
  • Aesthetic Merit: “Does this piece succeed aesthetically?”
  • Reflexivity: “How did the author come to write this text…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 cultural, social, individual or communal sense of the ‘real’?”

I thought about this and started to change the context to be about software testing:

  • 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’?”

By doing this I found I suddenly had a set of heuristics to measure against the software testing that has been carried out, yet again more similarities between the two crafts.

Another area in which ethnographic research can be useful to software testing is when you need to test software that has a lot of UI interactions. Using the methods of ethnography a tester could go visit the users and observe and participate in their daily routine to find out the common tasks carried out and what oddities are seen.

The oddities are the things of greatest interest since these are the things that would not normally be planned for and without active participation with the users would not normally be uncovered until it is too late.

There are many studies being carried out to determine if ethnographic research should be used when designing software system. However, my concern with this is that it appears to be stuck in the design up front way of working which is not a flexible iterative approach. In my view it is easier, quicker and cheaper to ensure that testers use ethnographic methods when testing to ensure the design is suitable for users or even better get the users involved earlier and observe them earlier.

The more I have delved into the study of ethnography the more and more I have seen similar patterns to software testing. This makes me aware that software testing is not solely a hard science but a craft that encompasses many disciplines outside of the typical number crunching and algorithm creating world of software development. Within the testing profession we need to look outside of the box and find approaches, methods, structures that can improve the discipline. To ensure our craft grows we need to ensure we do not narrow out field of vision or thought.


To read original post please visit http://steveo1967.blogspot.com/2011/01/are-testers-ethnographic-researchers.html

 

John Stevenson

Tweet John Stevenson: @steveo1967
“The opinions expressed in this blog are my own views and not those of any company I have or do work for”Having been involved in testing for over 20 years and within the IT industry for more than 24 years I am still surprised with how exciting I find it and how much I continue to learn about things that are new.I have a passion for learning and love to learn about new things. I have an interest in many things such as social science, psychology, photography, and gardening. I keep involved within the testing community and write a testing blog (www.steveo1967.blogspot.com) and can be found regularly tweeting (@steveo1967).
John Stevenson
I have a passion for learning and love to learn about new things. I have an interest in many things such as social science, psychology, photography, and gardening.

The Related Post

I’ve been reviewing a lot of test plans recently. As I review them, I’ve compiled this list of things I look for in a well written test plan document. Here’s a brain dump of things I check for, in no particular order, of course, and it is by no means a complete list. That said, if you ...
Introduction Software Testing 3.0 is a strategic end-to-end framework for change based upon a strategy to drive testing activities, tool selection, and people development that finally delivers on the promise of Software Testing. For more details on the evolution of Software Testing and Software Testing 3.0 see: The Early Evolution of Software Testing Software Testing ...
Training has to be fun. Simple as that. To inspire changed behaviors and adoption of new practices, training has to be interesting, motivating, stimulating and challenging. Training also has to be engaging enough to maintain interest, as trainers today are forced to compete with handheld mobile devices, interruptions from texting, email distractions, and people who think they ...
This article was developed from concepts in the book Global Software Test Automation: Discussion of Software Testing for Executives. Introduction Metrics are the means by which the software quality can be measured; they give you confidence in the product. You may consider these product management indicators, which can be either quantitative or qualitative. They are ...
Having developed software for nearly fifteen years, I remember the dark days before testing was all the rage and the large number of bugs that had to be arduously found and fixed manually. The next step was nervously releasing the code without the safety net of a test bed and having no idea if one ...
Reducing the pester of duplications in bug reporting. Both software Developers and Testers need to be able to clearly identify any ‘Bug’, via the ‘Title’ used for the ‘Bug Report’.
When You’re Out to Fix Bottlenecks, Be Sure You’re Able to Distinguish Them From System Failures and Slow Spots Bottlenecks are likely to be lurking in your application. Here’s how you as a performance tester can find them. This article first appeared in Software Test & Performance, May 2005. So you found an odd pattern ...
This article was originally featured in the July/August 2009 issue of Better Software magazine. Read the entire issue or become a subscriber. People often quote Lord Kelvin: “I often say that when you can measure what you are speaking about, and express it in numbers, you know something about it; but when you cannot express ...
When it is out of the question to delay delivery, the solution is a prioritization strategy in order to do the best possible job within the time constraints. The scenario is as follows: You are the test manager. You made a plan and a budget for testing. Your plans were, as far as you know, ...
Introduction This 2 article series describes activities that are central to successfully integrating application performance testing into an Agile process. The activities described here specifically target performance specialists who are new to the practice of fully integrating performance testing into an Agile or other iteratively-based process, though many of the concepts and considerations can be ...
LogiGear Magazine March Testing Essentials Issue 2017
This article was developed from concepts in the book Global Software Test Automation: Discussion of Software Testing for Executives. Quality cost is the sum of all costs a company invests into the release of a quality product. When developing a software product, there are 4 types of quality costs: prevention costs, appraisal costs, internal failure ...

Leave a Reply

Your email address will not be published.

Stay in the loop with the lastest
software testing news

Subscribe