Being my first conference for just over 4 years, I was unsure of what to expect. Luckily, the journey was not eventful in anyway and finding the venue was relatively easy. It was great to join other professionals who were working in environments with varied amounts of agile methods being used. I felt that all the sessions I attended over the two days provided me with great information that I felt I could take back to work and suggest as ways in which we could adapt our current methods.
Testing at Google – Dr James A Whittaker
The first session was the Keynote Speech from Dr James Whittaker who is a Director of Testing at Google – ‘How Google Test Software’, it was very insightful to see how Google manage to test their software when they perform several releases a day for many of their products and this was made even more suprising when he mentioned the dev heavy ratio when comparing the amount of developers to testers. A phrase from his speech that sticks in my head was ‘Testing is like heath care, it’s an on going process’. It was a very useful talk and if I could take anything away from this talk, it was that with the amount of testers they have compared to developers, it is important to put the ball back into the court of the developers to make sure they have tested their own code to an acceptable standard before the testing team see it. Also with the methods they have in place to ensure that any bugs raised are fixed as early as possible, certainly make it seem like a very productive environment.
The Specification Game – Gojko Adzic & David de Florinier
After a half hour break and talking to some other guys about their processes, this next session was one of the most eye-opening and intriguing of the conference. The workshop that Gojko and David presented to us was that we had to produce the first iteration of a blackjack game, we were given a description of the game from which we had to pull the features we felt would be enough to produce an end-to-end working game for the first iteration. This is where we made our first mistake, Gojko had mentioned he was the customer and not once did I as the Product Owner for my team feel that I needed to check something or negotiate requirements with him. I picked the requirements I felt fit for the team and the team started developing the prototype while the testers were pulled over for a few pointers with David, when they returned, we didn’t sync up as a team to make sure they understood exactly what the developers were developing but instead they ploughed into writing test scripts. The problem with not syncing up as a team earlier on, then hit us when we ran the test scripts and we failed the majority of them for simple reasons such as the wrong words on the UI buttons (Stick and Twist rather than Hit and Stand) and the cards being dealt two at a time for each user rather than one card alternatively.
We then recieved the User Acceptance tests from the customer (Gojko) and quickly found that we failed all of them. Gojko then mentioned that not one team had gone to him earlier to get the acceptance tests, meaning that none of us actually gave the customer what they needed.
All this in 90 minutes, it was a very interesting session that highlighted 3 major points to me:
- It’s important to interact with the customer to find out exactly their needs of the product and negotiate scope
- Make sure the team is reading from the same page for the entire length of the project and that testers are aware of exactly what the developers are coding
- Ask for the User Acceptance Tests as soon as possible, this way you can make sure your product covers the minimum of what the user wants.
A great session which was well led and left us all discussing it for the lunch break afterwards.
Creating Agile Environments – Rachel Davies and John McFayden
I was keen to attend this session as I was interested to see what would be defined as a good agile environment. The session was made up of two main group discussions where firstly people discussed their experience of workspaces from hell, followed by workspaces from heaven. The additional fun factor here was that we were asked in teams to create our worst and best environments using playdough and other creative materials.
There were some shocking stories for some of the worst environments but most had a common theme, such as division of teams with people working together but not being able to communicate very well with each other, lack of communication with management, noisy or silent environments, lack of motivation for employees and many others.
Obviously in a lot of cases, the good environments were an exact opposite – good communications, teams sitting in the same area so good collaboration, supportive management, incentives, a happy environment. A few additional features were things such as modern technology both in machines and in communication tools, break out areas, windows with great views and project workspace.
The one thing I took away from this session was that for a team to work well together, the environment in which the team is located in is paramount to their success.
Winning Big with Specification by Example – Gojko Adzic
Before I attended this conference, several of our QA team attending the Iqnite conference in London and all came back to the office raving about this session. Having attended Gojkos workshop earlier in the day, I was keen to attend this session too. The concept of Specification by Example was a new concept to me and listening to this presentation really opened my eyes to the idea of the collaboration between stakeholders, developers and testers to define high quality requirements that can be turned into a set of high quality user stories followed by a set of tests which would be the user acceptance tests, the difference being that the team will understand the need for these acceptance tests a lot more than if they were just given to the team by the users.
These then also turned into the living documentation which in itself is a very interesting concept, a document that will be continually up to date and will mean any change made to the software can be facilitated very easily. I can really see the benefits of using this approach and will be looking for Gojko’s new book when it is released.
The lesson shining through here again was to have the tests written before coding is started, then the team will know that the product is fit for purpose when it is complete.
Cyberdojo – Jon Jagger
I was looking forward to this session before the conference and when it came to the conference itself, I was so impressed with all the previous that I didn’t have time to even think about this before I turned up to it. The concept of this was reasonably simple, it was a pair programming exercise where every 5 minutes, whoever was ‘driving’ would move to another machine and become the ‘passenger’. The way it was set up was as follows:
- Every machine had a unique animal avatar
- The first users on each machine would choose a language (C, C++, Java, PHP, C#,Perl,Python)
- They would also choose an exercise (ranging from generating prime numbers to anagrams)
When the users have selected these, they are then given a test script that fails for this exercise and dummy source files. As soon as you press the play button for the first time, the current program will compile and the tests will be run, depending on the state of the program, a colour will be displayed (green if it works and passes, yellow if it doesnt compile and red if it fails tests). Once everyone had moved around a few times, Jon added an extra rule that every time he rang a bell, all teams had to get to green. This gave an interesting dimension to the coding as some people would try to get their code working as effectively as they can in 5 minutes and then when the bell would ring they would be in a state where it either wouldn’t compile or they failed the tests. Others would do minimal amount of coding just so it continued to pass. It was a very interesting exercise that showed how important it is to control your code and the lesson I learnt here which I found very useful was that if you have completed your exercise at the requred time, rather than moving onto the next exercise, in a collaborative environment, it would be more useful to help others get to the same stage. Certainly a valuable lesson to take back to an agile team working in short sprints.
That was the end of the formal sessions but there was the evening event sponsored by the kind people at Redgate Software. I sat and discussed agile process with some very knowledgable people and learnt quite a bit about how other companies are adopting the agile processes. The most important thing I learnt from this time was that not to expect agile to work perfectly straight away. It will take time to get it right.
For what happened on the second day of the conference, there will be another entry soon.
Simon Prior 