Posted on

My Goals & Targets for 2011 - Update

Ok - so maybe achieving all 3 goals by the end of May might be a bit tricky.

Consequently, I’m going to strive to complete for these 3 goals by the end of the year. This will allow me to get into each goal in more depth & hopefully provide a richer experience.

I’m still going to train for the ISTQB advanced & SCJP qualifications in parallel & I aim to have a good, solid understanding by the time my current contract comes to an end.

This should enable me to provide better, more informed responses to any interviews I might have.

Posted on

>Arlo Belshee - notes/further reading

>At my current client, we were fortunate enough to have Kevin Rutherford as an Agile Coach.


In talking to him about Agile, he suggested I have a look at thoughts & musings of Arlo Belshee as anything he talks about is largely adopted by the Agile community.


This post is for a dumping any interesting links I find whilst researching Arlo Belshee.


Interesting conversation on the Agile Toolkit podcast re pair programming :



And the associated paper he wrote on the pair programming :



The Progammers practice pair programming here, but the Test team were seen as a separate entity. Although we were called in for huddles as the story progressed, we still felt a bit like outsiders.
This has now changed and we pair/triple with the Programmers a lot more & have more input into planning the the test suite throughout the whole web stack, not just at the Twist/User Journey level.


The team is comparatively large for an Agile team - 16 Programmers to 6 Testers. Arlo talks about an optimum pair swap time for a team of 6 to be around 90mins, with the first Programmer to roll on to the story being the first Programmer to roll off. This way, as the Programmers roll on to a story, they’re fresh (beginners mind) & then they get to move onto another story after 180mins.


Programmers here work slightly differently - (probably due to the size?) Programmers don’t tend to swap as often as 90mins. Also, A Programmer will tend to own a story through to completion, as opposed to rolling off after 180mins. This allows to be an ‘expert’ in this story.


I’m not sure which is better. I can see the benefits of both, but I can also see the downsides. 
We’ve had some stories which have caused the Programmers a lot of grief, and the original estimate of complexity has gone out of the window. Would this situation benefit from have a fresh programmer every 90 mins, and for the pair to be completely changed every 180mins? Or does it require 1 Programmer to remain on the story to steer it through?


The Naked Planning idea is interesting. We have implemented a similar solution here, and it first mentioned by Kevin (practising what he preaches!). 
We have the priority column on the left, which has the metaphor of the dinner plate stacker found on ferries & the like - You take a card from the top & all the other cards move up the priority pile. New stories can be added underneath.
We slightly differ form Arlos idea of naked planning, in that most of the prioritising has already been carried out on the epic wall - Stories are promoted from there, and although the Product Owners can change the priority once the story is on the wall, We generally work through the stories in the priority pile.
Also we don’t have an expedited section - high priority stories / defects move directly to the top of the priority pile.   

Posted on

>Lessons Learned In Software Testing - notes/further reading

>I’ve noticed that as I’m reading, I’m writing buzzwords on scraps of paper which when I go to read them have no context - makes it hard to follow up on!


This post is for me to add topics for further research as I am reading Lessons learned in software testing.


Topics
Epistemology
Cognitive psychology
Cognition in the wild - Hutchins 1995
Modeling - are there testing patterns?
Abductive inference


Epistemology
My understanding of Epistemology is how do we now what we know is true & correct. This might not be the best definition, in the context of testing, it enables us to ask pertinent questions in order to get an adequate answer.


testingnook.blogspot.com appears to have taken the same route as me, in that after reading the Lessons Learned book they have carried out some further research on this topic.
The blog ends up with a list of skills of epistemology which can be applied to testing and form a great plenary to the blog - Really handy for helping you talk about what you do (to interested parties only!)

    • Ability to ask questions

 

  • Ability to observe
  • Ability to describe
  • Ability to think critically about what you know
  • Ability to recognize and manage bias
  • Ability to keep thinking despite already knowing.
  • Ability to analyze someone else’s thinking.
  • Ability to form and test conjectures.

 

 

Posted on

>Gathering Resources

>After asking around the team, I have a nice selection of resources to dip into. I’m thinking i’ll be adding posts about the resources as they each spawn further reading.


Java related books :

  • “Head First Java” Kathy Sierra and Bert Bates
  • “Head First Design Patterns” Elisabeth Freeman, Eric Freeman, Bert Bates, and Kathy Sierra
  • “

    Java For Dummies

    ” Barry A. Burd

  • “SCJP Sun Certified Programmer for Java 6 Study Guide” Kathy Sierra



Testing related books : 


Agile related books : 

  • “The Art of Agile Development” James Shore

Learning related books :
  • “Pragmatic Thinking and Learning: Refactor Your Wetware (Pragmatic Programmers)” Andy Hunt

As well as books, there is also the mighty WWW. 

Java related sites : 

Testing related sites : 

Agile Development related sites (inc. podcasts):

This list is obviously going to grow as my reading gets more and more involved.