When I was a child my brother used to build amazing Lego structures…and I’d break them.  Little did I know then that he’d become a civil engineer and I’d be a tester...

Testing is not about breaking things though…it is about the mitigation of risk in a controlled environment and the assessment of suitability for purpose.  My brother's structures were clearly not fit for purpose and as a young tester I knew he wanted to grow up to be respected for building stable structures.

Our customers won't use it like that

The suitability of purpose or quality, much like beauty, can be in the eye of the beholder and has a different meaning for different people. The ideal of quality can be subjective and is continuously evolving.  At AccessHQ, a Dialog subsidiary, the definition of quality reflects this.

"A quality product or service is one that meets or exceeds customer expectations"

Herein lies the challenge for IT. As our customers take in new information, and are exposed to new experiences, their opinions and point of reference can change over time. In other words, their expectations change over time.

Consider fashion... who can remember the 80’s? Who had a Flock of Seagulls haircut and thought they were cool? But, I digress, I’m human and a tester, I go off on tangents, look at things from different angles; I don’t always conform to a behaviour that someone has laid out for me.

Humans do not work in a linear fashion and are often distracted or interrupted.  However, applications time out when we have stopped to chat in the middle of a transaction, or noticed our child painting the wall with crayon, or rushed to pull a boiling pot off the stove, or had another thought, opened a new tab and been sucked into the Google vortex.

How often do we hear, ”but our customers won’t use it like that”.  Yet, how often do our customers surprise us by using our technology in an unexpected way and venting their dissatisfaction on social media? We are human, yet we are constantly being asked to perform actions to suit technology, rather than the other way around. We yearn to be understood and we expect technology to conform to our expectations.

• Why do we insist that transactions must be processed linearly?
• Why do we force our customers to use technology in a certain way?
• Why do we continue to apply “discipline” to testing often at the expense of innovation?

Sometimes undisciplined behaviour can yield unexpected results. Would we prefer to know about unexpected results and work with our customers to best determine how to deal with them?

Human qualities

Humans have beautiful imperfections that make us human; we are colour blind, partially sighted, legally blind, computer illiterate, prejudiced; we break limbs, we break rules, we break hearts, we get distracted and we write imperfect requirements and create imperfect code (un-intentionally imperfect as we want technology to work) … but technology often fails us … because it doesn’t understand us …it is not human.

Our customers may not believe our next new thing is as “cool” as we believe it to be ... they’ve already seen something “cooler”.  In this fast paced world that we now live in, we need to come up with new ways to perform testing.

Humans can be judgemental and share their judgement with others, this can be damaging to your bottom line as you are judged “unsatisfactory".

"How will you know the expectations of your customers, and meet or exceed these expectations, if you don’t ask what they are?"

- Denise Barrett, Principal Consultant AccessHQ

AccessHQ (Human Quality)

AccessHQ has developed a range of services, techniques and tools to aid in the assessment of quality across the entire technology lifecycle. We look at technology from different angles by asking the following questions;

• Does it work as expected?
• Can they use it?
• Are they engaged?
• Are they loyal?
• Is your IT planned?

Let’s look at some real-life scenarios for a couple of these key questions to illustrate the approach.

Does it work as expected?

Business requirements capture a new contact number at a bank, which is carried forward into the design, specifications and test cases.  A human tester may have the insight to call the number and discover it is actually the number for a garden centre. This defect could have caused significant embarrassment on launch, but this minor typo had been approved and carried forward through every level of the process.

This change would have passed typical functional and automated testing. It would be simple to resolve this defect as it is a relatively small change to make prior to Implementation.  With little impact on functionality it can be fixed and tested quickly, thus preventing reputational damage and loss of business.

Can they use it?

A form is being updated in a data capture accounting system. The ability to use the number pad, tab between fields and use hotkeys is an expectation of the end user. They have used other similar systems and have applied their “frame of reference” to set their expectations. However, these requirements are not captured anywhere in the documentation of the system.

Using the paper based application form and transferring “real” data into the system could reveal that input fields on the user interface do not align. All fields are captured in the requirements and specifications but are presented in a different order from the application form. Automated testing running from a data sheet would pass the test.

In both scenarios, a human tester may query the usability of the application and be faced with the business analyst who has assumed that “the users won’t use it like that” or a development manager who will insist “it is built to the specification”.

These usability issues could slow down data entry processing and equate to an additional full time employee to make up the shortfall against current data entry achievements (in an application with hotkeys and fields in the same order as the application form). The aim of the new system was to reduce the manual overhead and free up current staff for other activities. Instead the opposite has happened.

Ask and you will receive

Using simple techniques to frame questions about the system to determine how it will be used, by whom, and with what expectations will result in better quality outcomes and happier customers.

• Assume nothing
• Search for answers
• Know your customer​

Visit www.accesshq.com for more information.