Think About as Many Different Perspectives as Possible: 99 Ways Workshop #62

Many aspects affect the perspective we have
towards like, relationships and the tools that
we use.

The Software Testing Club recently put out an eBook called "99 Things You Can Do to Become a Better Tester". Some of them are really general and vague. Some of them are remarkably specific.

My goal for the next few weeks is to take the "99 Things" book and see if I can put my own personal spin on each of them, and make a personal workshop out of each of the suggestions. 

Suggestion #62: Think about as many different perspectives as possible!! - Dan Ashby

One of the terms that gets used a lot in software testing is "context". "Perspective" deserves to stand right next to it. Often, those of us who have continuous involvement with a project will develop a case of "tunnel vision"; we see the project and the issues through our own perspectives. If I am prone to using a particular platform, then I will consider that paradigm as normal. If we are focused on desktop apps, then web or mobile apps may suffer from the fact that we do not understand their positive and negative issues as wells we do our preferred platform.

Comparing different platforms or applications to others is normal, but how do we handle different goals, contexts and needs with the same application? Are we considering how others might interact with the product in ways that are unfamiliar to us? What if we woke up one morning and our physical reality were to change? How would we view the software that we use? What might we do differently, and what might stand out as issues we would have never considered before? 

Workshop #62: Take one of your senses and abilities that you take for granted, and find a way to limit that ability. Pull a hat down over your eyes. Plug your ears, or figure a way to simulate an inability to hear. Bind several fingers on your hands together. Now interact with your software applications. What do you notice that you may never have considered before?

One of the most interesting aspects of my current job is the fact that we have a broad variety of customers and users for our products. They vary from very small to very large companies, and some of the very large companies have policies about what software has to do to be purchased. One of our customers has a very specific requirement. Our product needs to work in such a way that people with certain disabilities have the ability to use our software effectively. Accessibility testing is an area of testing that I had never performed before. I realized that Accessibility options were available, but it had never come up in any meetings or discussions during development to apply any resources to testing for them.

There are a variety of applications that can be used. There are operating system specific tools that are built in to system preferences, as well as special purpose tools that have been developed to make software respond better for specific needs. There are screen readers and audio playback options for those with vision impairment, there are voice activated systems and command layers for those who cannot use or have limited use of their hands. Options for screen alerts can be configured so that those who have hearing impairment can be alerted at important times, etc. Many of these tools are proprietary and cost money to purchase and work with, but their are also several that are available for free.

To help me with this testing at times, I actually do what I described in the workshop section. I will pull a hat down over my eyes so that I really cannot see a screen or my keyboard keys, or I'll bring the system into a room with no windows, turn off the lights, turn off the screen illumination, and enable the screen reader application. When I set up Dragon to speak with the system, I will take some rubber bands and put them around my fingertips to mimic fused fingers, or to simulate what I would need to do if I didn't have fingers at all.

These options make me depend on the software layer that makes accessibility possible. While these tools will help us discover how accessible our products are, it also allows us to see the workflows we take for granted. When I have several steps that I need to have performed, I may not be thinking about the efficiency of the workflow, since the impact of an additional few steps may be minor. When we have to listen to descriptions of every command, or be very exact with verbal cues, "minor" inefficiencies can become agonizing.

Bottom Line:

Accessibility is just one way to adjust a perspective as to how a product operates. Localization, variation of platforms, older and newer operating systems, cultural aspects, language idioms, and more can play into the perspectives we use to view and interact with software. Make a point to see if you can change your world view a little bit, and then see what the change in your world view inform the questions you ask of your software.