After spending almost the entire year looking forward to it, I finally attended not only my first conference but my first CAST! The first day consisted of four full-day tutorials. Attendees were given the choice to attend any one of four full-day tutorials, they all looked intriguing but the one I choose to register for was End to End agile Testing with Paul Holland – and I was not disappointed.  What I learned and got out of the tutorial is actually one of my highlights for this year’s CAST.  Now I’ve spoken to Paul before via twitter and email, and he had also informed me early on about a public RST class (completing RST is one of my goals) he was teaching in Ottawa earlier this year, which unfortunately I was not able to attend due to timing issues – but this is the first time I’ve actually met Paul in person.  I will say this – Paul is an awesome teacher!  Aside from the tutorial I also got a chance to speak with him about some of my goals as a tester, how I can go about to accomplish them and he was able to give me some great insights.  I also got a chance to joke around with him for a bit – he is one funny individual!

Getting back to the tutorial – there’s one term that I feel has been engraved into my head, and that is PCO which stands for Product Coverage Outline.  I work on many different projects at my company, and usually asked to create & document a test strategy.  I have to create a test strategy that will be looked at by many different people (Product Owners, Project Managers, Developers, Architects, Systems Development Manager, Test Managers) with different technical knowledge & understanding, and different understanding of what software testing is or what I (the tester) actually do.  This can be even more amplified at a big company such as where I work right now where the application might interact with many other components and due to the number of levels and teams who have worked on the different components, many people have a different understanding of where and what the risks are.  I don’t create 50 page documents explaining my test strategy (despite some in the company who may believe that is what needs to be written), instead I have been creating test strategies consisting of a short document divided into a few sections, and a diagram depicting the application and related components (which went over well) – but the challenge still remained, how can I do this better in a way different people with different understanding will better comprehend?

The PCO

I got my answer and learned how during the tutorial – Product Coverage Outline.  We were split into teams based on where we were sitting (I have more on this below). Paul explained to us (and then had us practice it in our teams during the tutorial) how a PCO can be created and used (in different ways) for different purposes – to explain testing, to guide testing, to divide testing amongst the team (if that’s your aim), to show test progress (along with visual tracking using a whiteboard), to show test coverage and how it can also be used as part of the final test report.  We started off creating our own PCO, although during this stage my team and many other had starting finding bugs and logging them into the shared bug list. This PCO would then help us focus our testing based on risks and features. Before lunch each team presented and explained their PCO in a timespan for 3 minutes.

Testing the application and filing bugs

After lunch Paul explained Test Reports and what was expected from them, and then we started (well officially started) to test the application and log bugs.  We had about 2.5 hours (which went extremely quick) to discuss the test strategy with our respective teams, test, file bugs and create our test report which each team would then present. One challenge here was to do all these things in the time allocated – a testing challenge we all face in the real world.  Another was to find and file bugs, in that we had to ensure another team had not already filed the bug, this eliminated duplicate entries and furthermore the team that filed the bug first would receive credit for it.

 Presenting the Test Report

The final part of the tutorial was each team presenting their Test Reports.  My team and I were nowhere near ready as I had just finished up writing the Test Report when we were called on as the first team to present. I presented the 5 minute test report for my team.  Now this was nowhere near my best presentation – not even close, but I know I can do better because I have done better.  More importantly though is that Paul gave me some insight on how I can do better in area’s I had not been aware of – how I can better deliver my test report verbally explaining the test report based on a story about the status of the product, how we tested it and how good that testing was.

Tough lesson learned

This being my first conference and my first tutorial of this type, I did learn a tough lesson on this first day.  It has nothing to do with Paul or the content or the tutorial itself.  I will say this to anybody new to a conference and tutorial of this type – try to sit in the front with people who seem excited and passionate about being there (which can be difficult to do as you’ve never seen or met these people before).  I feel I made a mistake by for some reason sitting towards the back – now this is solely my opinion based on my experience, doesn’t necessary hold true for everybody or every time.  There are different types of people who come to conferences for different reasons and different levels of passion for testing, different goals or types of things they want to get out of something like this – which is fine I guess.  But for me I want these types of sessions to require me to really think, learn how to think, I like them to challenge my thinking and my way of doing things. In team exercises I like working with passionate people with different ideas who want to share, learn, and push their thinking just like me – unfortunately this wasn’t the case (teammates not on the same page goal-wise) for me during the tutorial.  Despite this tough lesson, I was still able to learn, apply what I learned, got feedback on how to improve it and looking forward to using it on my projects at work and getting better at it by practicing it.

For the remainder of the conference, every session and talk I attended, I sat in the one of the first three rows – learned a ton, asked the speaker questions and had a blast! 🙂