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 framework, 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 very useful...

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 a sudden it dawned on me;...

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 base. In these...

This is the second post of some of the things that I find myself talking to business people (and some technical folks too for that matter) when trying to explain agile thinking. Here is the first if you want to read that. Again, the disclaimer, this is mostly stated before and probably doesn’t contain much new stuff if your an agile ninja guy. Please don’t flame me - I’m trying to explain this to people who have done other stuff while you and i was geeking out in agile. One thing that very often comes up is this notion of deployment, and maybe that we rather make small deploys to the production environment often rather than big one seldom. For some that might seem like a no-brainer but actually it’s quite the other way around in most big companies where I’ve been. Let me tell you such a story; I...

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 agilista 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 was thinking...

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 tooling out of the way...

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 zone a bit here. Testing code is different, there...

Last week I attended the premier agile conference in Sweden, Agila Sverige. In one of the Open Space sessions we had a great discussion on why, still to this day, many developers don’t think writing test is important. Or at least boring and second grade job for a developer. The session was suggested by Ville Svärd who apparently has spent quite a lot of time on trying to convince developers that testing is important and also an important part of their job. So the whole session was just us sharing ideas and tips on how to help and convince developer to catch the testing-bug – it was aptly named “Testing is cool!”. Yes, yes – you could argue that it’s simply just to hit them harder and tell them that “They must!”. But I don’t think that works particular well. At least it don’t stick. Around here I got to...

Lately I’ve been coming back again and again the importance of culture in an organization, group or company. It’s the thing that binds you together and with a strong culture in place you can get a very fast moving, quick acting organization without being afraid of the people in it straying away from the important stuff. This topic has been nagging me for a very long time, a few years to be exact. I come back to it again and again in my reasoning and argumentations (probably sounding like an old record that got stuck to some people). But that just because I think it’s super important – it’s the soul of your company if you will. The spirit of a otherwise lifeless entity. This blog post is probably just scratching the surface of book length material. Bare with me – I need to get this out now. US Marines...

  A fantastic thing has happened to me. A couple of months ago I got the strangest mail sent to me. It was from Manning Publications and asked me if I would be so kind as to phone a person called Michael there. I understood it as if Manning was going to launch a book on Kanban and if I could come with some ideas or suggestions on the proposed content. Mike and I talked for awhile. What have I done around Kanban? Could I please describe it in 5 minutes for a total newbie (not that Mike was that :))? What would I see in a book on Kanban? questions like that for about 45 minutes. Then - all of a sudden - the final question (just about the time as my twins were tearing down the door and entering the room, i might add): > > > Would...