Agile projects, even fake ones (which don't do automated testing and continuous integration at all), use story cards, that is, writing requirements on cards (commonly, index cards used). But the fact is that nowadays most of people's handwriting, like mine, are not very recognisable (a less polite word: sucks). Story cards are conversation starters in agile projects, but only can be effective if team members can read the text on them.

Almost every project team I am involved likes the idea of printing story cards, this can be easily done in StoryWise. After entered or imported user stories in StoryWise, you can generate story card PDF from user story list

or from the story details page


, and you will get

Then you set up your printer with specified paper size 152x102mm to print it out on index cards.

Watir supports most HTML tags, and we use them to drive the testing:

link(:text, "some text").click
td(:id, "special_cell").click

How to test tag (such as TH) which are not supported by Watir? You can use xpath to identify the element. Let me illustrate with an example: a tester wants to click the table heading 'LOGIN' on the page below:

<th abbr="Login" scope="col">Login</th>

It does not even have a ID! We could use the xpath to find the element: tag is 'TH' and attribute 'abbr' is 'Login'. Here is the test script:

ie.element_by_xpath("//th[@abbr='Login']").click

To verify the solution, I modified the source to show a JavaScript popup window on clicking this table heading. And out test script worked:

Today I picked up Kent Beck 'Extreme Programming' book from the bookshelf, what's a great book! Last time I read it was about 5 years ago. The XP practices now make even more sense to me. However, over this period, I saw more projects branded themselves 'Agile', 'Scrum', few doing XP. Why?

With the help of James Shore's Scrum and XP Practices: Cross Reference, we can do a quick comparison

• Stand-Up Meetings XP: Yes, Scrum: Yes
• Continuous Integration: XP: implied, Scrum: n/a
• Ten-Minute Build XP: Yes, Scrum: n/a
• Simple Design XP: Yes, Scrum: n/a

  If a programmer thinks it is easy, then he/she is still in "don't know what you don't know" stage.

• Pair Programming XP: Yes, Scrum: n/a

  Maybe a controversial one, but there many studies approving pair programming achieve better productivity with lower rates

• Single Code Base XP, Scrum: n/a

  I have seen too many times, several junior level developers (not by age) got excited talking about branches, always end up with disappointments.

• Refactoring: a core practice in XP, n/a in Scrum

  Note if you don't have unit tests, it is NOT refactoring. What's your project's unit test code coverage?

• Customer Tests XP: implied, Scrum: n/a

  Getting customer to write/review automated tests prevents miscommunication.

• No bugs: XP: Implied, Scrum: n/a

As you can see, XP practices are more real, for my experience, found more used in successfully projects. Few people claim their doing XP as it is can be easily checked against the above list.

Scrum is, in my opinion, a more abstract version of XP and the word 'sprint' sounds cool. I remembered that in a group session at one conference, one attendant called out "Who else hate Scrum?" For me, what flag you fly up doesn't matter, how you do it matters. Story cards and stand-up meetings don't make projects 'Agile' (I am sure you have seen enough Fake agile projects like me), automated testing (unit and functional UI) and continuous integration do.

Quite often, we receive the following questions:

• Which test framework do you suggest, RWebSpec or Watir or Selenium?
• Which BDD framework is good for automated test scripts, xUnit or RSpec or Cucumber?

These kind of questions are not easy to answer, as people have different preferences. Now we created a public GitHub repository, you can try out and compare them yourself:
https://github.com/zhimin/adminwise-ui-tests

A test web site is created for this, you just checkout (or download) the test projects (six of them), open one in TestWise 2.

Two days ago, I received a marketing email from HP with subject "Be the first to own the HP TouchPad". Inside, "Works Like Nothing Else", "Everybody on HP TouchPad", "There is nothing like it", you may still visit its web version on HP.

Guess how much how much could change in 2 days? Today, 2011-08-19, news come out that "HP will discontinue its TouchPad as well as its WebOS phones". I feel sorry for people who just bought it.

This is just another example of sales/marketing guys will sell you dying animals. It happens so common in our industry that whole project team suffers from some manager/architect's decision on a product (usually expensive), knowing there are much cheaper or free products out there are a lot better. I am sure these managers/architects won't do grocery like this (as that will be own money), he/she will try and pick up most value for money products.

My point in the context of testing, when choosing a testing tool/framework, try it out for a week, see how much effort for the team to learn and how it cope with application changes? This is common sense really, isn't it?

Today I came cross to the Martin Fowler's Version Control Software Survey. Ironically, commercial and expensive VCS such as TFS and ClearCase are behind, correction, far far behind free ones such as Git and Subversion rated by thoughtworks consultants. Given the nature of version control software, it is hard to be critical against free good working ones, as they are widely approved by large software projects, why there are people still paying money for more problematic ones? Sounds crazy, but this happens all the time, remember old expensive J2EE containers, it turns out free Tomcat suits most projects, free and more stable.

This kind lack of common sense: prefer very expensive and useless rather than working and affordable happens to our testing world as well. Do you know projects who buy very expensive testing tools which generate unmaintainable test scripts, eventually left on shelves, I bet you do, as I heard all the time during testing conferences. But there is a hope, I see increasingly more testing job ads on Watir and Selenium.

Occasionally we got questions on use of defect tracking system, my answer is "try not using them if the team is co-located". To back up my claim, I quoted from the two classic books below:

From 'Agile Testing' book, "New agile teams usually have a hard time believing it can be done." "The objective is not to get ride of a defect tracking system -- it is to not need to a defect tracking system. There is a big difference. This trick is to expose a defect the moment it occurs."

From 'Extreme Programming 2nd Edition', "At first, American workers can't believe this. Chet Hendrickson told me the story of his brother-in-law who worked at a Toyota plant in Kentucky. He saw a defective door go by. His buddy said, "Pull the cord." Nah, he didn't want to get in trouble. Another defective door. Another. Finally, he pulled the cord. He was praised for telling the truth and pointing out flaws. Unlike mass-production lines where someone "down the line" is responsible for quality, in TPS the goal is to make the quality of the line good enough that there is no need for downstream quality assurance. This implies that everyone is responsible for quality."

News: Oracle Seeks xE2x80x98BillionsxE2x80x99 From Google in Java Patent Lawsuit for use of Java in Andriod. When Google acquired Android, why tied themselves to a technology belong to a potential competitor (Sun, then Oracle). With talents in Google, it shouldn't be too difficult to implement the idea in free languages such as Ruby or Python. Surely it will be of some work extending the language, but it won't cost 'billions', let alone on-going license fees. Apple is smarter on this.

To extend the thought further, It seems Google, with all respect, is not winning against companies embracing free and scripting languages, namely:

• FaceBook, implemented in PHP
• Twitter, originally created in Ruby on Rails

Today I came to this news: Windows SkyDrive Says Sayonara (Goodbye in Japanese) to Sliverlight, Embraces HTML 5. The rumour has been around for while (see this: Microsoft is Starting to Dump Silverlight, Phased Out of Microsoft Services). Now it sounds like poor Sliverlight is being dumped by its parent.

It saves us from answering the enquiry: "Does TestWise support Sliverlight?". I had a look on Sliverlight before, my impression: complex and hard to test. The designers didn't leverage the success factors of Web(HTML): simple and "Power of Text" (a principle of the classic book: Pragmatic Programmer).

Update (2011-06-22): Wired magazine just published an article on future of Adobe Flash, one developer says "itxE2x80x99s dead in the water".

Months ago, I promised to blog about each of ten steps in Continuous integration, here they are, all in one go. They are in a format of brief introduction and hints, I hope you find it useful!

Click on picture to enlarge