I was having a discussion with SimonK over on Software Testing Clubs forum in a thread regarding education in testing & where you spend your buck in doing it.
Continue reading “RST – Would Michael or James attend their course if they weren’t running it?”
So, I’ve been flexing my mindmap skills using Xmind to try & map my learning in order to complement my blog posts.
My driving goal at the beginning of this learning journey was to become a better tester. I said when I started this blog I would define what ‘better’ actually means.
Continue reading “As a Tester, what value do I provide to my Customers?”
The RST course uses mnemonics to remember the key points to testing using heuristics. This post is about my 1st attempt at mindmapping a Heuristic Test Strategy
Last week I attended the 3 day Rapid Software Testing (RST) course run by Michael Bolton & James Bach.
I’ve had a go at setting up a GitHub account & now I’ve committed some of my code from the worked examples in Head First Java.
Continue reading “I’ve committed some code to GitHub!”
So, at the beginning of my journey I wanted to achieve 2 primary goals :
- ISTQB Advanced Test Analyst Certification
- SCJP Certification
This post may come across as rambling, but its more of an avenue for me to dump the contents of my brain as I try & work things out.
As you may be aware, i’m on a journey to become a better Tester. I haven’t blogged recently as I’ve been busy at home & at work and this has really impacted my ability to study properly.
Continue reading “What is my testing ideology?”
Right – have finally finished reading “Refactor Your Wetware”. What a great read – very insightful & easy to follow.
Admittedly it has taken me far longer to complete it than expected, but hey – i’ve family time to enjoy!
Continue reading “Refactor Your Wetware – Comments & further exercises”
Notes on “Pragmatic Thinking & Learning” – Refactor Your Wetware by Andy Hunt.
Post includes results of Jungs personality tests amongst others.
Continue reading “Refactor Your Wetware – notes/further reading & personality test results”
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.
I’m setting myself a fair challenge for 2011 :
Continue reading “My Goals & Targets for 2011”
On my first post I stated that I want to be a better Tester, but at that time I only had a rough idea of what I wanted to achieve.
Continue reading “How Can I Be A Better Tester?”
So, our current Iteration Manager, John McFadyen, got us to try the Marshmallow Challenge in a team building session.
Continue reading “The Marshmallow Challenge”
>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.
>This post is for me to add topics for further research as I am reading Head First Design Patterns.
>This post is for me to add topics for further research as I am reading Agile Testing: A Practical Guide for Testers and Agile Teams.
Wizard of oz testing
>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.
Cognition in the wild – Hutchins 1995
Modeling – are there testing patterns?
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 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.
>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.