People Make the Code and Code "Makes" the People: 99 Ways Workshop #49

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 #49: When you analyze a system, don't forget the parts of it that are not made of code, but living, breathing, fickle, forgetful, quarrelsome, cooperative, adaptable, lovely human beings. - Anna Baik

Systems are developed for people to accomplish certain goals. They are also developed and built by people for people. That means, at the heart of everything, the software that is created is ultimately limited by the abilities and aspects of the people that make it. That means there are no perfect systems. There are no bug free systems. There are no infallible systems. They all are built by people, used by people, and ultimately are accountable to people. 

Workshop #49: Understand the motivations of the people that create and use systems. Realize that not all users fit the same mold. Spend some time understanding why people want their systems to behave in certain ways, and find ways to help them achieve that.

There is a discipline in software and hardware development that's referred to as "human factors".  Another term for it is "ergonomics". Both try to do the same things, determine how best to shape systems and processes so that humans can use them comfortably and effectively.  

Even if the ideas of ergonomics or  human factors are not areas that you specialize in, there is a value to understanding how the systems we use are designed, and how we interact with them. When systems require going into deep layers to set up and make work properly, many of us will certainly not enjoy using those systems. If we do not enjoy using them, it's a very good bet that our users will not either. 

When a system or a process requires too many steps to configure, or doesn't take into account the way that humans prefer to interact with systems, we run the risk of our customers abandoning or having less interest in using our products. Performing usability studies of our applications, and the information we gain from these studies, can prove to be very helpful.

For those who do not have familiarity with usability testing, two interesting sources are books by Steve Krug. The first is the book "Don't Make Me Think", which goes into the  background and details of performing usability testing, and the second is "Rocket Surgery Made Easy" which is a workbook on how to apply the ideas discussed in "Don't Make Me Think".

As an example of this process, Steven recorded a sample interaction to show some ways that we can perform usability testing. 

Bottom Line:

When we design systems, we often try to design them with the customer in mind, but very often we end up designing systems that do not really hit that mark. That's because people design systems, and people often have cross purposes as to why they think that systems and approaches will work. It helps to take a step back where we can to see if the solutions we are presenting make sense. Do we require our users to move around a lot to accomplish tasks? Can we come to an understanding of what they really want to use? Getting to understand the humans in the system, both from the way humans design systems to the people who end up using the systems, we can better test more aspects than just the code.