Automated GUI testing

Details

Created: 15 October 2014

Automated testing is a key part of agile development. If you are changing software in frequent small increments, you need to be sure that your new changes have not broken the existing code. Because the increments are usually between one and four weeks long, there is no time for test regimens that take weeks to complete. And manual tests become especially tedious (which leads to errors and oversights) if they have to be repeated frequently.

GUIs are frequently considered something difficult to test in an automated fashion. One thing that can help a lot is separating the production of data from the presentation of data, using the Model-View-Controller, Model-View-Presenter, or Model-View-ViewModel design patterns. (Here is a good overview of the differences between MVC, MVP, and MVVM.) In all three of these design patterns, the Model is the part of the system that contains its state and performs all calculations.

You can write automated unit test programs that call methods in the Model and check for expected results, just as with any module, without worrying about how it is presented on the screen. Testing the GUI itself is just a matter of making sure that when you click on a button, it sends the right signal to the ViewModel, and when you pass the View Model a particular value, it is properly displayed. Even if you have to do these tests manually, it is easy to write a test driver that tells you when each button has been clicked, and populates each display with dummy data. This is a lot easier than trying to figure out what you have to do to the system to make it display a particular thing.

There are some other benefits to separating the production and presentation of data. It can make it a lot easier to change the GUI without fear of messing up the data production. For example, Boonex Dolphin, a content-management system for social websites, does not directly generate its HTML web pages. Instead, it generates XML, which is run through an XML stylesheet (XSLT) to format it into a web page. This lets the web page designer concentrate on the design, without having to worry about the business logic. It also makes it easy to have several themes available, completely changing the look of the website, by just changing the XML stylesheets, without changing the business logic of the website.

Another example is XAML (Extensible Application Markup Language), an XML-based markup language for designing GUIs. It is used by Microsoft's Windows Presentation Framework and Silverlight application-development frameworks, as well as NoesisGUI, a platform-independent GUI middleware package that is available for Windows, OSX, and Linux, as well as several popular game and rendering engines.

A designer can design a GUI either visually, using Microsoft Blend or Microsoft Visual Studio, or by hand with a smart XAML editor like Kaxml that immediately displays how the XAML will be rendered. The designer can concentrate on what the page looks like, without having to get involved with how the data is calculated.

This allows separation of duties: someone who is good at design can design the GUI, and someone who is good at code and business logic can code the Model and ViewModel. Even if you are a one-person indie shop, and have to wear several hats, it is easier to be in a design headspace or a coding headspace, and not be constantly switching back and forth between the two.

Yet another benefit is code reuse. If your business logic is not tied to the GUI, it makes it a lot easier to reuse it in a different application.

Designing your GUI for automated testing helps you meet your sprint commitments, makes changing it easier, and makes your code more reusable.

What's not to like about that?

Business 101

Details

Created: 30 September 2014

Recently I was working with a team that was having trouble getting testing tasks done, because some of the developers did not like testing; they wanted to write code, because if was more fun.

At the risk of preaching to the choir, let me explain how business works:

1. A business employs people and asks them to make stuff. The employees would rather be doing something they would like to do, so the business pays them in order to give them an incentive to come to work.
2. The business sells the stuff that its employees make. Customers exchange money for the stuff, because they don't have the time or the expertise to make it themselves.
3. The business takes the money from the sales of the stuff, invests some of it in the business, pays some of it as dividends to shareholders, and pays some of it to the employees from step 1.

As long as the employees are making stuff, and the customers are buying stuff, we have a continuous cycle and a successful business.

Notably absent in the above description is "The business pays employees to come to work and only work on fun stuff."

Elbert Hubbard, a 19th century American writer and philosopher said:

If you work for a man, in heaven's name work for him. If he pays you wages which supply you bread and butter, work for him; speak well of him; stand by him, and stand by the institution he represents. If put to a pinch, an ounce of loyalty is worth a pound of cleverness. If you must vilify, condemn, and eternally disparage, resign your position, and when you are outside, damn to your heart's content, but as long as you are part of the institution do not condemn it. If you do that, you are loosening the tendrils that are holding you to the institution, and at the first high wind that comes along, you will be uprooted and blown away, and will probably never know the reason why.

Now that may sound terribly old-school. The social contract of loyalty between employers and employees is much weaker than it was even 50 years ago, when working hard your whole career almost guaranteed that the company would take care of you. (This is the social contract Billy Joel sang about in Allentown.) Today you can get laid off at a moment's notice, or your can give your two-weeks notice, and nobody raises an eyebrow.

No, this is not about being loyal to your company because it is the noble thing to do, but because if the company is paying your wages, it is in your best interest for the company to stay afloat.

There is an old story called A Tale of Three Bricklayers. (Josh Allan Dykstra has a good article about this.) It goes something like this:

A man came upon a construction site where three bricklayers were busy at work. As he meandered through the site, he asked each bricklayer what he was doing.

The first one said "I'm laying bricks."

The second one said "I'm building a wall."

The third one proudly proclaimed "I'm building a cathedral."

Developers who do not want to perform testing tasks because they are not as fun as coding are like the first bricklayer. They may be excellent coders, but they are not looking at the big picture of what the company needs in order to survive.

They are frequently long-time employees, and they are like the mice in Who Moved My Cheese?, by Spencer Johnson (one of the great agile development books, in my opinion). For as long as they could remember, there was a big pile of cheese next to their home, and when it finally ran out, some of them could not believe that their world had changed so radically, and just sat there, waiting for the cheese to come back.

There was a time, in the days of old, when being a hotshot coder was enough, and if one didn't want to help with testing or documentation, there were other departments for that. And anyway, being a hotshot coder made one close to god-like.

But the times have changed: agile development is the industry standard, and customers are beginning to expect faster response to their requests than the once-every-18-months cycle that used to be the norm.

Developers who consider themselves above tasks like coding, or ones who don't want to work on anything that isn't fun, will eventually face one of two things:

• the company will realize that they are impeding progress and will let them go, or
• the company will let them continue to be a spanner in the works and demoralize the developers who are trying to do agile development, and eventually they will take the company down.

Either way, they will be out of a job.

Class bells

Details

Created: 06 October 2014

When I attended General Motors Institute (now Kettering University) in the early 1970s, it didn't have the free-wheeling feel of many college campuses. It was part of General Motors back then, and shared a lot of the traditional General Motors conservatism.

One thing that really irritated me at the time was the class bells. It made me feel like I was still in High School, especially when my friends at other colleges told me that they were just expected to show up to class on time, without a bell prodding them.

But with a few more decades under my belt, I'm beginning to think the bells were not such a bad idea. Today we have lots of meetings, and most of them start and end on the hour. A few enlightened teams start their meetings at five after the hour, and end at five before hour, but not very many. And meetings frequently run over their time box, because the participants figure since it is only 10 or 15 minutes, it is easier to keep going than to schedule another meeting. But those 10 or 15 minutes don't belong to them. If participants are due in another meeting, all the people in the subsequent meeting need to wait for them.

That is where the class bells would help. If we had a bell (or better, a soft tone over the public address system) at five minutes after the hour and five minutes before the hour (perhaps the half-hour, too), it would remind people that they have to end their meeting so that people can get to their next one.

Actually, it would not be all that difficult to tie the room reservation system in with one of the desktop alerting systems, like SnapComms, NetSupport Notify, or Alertus, so when the meeting has exceeded its timebox, a message scrolls across projector screen saying "This meeting has ended. Please clear the room for the next meeting." This would avoid disturbing people who were not in the meeting.

Some would argue that trying to solve a behavioral problem with technology is focusing on the wrong thing. However, my experience has been that it is sometimes the only way. If you tell people to end their meetings on time, many will feign agreement, but continue to overrun their allotted timeboxes. If you use technology to make it inconvenient for them to exceed their timebox, they are then in the position of either putting up with the inconvenience, starting to behave right, or complaining about the end-of-meeting messages and explaining why their meeting is so important that it should be allowed to impinge upon other people's meetings.

It all depends on the company culture. In some companies, all you need to do is to get mid-level management to proclaim that meetings should not overrun their timeboxes, and set a good example by ending their own meetings when the timebox expires. In other companies, particularly mature companies where people are set in their ways, you may need to use technology to influence them.

Are you writing fake canonical stories?

Details

Created: 23 September 2014

A popular template for user stories is

As a <persona>, I want <some goal> so that <some reason>

For example,

As a blogger, I want the blog system to return a permalink to my posts so that I can give a stable link to people who want to refer to them.

This is variously known as the canonical form, the role-feature-reason form, or the Contextra from. (It was popularized by Rachael Davies when she was at Contextra.)

The format is widely recommended. Mike Cohn lists some of its advantages here.

Recently, I have been seeing a lot of what I would call fake canonical stories. Here are some real-life examples, slightly edited to protect the authors:

1. As a DBA, the <product> should generate a report of all database changes.
2. As a <product> user I want to make the <feature> process easier for users.
3. As a user of <product>, when a problem is encountered with the <feature>, the <option> should enable the <product> to facilitate the request by 'failing over' to use <other product>.

The first story implies that the DBA and the product are one and the same. The second implies that the users, not the developers, are the ones enhancing the product. And the third one is just ungrammatical and difficult to parse.

The authors of these stories realized that they were supposed to put "As a" on the front of their stories, but they didn't really understand why, so they were just going through the motions.

Why do we write stories in canonical form? It is not because some Scrum book, or Scrum Master, or Agile Coach decreed that all stories must start with "As a". No, there are sound reasons why we do this.

The first is that it makes clear the viewpoint of the person who is requesting the story. Consider these hypothetical stories about a password mechanism:

1. As a Security Officer, I want passwords that are hard to guess, so people don't break into my system.
2. As a User, I want passwords that I can remember, so I have half a chance of being able to log in.
3. As a Hacker, I want easy-to-guess passwords, so it is easy to hack the system.

The third story wouldn't actually be in your backlog, of course, but my point is that the knowing the persona that wants the enhancement helps a lot in understanding it.

Some teams go as far as defining personas that typify what they think their customer roles are like, for example, "Terri is a 59-year-old database administrator who is much more comfortable with green-screen terminals than with the web." But that is a topic for another post, especially since there is some controversy about coming up with stereotypes about one's customers.

The second item in the canonical form is what the story is asking for.

The third item in the canonical form is why? This helps clear up ambiguities in the what.

Let's look at the first story, slightly edited to be more grammatically correct:

As a DBA, I want the <product> to generate a report of all database changes.

Should this report contain:

• Just the number of changes, so the DBA can know the level of activity for each database?
• The time, date, and user ID of each change, so the DBA can watch for suspicious activity?
• Before and after images of each changed field, so the DBA can see how the data is being changed?

We don't really know. But if we rewrite the story with a why clause, it is much easier to know:

As a DBA, I want <product> to generate a report of a database changes, so I can see who is modifying the database.

One could argue that this could be dealt with in the what clause:

As a DBA, I want <product> to generate a report listing the time and date of each change to a database, as well as the name of the database and the user who made the change.

But this is getting into the details too early in the design process. Initially, a story is a conversation starter. Given the who, what, and why of the story, the Product Owner and the team can develop the story further and come up with the details that will go into the acceptance criteria.

Do stories always have to be written in canonical form? I have yet to see a story that couldn't be written that way, so that is generally how I write my stories. But with some stories, it isn't really essential. For example, on a new project, you might have a story like this:

We need to set up a Git server to be our source code repository.

or like this:

As a developer, I would like to have a Git source-code repository so I can commit changes and roll them back as necessary.

Does the second story impart more information than the first? Not really. We know why we need a source code repository, and the reasons are actually too many to express in a one-sentence story.

But this is an infrastructure story. In a feature (customer-value) story, it is much more likely that you will need the canonical form to provide the information needed to properly start designing the story.

Depending on the story, you may or may not need canonical form. But if you use it, please use it, rather than just slapping "As a" on the front. I think you will find that using the canonical form helps stories be the good conversation starters that we would like them to be.