How many tool you need to know?

This is just a quick note from a nice summary:



Symptoms of bad “good test”

It’s not only the test which fails are bad ones, sometimes the “passed” ones are bad as well if they fall into following category:

  • The test does not have any impact on the coverage/confidence; that means: if you remove it, you do not have less confidence; vice versa, you do not get extra confidence by adding it;
  • Freaky tests, sometimes it passed, sometimes it failed. People said, it’s ok, just rerun it.
  • Takes long time to execute, indicator of you need to refactor it.
  • Bad readability, confusing names could not help people understand the test intension.
  • Complex test, may need to decompose;
  • The test does not fail when the key tested functionality changes significantly;
  • Nobody dares to change the test;
  • One test covers multiple functionality 


The tests are passing but you can not get any confidence;  if you remove it, it does not change the coverage;

Team Foundation Server in Agile world

TFS is widely used in the .net development. This blog will talk a bit about TFS and Agile.

Why TFS?

TFS is marketed as an alternative to Rational Clear case, its trying to give a broad range of features and workflows that are simular so its not a huge jump to large organisations. The use case in these types of environments is developers working on branches and checking into trunk or even a team branch infrequently, hence to ceremony is high as its a big event.

Once started the iteration development, these ceremonies now become burden.

Key Functionalities

The essential part of TFS is made of three parts:

  1. Work Item Tracking
  2. Team Build
  3. Source Control

Work Item Tracking 

The current TFS and TFS 2013 are started to supporting Enterprise Agile oriented features. Examples are:

  • Virtual Story Wall
  • Agile Portfolio Management (aka Epic in Jira, Mingle and other tools)

What you can do with the item tracking functionality is you can actually create story, issue, task or defect in a pre-defined work flow. One tip here is to do not define over-complex process upfront, as later on when you want to change it, it will become difficult. There is a “process editor” included with TFS power tools, you can change the work flow in fly, yet the user experience is not very nice.

The corresponding alternative could be Jira or Mingle.

Team Build

Team Build is the system that is supposed to build, test and deploy your code. When review this kind of capability, need to think about whether this be enough to support continuous delivery, at least continuous integration.

The current Team build could not easily support the build pipeline, finish one build then trigger the next dependent build; could not pickup the artefact to run further steps. I might overstate this inability as there might be workaround to do is, but this will start a door of workaround nightmares.

Alternative could be Go, Jenkins and TeamCity.

Also, with TeamBuild, the process of getting a build job to do something other than the default (which is very likely we would do, as using NUnit rather than MSTest) is rather painful and horrible involving visual designers and enormous XML files.  The other tools mentioned above, will let me change this by supplying simple script files for each build step.


Source Control

Giving the nature of Agile iteration development, that means the team needs to work in a fast pace; the work needs to be integrated more often. One of the big pain of TFS is the server side merging (caused by people check-in changes without latest copy of code) and looks like Microsoft realizes this as well. TFS is now supporting Git client, yet still has its own limitations of working together with it’s own repository.

Alternative could be Git, bitbucket, mercurial or SVN. 


On the way to lean

Below are suggestions from one of the lean experts, think it might help if someone on the same journey as I:
  1. Read lots of books.  Reading lots of books allows you to get multiple perspectives and pick up different interpretations.  
  • started with the Poppendieck books (Lean Software Development, Implementing Lean Software Development, Leading Lean Software Development),
  • then the Womack books (Lean Thinking, Machine that Changed the World, Lean Solutions),
  • then the Liker books (Toyota Way, Toyota Way Fieldbook, Toyota Culture, Toyota Talent, Toyota Product Development System, Toyota Way to Lean Leadership),
  • then more classic works by Taiichi Ohno (Toyota Production System, Workplace Management).  
  • I like The Birth of Lean for a broader historical perspective.  I like Managing to Learn for A3 thinking, Learning to See for value stream mapping, and Getting the Right Things Done for hoshi kanri.  Toyota Kata is good for problem solving and leadership behaviour.  For product development, I like Lean Product and Process Development, the Kennedy books (Product Development for the Lean Enterprise; Ready, Set, Dominate), and the Reinertsen books (Managing the Design Factory, Principles of Product Development Flow).  It’s worth reading Kanban by David Anderson, The Lean Startup by Eric Ries, and possibly Lean Software Strategies

2. Do site visits.  I spent some time with a Lean community group based out of Parramatta which was interesting only because of the site visits they set up.  The Toyota plant in Altona, Victoria offers free plant tours.  You just need to call them.  I also did a Lean study tour in Japan.  I’d recommend the Japan Kaikaku Experience ( if you want to do that.

3. Attend a Lean Summit.

4. Try it out myself. Try using the problem solving approaches and other techniques to deal with the actual situations you are facing.

5. Subscribe to Lean blogs, this might go away after July 1 as google is dismissing its reader:

Visualizing code dependencies

When you want to improve your code, make it more testable, you start to realize there is too much dependencies within the code, far more complex than you can handle. There are several tools you could use to make it obvious so you can act on later.


If you’re working on Java, then there are a list of tools you could select from:

  1. : this could handle multiple projects, within a project …, but the graph takes a bit time to understand;
  2. Structure101 
    it provides an architecture review and a wealth of functionality including cyclical dependencies (also fat classes etc..) and the ability to ‘experiment’ by moving classes into different packages to reduce coupling.You can view the dependencies high level or drill down to the class level or even a mixture.
  3. CodeCity

Things to consider when choosing a tool:

1) Scalability of visualizing

2) Learning Curve

3) Integration with development toolchains

4) Experimental advice 

5) Opensource


Start build an mobile app from scratch

1. Created a source repo on “Bitbucket”

2. Created the corresponding directory on my local (Mac) and do the initialization as following:

  • git init
  • git remote add origin ssh://[user name]/[project repo]

3. Choose an mobile framework to start

There are two candidate platforms:  Calatrava and Cordova(PhoneGap). As Calatrava is pretty new, I would like to give it a try and evaluate it from a complete perspective:

  1. Document
  2. Community support
  3. Mobility
  4. Testabilty
  5. CIability
  6. Limitation

4. Get started with Calatrava

Calatrava can be found at:; more detail info can be found at:

5. Issues while creating first calatrava project

  • calatrava create toyCalatrava

{“template”=>”/Users/may/.rvm/gems/ruby-1.9.3-p125/gems/calatrava-0.6.6/lib/calatrava/templates”, “dev”=>false, “no-ios”=>false, “no-droid”=>false, “no-web”=>false, “android-api”=>”17”}
android create project –name ‘toycalatrava’ –path ‘toyCalatrava’ –package com.toycalatrava –target android-17 –activity ToyCalatrava
Error: Target id is not valid. Use ‘android list targets’ to get the target ids.

==> Solution: update android SDK, to api 17 does solve the issue. Verify the result by using “android list targets”.

6. Project successfully build for web, android

7. Build issue on iOS, refer to .

What Makes A Good Test – Visible

In last blog, one important attribute that makes a good test is “Independent”. This is important because of it is related to the test writing, test execution, test maintenance as well as concise test feedback. 

Another key value-added attribute of a good test is – “Visible”. How do we define “Visible”?

  • The test is well-understood by all levels of stakeholders
  • The test strategy is visible
  • The test existence is visible
  • The test execution is visible
  • The test management is visible
Useful methods/tools to help make our test visible:
  • Stakeholder analysis: decide who to invite for test strategy defining;
  • Collaborative Test Strategy defining with all stakeholders, to come up with the communication plan, priority, risk/mitigation plan, resource, tools, constraints, 3rd party management and etc; the agenda could be pre-defined plus nominated topics as well;
  • Code analysis tool (like Sonar, Coverity) to show the history, current status of existing code base.
  • Appropriate test integration to the CI (Continuous Integration) process, utilising the RED/GREEN light. As well as how many times the build was failed because of testing.
  • Visualize the bug management effort: to make sure the bug is treated seriously, tester has to correctly label and prioritise the defect with a collaborative effort. To raise the awareness, could use different stickers to note different importance level.
  • Visualize the test optimising effort using “Test Healthy Indicator”: The “Test Healthy Indicator” could include: coverage, speed, refactor, failing frequency. This could customise according to different project needs.
What kind of benefits we can get while making test visible:
  • Enables better test reuse as it increases people’s awareness of the existing testing suite;
  • Enables better test maintenance as any breakage is easier to detect
  • Enables better team engagement