When we are designing user interfaces we should be mindful of this and help the user make the correct decision rather than punishing them when they make the wrong one.

If you leave it too late you could end up in the intersection; if you keep going then you may run the red-light.

To make it more interesting there is a red-light and speed camera; so you can’t speed up and you get fined if you don’t make it.

What do you do?

The issue is uncertainty there are too many variables to make an easy judgement call. Not all intersections are the same length, not all roads are at the same speed, you are not always going exactly the speed limit, you’re not always the same distance from the intersection when the light changes.

If you add additional factors like poor vision from eyesight, poor vision from bad weather or poor spatial skills it becomes even harder.

If you look at this problem as “should I keep going?” we can make a simple change that I think would remove the issue.

If you’re travelling at the speed limit there is a finite distance you can travel in the five seconds from when the light goes orange to when the light goes red.

If you travelling 80km/h then are moving at 22.2metres per second and if you’re travelling at 60km/h then you are moving at 16.6m/s.

If you have 5 seconds to cross the intersection then you are going to travel 111.1 or 83.3 metres respectively.

Now consider the example story and add a single orange line drawn across the lane at 110m from the far end of the intersection. If the light goes orange and you haven’t crossed the orange line then you are never going to make it. The decision is made for you. If you’ve crossed the line then you will make it and can continue at the speed limit.

The caveat is that all of these equations are based on the maximum speed of the road. If you’re travelling slower than the speed limit or there are poor conditions and you are outside the line you have more time to stop. If you’re inside the line then it comes back to the judgement call.

Some may argue that because it doesn’t solve the problem for all scenarios it won’t work or the government would get sued. The judgement call is the backup and is the current process. The orange line solves the problem in all scenarios where the driver is travelling at speed. In rainy or icy conditions it may even help drivers who are unsure whether their car will stop in time.

To me; all of this relates back to designing the User Experience and challenging the assumptions about what we think the user knows at the decision point. I feel we are often too focused on the outcome of a decision (user invokes behaviour) rather than the decision process.

If we’re in the mindset of “if the user wants to do X they can click here and if they want to do Y they can click there” or “if the driver wants to make it through they keep driving and if they want to stop they slow down” we need to take a step back and make sure the user can make the decision in time.

When you are next giving a user choice consider why and how the decision is made. It may be possible to better plan the flow so that no decision is ever necessary.

1. if you’re turning left you will be travelling at a lower speed and better able to stop

Service tests where I work are written in Vanilla C. We’re talking 80’s C with the big hair, neon and everything. One of the things Vanilla C doesn’t have is the concept of a Boolean. Integers are used.

When we execute tests we leave cross cutting concern validation off when testing functionality and then enable it when are specifically testing that particular cross cutting concern. An example is ‘Exception Reporting’. We do this to reduce the time it takes to execute the tests and to stop Exception Reporting failures from failing the functional tests. Restricting the focus of testing is very important to me.

So we would have code that looks like this:

EnableCheckForExceptions (0) ;

I was explaining this to my junior service tester and she asked why it couldn’t just be a Yes or a No.

I didn’t have a good answer especially because I knew it was entirely possible to have just a yes or a no; in a newer language I would have coded something like this:

ExceptionValidation.Enable () ;

But in C we don’t get such extravagances as classes. Luxury!

What I did and what I will do in future is define an enumeration like so:

enum EnabledOptions {No, Yes} ;

and then changed the signature to this:

void EnableCheckForExceptions (enum EnabledOptions ExceptionValidationEnabled)
{
     //...
}

This isn’t mind blowing software architecture but anything that increases friction or is a barrier to learning makes it more difficult to learn. Right now my primary job is establishing an autonomous service testing team from people who are not software developers. This is a combination of teaching them various programming languages and writing an API layer that encapsulates the existing HP Service Test functions and gives it a more realistic testing terminology and structure. This enables the testers to use their language to write service tests.

To me this is where HP’s Service Test fails most of its users. It’s designed for the people who wrote Load Runner and not those who are service testers or those that lack in depth programming knowledge.

I fell into the same boat but thankfully I was saved by taking my implementation to the users and asked if made sense. User acceptance testing for APIs!

Many of you are probably aware of the issues surrounding Google Buzz and the publication of private information. One of the ones that caught my attention, second hand I might add as the original post is now private. Here is the article that I read. Click here for article.

Based on the article it would be easy and foolish to say that Buzz and the rollout of Buzz weren’t tested properly. I would say that there is a lot of testing going on here and my guess is that almost none of it is defective or underdone.

As I did with the “Great Australian Internet Blackout” I am going to talk about testing and how that relates to the issue at hand rather than the actual issue at hand.

Firstly let’s get to the obvious testing that was probably done on Buzz. There are some basic concepts of information security; Confidentiality, Integrity, Authentication, Authorisation, Availability and Non-Repudiation. Here is a Wikipedia article about Information Security.

When it comes to testing I call these testing aspects and add a seventh called Penetration testing.

• Confidentiality – testing to ensure the correct disclosure of information
• Integrity – testing that ensures that a receiver of a message can determine whether or not the message has been altered since initial transmission.
• Authentication – testing to ensure that sender and receiver are who they say they are.
• Authorisation – ensuring that only authorised parties can request a message
• Availability – testing to ensure the system supports its uptime requirements (must be available 23 hours a day, etc) and the staleness of data. An example of stale data is that when a piece of information gets changed there will be a requirement that all copies of that data are updated within a time frame (maybe 24 hours)
• Non-Repudiation – testing to ensure that an action undertaken by an authorised party is recorded such that they cannot deny the action took place. This is commonly implemented to as auditing.
• Penetration – A penetration test is a method of evaluating the security of a computer system or network by simulating an attack from a malicious source¹

You may already be looking at the confidentiality tests and thinking that Google didn’t test that. It’s not that simple because what is correct disclosure?

When they (Google People) were designing Buzz they probably had some meaningful and great requirements, user stories, use cases or feature lists. These probably specified the automatic following of most frequent contacts, sharing of information between contacts, etc, etc. The underlying concept is that my most frequent contacts are my friends or family.

If I had a Gmail account then that is how my contact would look; friends and family. As you’ve seen from the aforementioned article (link again); that is not always the case.

This leads me back to the confidentiality; there was probably tests run to ensure that people who are not on your follow list cannot see your confidential data. There were also probably tests run that ensure that the follow list was created correctly, etc, etc. These were all based on the requirements and no doubt all these tests passed.

It is my belief that this problem was caused by not engaging testers early on in the process. A good tester involved in the process has the job of questioning everything and coming up with scenarios well before testing that will highlight potential concerns.

Consider this:

A social network relationship is one that is formed between two people. These relationships can be one way or bi-directional. The direction relates to the flow of information.

Example: In twitter I may follow you; this is a by default a one way relationship whilst in Facebook we are friends and that is a bi-directional relationship.

Can you see the problem with the above statement?

The problem is that assuming that the relationship involves people. In terms of the business language in the problem domain you have people in the relationship but in the implementation; what do you really have?

In the sense of Buzz the relationship is actually just a Gmail email address. And an email address is something that is very easy to create.

How is any of this a problem?

Consider a piece of functionality that features often in social network tools; the ability to block a person who you do not want to give access to your information. This leads off the use case: “how do I stop someone following me and seeing my information?”²³ The answer is to “block” them.

What does it really mean though? If a person is just an email address and email address are easy to create how does the ability to block an email address going to solve the problem. If one gets blocked you create another, if you hadn’t already.

This is an example of logically correct rules that are implemented and tested without issue but fail because whilst it is a solution it isn’t a good solution in terms of the user experience.

How does all this relate to a problem facing testers? In my experience there are not enough testers out there that can adequately test the aspects of security and I don’t just mean penetration testers; as there are even fewer of them. I’m not qualified to do penetration testing and I’m the most experienced in the topic amongst the testers where I currently work.

Secondly there are not enough testers that when they are involved early in the project do they sufficiently analyse the system and raise the necessary concerns. Most of them focus on whether the requirements are testable; a worthy goal but nothing in comparison to focussing on whether the requirements are correct.

Finally in my experience the other area that I see testers have the least amount of experience and knowledge is the user experience. Interestingly enough that was the other talked about flaw in the Buzz release (see this article by Dave Winer); automatically signing everyone up. Ironically it was probably done to make the system easier to use; reducing friction and the barriers to participation, etc.

Testing isn’t just about proving the requirements have been implemented correctly. If you’re just doing that then you need to skill up or get out of the game. It’s about challenging assumptions and asking the question why. If we don’t do that then we are nothing more than checkbox in the development life cycle. Quality has been assured. Then again the people who think we are just about assuring quality, including testers, have probably never asked the question; whose quality?

1. http://en.wikipedia.org/wiki/Penetration_test
2. If you want a user story “as a user I want to be able to block people from following me”
3. Or a requirement “A user must be able to block another user from following them.”