Thursday, 19 October 2006


Fit/Fitnesse ( has been adopted by some projects at my current job for 'automation' testing in the UAT process.

Now I can see automated testing is needed in UAT, esp useful for regression testing. However the Fit/Fitnesse framework only works for java based apps, and hooks in at the class level. A big problem with it, is it requires java developers to write the tests.... so there's stumbling block number one -- business users aren't java developers - so either grad students (who work a few days a month if we're lucky), or external consultancies are used to build these tests. How they are maintained, I have no idea!

IMHO (and in most of the software testing world!), UAT should be testing end-to-end business processes, not messin about with the java code. When using an automated tool, it should interact with the UI, as this is where the end user interacts with the software. Often a business process will jump into various different apps, or even paper/offline processes.

To me, this seems too much like low level testing that is done at unit/integration or system test phases. Note the 'U' in UAT stands for 'User'. If it's not simulating user interaction, it ain't a UAT test.


  1. Amen sister, currently goin toe to toe with ThoughtWorks over the same issue. In ThoughtWorks land their are blue skies, rose tinted goggles and developers that test.

    If we have testers witting java code for fitnesse tests, "where is my test independence" i cried. ThoughtWorks response? "my, aren't you a suspicious little tester".

    Well yes, yes i am, and that is what makes me a tester Oh you Agiler developers can have your TDD badge, but i'll still find 80% of the defects in 20% of code you tested!

  2. argh posted before I could finish it. that's one bad thing about blogger - no comment editing (or I might just be going blind)?

    Anyhoo... software testing can be hard enough at times just validating the 'tests' being run are correct, without having a whole level of possibly buggy test framework getting in the way also.

    In some cases, the risk of 'buggy' tests is acceptable, in others it's not - depends on the project, the environment you're working in, and your own skillset to identify issues in the test framework (and being humble enough to have devs raise bugs against your test code in a bit of a vice versa moment hah!).

  3. Yes, not having edit sucks.

    When i typed their, i meant there, but was thinking about their view of the world, and an errant R decided to mate with Agile.

    anyhow - Yeah, in its simplest form testing is simply checking that a clearly defined set of requirements has been met (checking for deviation from the expected). Obviously the Agile methodology tries to do away with a lot of the process that front loads a traditional waterfall project. This is mitigated by the developers writing to code to pass the tests created by the test team. But the test team have no clear requirements, just a bunch of high level (and somewhat woolly) stories. As usual the devil is truly in the detail. So the question is a biggie (an octopus out of the string bag), who tests the testers tests? The BA? I don't think so.


  4. Thanks for sharing such great information with all of us. This is one of the blogs that come with new idea. This is the first time for me that I am commenting on a blog. Though I read many articles on team online and blogs too but never give any response to any one.