I have been diving deep into automating web pages for my current client. I have a love – hate relationship with this. It’s quite cool but I would also recommend against using it. I wrote about why just a post or two ago so I won’t repeat it here.

In this post I will instead acknowledge the fact that we are going to automate against the web page and do our best to handle the brittleness of such tests. One challenge that you are facing when writing code to automate elements of a page is to actually get hold of the elements themselves. This is done in different ways with different automation frameworks, but typically you can search by Id (or other attributes on the elements), order in the page, and position.

In this post, I will examine those different approaches and suggest one way that I’ve found...

A couple of years ago I attended a course with David J Andersson, father of Kanban, on Kanban. I learned tons of stuff that I now use everyday but one quote really stood out for me. We were talking about prioritization and how it’s often hard to get business users to put values on a certain item and thus making them hard to prioritize. David said:

If you get a bad answer you have to ask a simpler question

I think it’s brilliant. It’s actually up to us to help them be able to answer the question we want. So we have to help them understand the question better. (In this case you might ask them to draw a graph showing the possible revenue or cost or something). Since then I’ve been carrying this thought with me; ask simple questions. And then all of...

I’ve been putting together a sample for my client on how to automate against a web page. The purpose is to show how the tools are used and give a starting ground for training and elaboration. When I was done I realized that this could be useful for many – so here is my story on how I set this up, problems I’ve ran into and solutions to them and the code. Please join me on the journey!

Why test against the UI now again?

The first thing to notice that testing against the UI is not the best thing you can do. There’s an excellent article on that by Gojko Adzic here. But sometime you don’t have much choice, the application may not be in shape for writing tests against a level under the UI, or you don’t have access in (or knowledge about) the code...

This is the second post in a series where I discuss agile concepts with business people (and some technical folks too). Here is the first post if you want to catch up.

Again, a disclaimer: this might seem basic to agile experts. Please bear with me as I explain these ideas to people who may not have immersed themselves in agile methodologies.

One common topic that comes up is deployment frequency. Many organizations prefer to make big, infrequent deployments rather than smaller, more frequent ones. While this might seem logical to some, it’s often the opposite in large companies. Let me illustrate with a story:

I once consulted for a major insurance company in Sweden. They, like many in their industry, did four releases per year, aiming for “stable IT.”

Let’s pause and consider this. If you deploy only four times a year, stakeholders and projects will try to...

This post need to start with an disclaimer;

I write this since I have run into several people to which these thoughts are new and confusing. If you are an agilist you will not find anything new or exciting here.

Really… there’s nothing new to see here. Go away you scrum-lovers - this is not aiming for you.

How’s that for scaring people away from a blog post. If you’re still around… Anyone… Hello? Ah - there you are. Well – let’s get started then.

I recently have introduced agile in a large company and tried to do it through the whole company, business and IT working together in brotherly company. As you can imagine I ran into some problems. And still to this day we need to explain for the business why they would and probably should look into agile thinking (or was it lean maybe?). I...

This is the last post in my series on how to motivate developers to write test for their code. Please read the first two posts to get some context (part 1 and part 2).

This post talks about the last part of the Switch Framework – Shape the path. This is all about making the change easier by helping our rider and elephant to get a smooth path to walk on as they change.

Tweak the environment

This talks about changing the environment in which the people we’re trying to change so that it’s easier to change than to not. Microsoft lately has use the expression; “help developers to fall into the pit of success”. I like that a lot – that’s what we want here; it should be easier to do right than to not to.

Everything you can do here to get the...

This is the second part (read the first part) of my trying to get inspiration from the Switch book on how to get developers to realize that we also need to take our responsibility for the quality to test. It not just the testing departments problem. As W. Edward Deming put it;

“Quality is everybody’s responsibility”

Last time we took a look at the first principle – Direct the Rider. This time the turn has come to the elephant in the kitchen. The emotions and things that we cannot control by pure will power – it’s time to see if we can Motivate the Elephant.

Motivate the Elephant

The elephant is lazy; he doesn’t want to write more code than necessary or write stuff that probably somebody else will find anyway. Also the elephant will be pushed out of his comfort...