The Trap of Exploratory Context Collapse

I recently heard the term “context collapse” in a podcast discussing the possible flight of the younger audience from some social media applications. It is unclear who originally coined the term in the early 2000's, which initially referred generically to the overlapping circles on social media leading to a poster's inability to focus on a single audience. In the podcast, the meaning was more specifically defined to identify the clash of incompatible social circles: college acquaintances, close friends, family, and work connections (especially management). That incompatibility leads to an abandonment of the media or couching postings in coded terms that are (supposedly) only understood within a specific circle.

That sparked a memory of a testing phenomenon I have run into on occasion, a form of exploratory context collapse. Here, I will use functional accessibility testing, specifically Section 508 testing for U.S. government products, as an example of how this can occur. The Section 508 standards were developed primarily for the keyboard/mouse era of ten years ago and specify a set of requirements for desktop applications and web applications. (These are presented separately since a web application is largely dependent on the browser for its environmental presentation, but the function testing is similar for both environments.) The impact of mobile and desktop touchscreen environments on accessibility testing is an interesting topic, but that is for another posting later. (Perhaps that would be a good discussion topic!)

I usually saw teams attempting to implement the specific technical direction provided in each individual requirement, usually as independent efforts (by independent developers). In the development environment, this approach led to straightforward implementations but subsequently led to some interesting singularities in the test environment.

An example is one screen that presented a series of clickable pie chart selections to display the meaning of a report graph. One requirement is to not use color as the only means of conveying information. The solution: Provide popup mouse hover context text to allow the user to tell the difference between displayed pie chart sections. However, separately there was another requirement to make any information displayed as text programatically visible externally (such as to a screen reader). Solution: Make the displayed popup text output on the screen reader. Another requirement also required that the application be usable without the use of a mouse. This one stumped the developers, resulting in plans to revise the screens to provide alternate text screens, with the impact on readability and obtuse navigation problems. Other requirements impacted this particular function to one extent or another, at which point the development was getting out of hand.

Due to the development structure, this transpired as a series of defect submissions to different developers, each associated with their individual requirement, sometimes from different testers. That ended one day when we realized we had stepped into an area of overlapping usage contexts, each with a different user having different needs and different solutions. The solution was to step back and untangle the overlapping contexts. With the help of some some subject matter experts (ie, consultants with actual disabilities to evaluate the product), we were able to break the requirements up into those contexts for which they were specifically intended through the use of role-based testing. Some examples: people with various visual disadvantages (color blindness, uncorrectable focus or blind spots, total blindness) and persons with various manual disadvantages (limited movement, erratic movement, mouse restrictions, keyboard restrictions).

The intelligent use of roles/scenarios with the understanding of the intent underlying specification testing is essential in avoiding the trap of exploratory context collapse. If you find yourself in a hot debate questioning whether a specific screen function is a defect or not, it may be time to go back to basics and research the core needs underlying your specific requirements.

Views: 287

Add a Comment

You need to be a member of Software Testing Club - An Online Software Testing Community to add comments!

Join Software Testing Club - An Online Software Testing Community

Comment by Madhava Verma Dantuluri on March 11, 2014 at 4:32

Excellent share and i have come across with the similar situations.


© 2017   Created by Rosie Sherry.   Powered by

Badges  |  Report an Issue  |  Terms of Service