An automated testing journey

I did a presentation this evening in Brisbane on an automated testing journey that one may embark on. The whole thing was centered around this tube map style diagram I came up with recently: (download in PDF)

Here’s a link to my prezi slides and it should appear below (if you have flash enabled that is).  You can also download them in very printable PDF if you so choose.

I feel the presentation was well received, but I really shouldn’t have tried to squeeze three days of thinking into 30 mins. Oh well.

As always, I welcome your feedback.

Specification by Example: a love story

I attended a three day Advanced Agile Acceptance Testing/Specification by Example workshop in Melbourne last week run by Gojko Adzic, which I enjoyed immensely.

I took copious amounts of notes so I could regurgitate them here, but instead I decided to do something a bit different and write a story. It’s a story about how a team can apply what he taught us to improve their software development practices. It’s entirely fictitious (although I’d love to live in the Byron Bay hinterland!) and any resemblance to any real person or project is purely coincidental.

So here it is: Specification by Example: a Love Story (PDF). Enjoy.

Dismissing pesky JavaScript dialogs with Watir

Dismissing JavaScript dialogs has historically been an issue when using Watir, demonstrated by the lengthy JavaScript Pop Ups wiki page full of complex, messy code with multiple sleep statements and polling to dismiss these pesky things.

Recently a fellow ThoughtWorker showed me a much simpler and more elegant solution, which he had learned off another ThoughtWorker.

It simply overrides the JavaScript function being called and returns true always, so the dialog never appears.

b.execute_script "window.alert = function() { return true; }"

The beauty of this solution is you don’t need to use problematic click_no_wait method like all the other solutions available, and you can override any JavaScript function, including the three types of dialogs.

require 'watir'
b = Watir::Browser.start "http://www.sislands.com/coin70/week1/dialogbox.htm"
b.execute_script "window.confirm = function() { return true; }"
b.execute_script "window.alert = function() { return true; }"
b.execute_script "window.prompt = function() { return true; }"
b.button(:value => 'confirm').click

The downside is it only works in Internet Explorer at the moment; I am trying to work out why it doesn’t work in FireWatir.

I’ll update the wiki page to include this solution so other don’t waste time on complex polling techniques.

Update: 6 Nov 2010

Jarmo Pertman has written an excellent follow up post to this one, where he talks in more detail about what values you should return. You should check it out.

Agile software, continuous delivery and passionate users

Rowly Emmett, a test consultant who lives here in Queensland, Australia, recently dismissed agile software development in a blog post titled “Agile Recipe“.

“…there is no difference between Agile and Waterfall”

“The thing is, if people followed the (rigourous software methodology or waterfall) process correctly, then they wouldn’t need to try out Agile.”

Rowly says it’s not really about your software development approach, but how rigorous you are in your chosen approach. One of the things that Rowly wrote that stood out to me was:

“I believe the process should adapt to the conditions of the project and the needs of the application.”

But that’s what agile is about isn’t it? Adapting and evolving solutions through collaboration.

Rowly finishes by listing some of the conditions for a project moving to agile, which included:

“Is the domain ABSOLUTELY clear (does the customer really know what they want?)”

But I’d actually say that’s one of the reasons I have seen agile software development methods work over other methods, in that customer needs can evolve iteratively, rather than having to be specified upfront which is more likely to produce something not needed at the end.

I would say my biggest criticism of Rowly’s article, and why I disagree with it, is he’s looking at it from a pure methodoligical viewpoint, rather than what it does differently and what that can ultimately deliver. Sure, a project will fail if it’s done poorly, no matter what methodology is used. An agile project will probably fail sooner, but if done correctly can ultimately deliver better outcomes. Not just that, it’s increasingly anti-competitive to use non-agile methods to deliver software. So it’s no longer a choice, but a mandate. I’ll explain in a bit more detail using a case study.

Google Docs and how they deliver software

I have no idea what methodology Google uses to develop its Google Docs product, but I know they must use iterative agile techniques. How do I know this? Because I am a passionate Google Docs user and I subscribe to the Google Docs blog. Every couple of days Google Docs releases some new functionality into Google Docs, and they write about it on their blog. They couldn’t do this using a waterfall methodology. They’d release new functionality every few months, or years. Compared to Microsoft who bring out a new product with lots of bundled enhancements every couple of years (Office 2003, Office 2007, Office 2010), Google release some enhancements every couple of days.

How does this make me feel as a user? Passionate. I love that there’s new functionality every couple of days, as it allows me to master it and kick ass. As I recently tweeted:

http://twitter.com/alisterscott/status/22256071870

 

Which is exactly how you want your users to feel. As Kathy Sierra explained during her great Business of Software presentation: you don’t just need users who think you’re company is awesome, or your product is awesome, but rather that they’re awesome, when they’re using your product. Like when I showed the expenses app I built with Google Spreadsheets and forms to my wife, and because she was so impressed I felt awesome. Like all the tweets I saw about the Gmail Priority Inbox, something that was delivered immediately, iteratively, not through an ‘upgrade’.

If Google Docs was developed using a rigorous software methodology, it may have only just been released, or it may have not even been released yet. And I certainly wouldn’t have had an opportunity to get excited about all the incremental improvements I have seen over the past years.

Moving beyond the Project into Continuous Delivery

The Google Docs case study highlights a bigger point, that Google Docs is a product, and not a project. As Evan Bottcher (a Thoughtworker from Melbourne) recently wrote on his aptly titled blog post: Projects are evil and must be destroyed, we need to move beyond looking at things as a project that are eventually handed-over to BAU, and move towards “form(ing) long-lived teams around applications/products, or sets of features”. Like the Google Docs team, who continually develop and deliver functionality to Google Docs users (and write about it). There’s a name for this concept, it’s continuous delivery, and a fellow Thoughtworker Jez Humble recently published co-published (with Dave Farley) a book about it, titled Continuous Delivery.

My bugbear with Continuous Delivery

The only downside I see to continuous delivery is when it’s used in an environment that needs to be actively upgraded by users; it’s no point pushing out new functionality daily if your users have to do an upgrade daily. One place I see this happen prevalently is iPhone apps, how many apps need updating every time you check? Too many in my opinion. In a web environment, such as Google Docs, continuously delivery rocks! In a non-web environment, such as iPhone apps, browser, firmware and OS updates, it sucks. As Michael Neale recently pointed out on Twitter.

 

Firefox are doing some work in this space around passively delivering (minor) updates, but there’s still a lot of work to do in this space if we’re going to have continous delivery of non web applications.

Wrapping Things Up

I started off by disagreeing with Rowly in his views on agile software methodology in that it doesn’t matter. I believe we no longer have a choice, we’re at a point where it is increasingly uncompetitive not to be agile, as we need to deliver soon and the way to do this is through iterative and incremental development and continuous delivery. This is even more important for environments where the domain is unclear and the customer doesn’t know what they want. Delivering software this way is also great for creating passionate users who feel they can master what you give them and kick ass.

Thoughts on Thoughtworks Australia Team Hug September 2010

I haven’t started yet at Thoughtworks (it’s still a week away), so I felt very privileged to be invited to the the bi-annual Thoughtworks Australia Team Hug over the weekend in country Victoria.

The weekend consisted of a series of talks and heaps of fun. I really enjoyed the talks by Martin Fowler on DSLs (Domain Specific Languages) and Chris Bushell on how to avoid branching code which was interesting as it relates to the new focus on Continuous Delivery.  I also enjoyed the two Dev-Ops talks, one frightening story by Tom Sulston and a much calmer one by Evan Bottcher. I need to look more closely into the Twist automated testing tool after seeing a demonstration of its features.

Besides the talks, there was a great Wild West themed party on Saturday night, complete with a photo booth that produced lots of hilarious photos. I dressed up as a cowboy, complete with chaps, boots, hat and guns. People went to huge effort in getting dressed up, there was even someone in a giant cow costume!

I managed to fit in a nice morning stroll on Sunday morning to enjoy the fresh country air and surroundings, which was very pleasant as I live in the city-city.

It was a great introduction to Thoughtworks culture and people and an all round enjoyable event.

A ThoughtWorker to be

I’ve recently accepted an opportunity with Thoughtworks, who are setting up a presence here in Brisbane, Australia.

I am thrilled to be offered this opportunity to work for a company who is passionate about revolutionizing IT and is so well aligned with my values and ideas. I found the Thoughtworks recruitment process to be very thorough, whilst not over the top, and actually enjoyable. This is because it gave me a great insight into the company as I got to meet a lot of thoughtworkers, and I felt very confident to  accept the job offer without any reservations. Thoughtworks thoroughness in assessing candidate’s technical ability and aptitude also made me confident that I will be working with other very capable individuals.

I look forward to beginning at Thoughtworks in mid-September as a Senior QA Consultant, and in the meantime I will be having a short break with my family.

Reflecting on this blog

I fired up my netbook tonight to read and reflect on some of my old blog posts. Here’s a collection of my favourite blog posts and a comment about each from my current perspective.

Five organisations I would love to work for (geography aside): Amazingly this two+ year old list is still very accurate. In 2010 I’d possibly drop 37signals from number 5 and replace them with either Thoughtworks or Mozilla or Google. Proving how great Atlassian is, Jeffrey Walker commented on this post, but very sadly, he’s no longer with us.

Software Piracy: I still stand by my views on pirated software being unnecessary, and still love my ‘biting the hand that feeds you’ analogy.

Why I do automated testing: This question still comes up (a lot) when attending job interviews. My answer is, unsurprisingly, still the same.

Version control your tests, quickly, easily, today for free: There’s still no excuse not to have version control of your automated tests. Please do it.

Create fancy wiki home pages with Confluence, Lozenge and Nuvola Icons: A dead simple way to create an attractive Confluence home page with free icons.

Weird ways of working, car indicators, and shoshin: The thing that amazes me today about my eight month year old son is his shoshin, and how he contributes to my own.

Running Watir tests from a Confluence wiki page: Some cool stuff I wish I could use more in my day job. One day.

Five reasons starting with F on why I use Watir: Again, two+ years later and all the reasons are still relevant.

Let me know if you have any favourites or would like me to write about something in particular in the future.

Update 20 July 2010:

Somehow I forgot this post I am really proud of: Software Testing Career Development