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.