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

Companies generally consider the software they own, whether it is created in-house or acquired, as an asset (something that could appear on the balance sheet). The production of software impacts the profit and loss accounts for the year it is produced: The resources used to produce the software result in costs, and methods, tools, or ...
It’s a bird! It’s a plane! It’s a software defect of epic proportions.
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 ...
Creative Director at the Software Testing Club, Rob Lambert always has something to say about testing. Lambert regularly blogs at TheSocialTester where he engages his readers with test cases, perspectives and trends. “Because It’s Always Been Done This Way” Study the following (badly drawn) image and see if there is anything obvious popping in to ...
People rely on software more every year, so it’s critical to test it. But one thing that gets overlooked (that should be tested regularly) are smoke detectors. As the relatively young field of software quality engineering matures with all its emerging trends and terminology, software engineers often overlook that the software they test has parallels ...
Karen N. Johnson began as a technical writer in 1985 and later switched to software testing in 1992. She maintains a blog at TestingReflections, a collaborative site where she is featured as a main contributor. In her latest entry, she discusses search testing with different languages. Here is an excerpt from her blog: “I started ...
LogiGear Magazine – May 2011 – The Test Process Improvement Issue
Introduction All too often, senior management judges Software Testing success through the lens of potential cost savings. Test Automation and outsourcing are looked at as simple methods to reduce the costs of Software Testing; but, the sad truth is that simply automating or offshoring for the sake of automating or offshoring will only yield poor ...
Introduction This article discusses the all-too-common occurrence of the time needed to perform Software Testing being short changed as specification, development, and unforeseen “issues” cause the phases prior to testing to expand. The result is that extreme pressure is placed upon the testing organization to perform the testing function within a reduced time frame. The ...
Trying to understand why fails, errors, or warnings occur in your automated tests can be quite frustrating. TestArchitect relieves this pain.  Debugging blindly can be tedious work—especially when your test tool does most of its work through the user interface (UI). Moreover, bugs can sometimes be hard to replicate when single-stepping through a test procedure. ...
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 ...
March Issue 2019: Leading the Charge with Better Test Methods

Leave a Reply

Your email address will not be published.

Stay in the loop with the lastest
software testing news

Subscribe