Test Management Forum – 27 July 2011


The thirtieth Test Management Forum took place today (27 July 2011) at Balls Brothers in London, EC3 and as usual there was a varied programme.  The first talk I attended was by Andy Redwood who was telling us about the psychology of testing and what makes a ‘tester’ tick.  Amongst the things Andy was telling us about was the importance of what he called “Social Construction” – how society works in different cultures and the significance of this in today’s global business culture.

Andy also told us how he goes about forming role descriptions and an experiment where he asked people to describe themselves.  He found that the statements so generated fitted into five categories:  Social Role; Personality; Interests and Tastes; Attitudes; and Current State.

An issue I had with Andy’s talk, though, was that he seemed to be adopting a narrow view of testing and appeared to ignore context a lot in what he was saying.  One example of this was that he was describing testing as just being about ‘breaking things’.  There was an assertion that all tests should be designed so that they fail.  The idea behind this, I think, was to mitigate the ‘absence of defects’ fallacy where people claim that the software must be right because there are no defects.  However, what about the different objectives of testing?  What if the objective of testing is to show that a feature works in a particular way?  What if you want to prove that a particular area of functionality is present?  I am not saying that you would not do some detailed tests to make sure that the software is not behaving in certain ways but I think you would major on simply proving the existence or behaviour of the function or feature to start with.

Andy also reminded us, though, that we find it difficult to find more than 30% of our own mistakes when we are proof-reading or checking our own work.  That is why it is very important to have peer reviews and solicit the opinions of others.

After the break I attended a talk by Steve Allott from Electromind entitled “Agile in the large”.  Steve discussed a rebadged incarnation of DSDM (Dynamic Systems Development Methodology) called DSDM Atern which has four underpinning principles:  Process; People; Products; and Practices.

The general consensus of opinion seemed to be that, while it is not impossible, it is difficult to port pure agile practices over to large projects.  Typically this is because on large projects there tends to be challenges such as geographical and cultural separation and much higher numbers of people involved.  It would be difficult, practically, to run a Scrum team with a team of one hundred people for example.

I intend to do some more reading up on DSDM Atern because I know very little about it.

I thoroughly enjoyed the afternoon and my special thanks to Paul Gerrard and Susan Windsor from Gerrard Consulting for organising the event for us.

Advertisements

4 Responses to “Test Management Forum – 27 July 2011”

  1. Lisa Crispin Says:

    I’ve personally worked in a dev org of 140 ppl w/ 25 Scrum teams, worked fine (there was a cultural problem, but nothing to do with agile practices or Scrum process), & I know of many larger orgs doing Kanban or Scrum, so I disagree that it doesn’t work on lg teams. DSDM Atern has much to offer, though.

    • Stephen Hill Says:

      Lisa,

      Thank you for commenting and I am glad to hear of your experience. So were the Scrum teams large too in that organisation? It was not so much that Scrum does not work in large teams but it seemed to be harder – I suppose in reality it’s just that the challenges are different – especially when you’re dealing with teams distributed across cultures.

      Many thanks once again for your comment.

      Stephen

  2. Lisa Crispin Says:

    Generally the Scrum teams were 10 ppl or fewer. When they got bigger than that, trouble followed. IME, NOTHING works well in large teams.

    • Stephen Hill Says:

      Thanks Lisa. That is helpful because that was one of the points that was being made – once you start getting more than about 8 – 10 people in the Scrum team it becomes very difficult to manage.

      Perhaps I was unclear in my original post – we were not saying that Scrum/Kanban would not work well in a large organisation – or even in a large development department – what we were saying was that if the individual teams working on a project were too large then it becomes difficult – if not impossible to deal with.

      Thank you so much for your input Lisa that’s clarified things for me too.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s


%d bloggers like this: