Collaborating with thinking testers in India
23 December, 2009 at 10:35 am | In Collaboration, Exploratory Testing, Software Testing, teamwork, testing | 4 CommentsTags: Collaboration, Exploratory Testing, Software Testers, Thinkers, Weekend Testers
Something is happening to testing!
A number of forward thinking testers in India have gotten together and formed Weekend Testers . Already there have been a number blogs posted about what an innovative idea this is – and these blogs post referrals/conference talks are from industry leaders such as James Bach and Michael Bolton which is high praise indeed.
I’ve been communicating with Parimala Shankaraiah who is one of the founders of Weekend Testers on Exploratory Testing (she has even taken the time to post some great comments on the google group Software Testers New Zealand.) If Parimala is an example of the thinking and passion towards testing in the Weekend Testers community then the Indian testing discipline is in good hands!
It does seem to me that are great inquisitive testers coming through every single day and the world-wide web is one way to keep track of and collaborate with these powerful thinkers!
STANZ 2009 Wellington New Zealand
28 August, 2009 at 1:26 pm | In Exploratory Testing, Software Testing, teamwork, testing | 2 CommentsTags: Brian Bryson, James BAch, Julian Harty, Karen N Johnson, Lee Copeland, Softed, Software Education, STANZ
STANZ (Software Testing Australia New Zealand) is the premier Software Testing conference this side of the equator! The conference kick off in Wellington New Zealand with Lee Copeland , James Bach, Karen N Johnson, Julian Harty and Brian Bryson forming the international cast of speakers along with a host of talented local speakers.
Monday started with a keynote from Lee Copeland from which in outlined the innovations he sees coming. I found him warm, engaging and very humble.
James Bach was next and what impressed me the most was the way he *prowled* the side of the conference room before being introduced and then ran and jumped on stage! I was wondering a whole bunch of “what if’s” then! His talk Becoming a Software Testing Expert was vintage James Bach in which he discussed the plays of Euripides and other Greek tragedians and related them back to software testing. The point from my perspective is that testing is neither purely technical or engineering but that we can learn from all multple areas and disciplines (history, philosophy, pyschology etc). James also discussed his Huh-Really-So heuristic which he uses when someone makes a claim about something. Huh means i don’t understand, please explain what you mean. Really is what other approaches are there, what else could happen, what other tools could we use and So is to dismantle the argument or to determine whether or not the idea is worth pursuing (I hope i got this right!
)
Unfortunately i didn’t get to speak to either Lee or James one on one but i did manage to talk to Karen N Johnson and Julian Harty. Karen’s workshop on test pairing was very interesting but more so the discussion we had (myself, Karen and Sharon Robson) after. Karen also gave a wonderful keynote on story telling which i think as testers, is an area on which we can improved. We may test but how do we say what we see? How do we know who to talk to and how to talk to them?
The last highlight for me from a presentation point of view was Julian Harty’s presentation on security testing which i found extremely interesting. I came away from the talk with the ideas of :-
*Finding a mentor
*Use tools
*Threat modelling
*and continuous learning (including self study or self learning).
I managed to talk to Julian afterwards and what surprised me was that security testing is about 1% of what he does as a tester. However when he did do security testing, he taught himself/found ways to make himself knowledgeable and very effective.
STANZ was a blast! Great speakers, great conference and more importantly great people. I managed to catch up with a host of new/old friends and its was awesome to share STANZ with them!
The Power of Two
8 July, 2008 at 11:23 pm | In Exploratory Testing, teamwork | 3 CommentsTags: Creativity, Exploratory Testing, Music, Power of Two, Robots
I am currently watching and listening to colleagues perform Exploratory Testing simultaneously. Instead of one working the keyboard and the other gathering oracles and recording paths, they are testing the application at the same time on different PC’s.
WOW! What a synergy! There is a flood of ideas, debates, discussions, agreements and the beginnings of their conclusions on this particular application.
The idea that Exploratory Testing is a cheap approach to find quick, superficial bugs is completely untrue….I’ve just in the last 30 minutes seen the converse to that argument! I am watching a creative collaboration of minds – coverage obtained – yes (i know that application enough to understand the coverage of functionality) diverse – yes, depth – yes – Superficial – NO.
I have been involved in Exploratory Test sessions where the creative juices just absolutely flowed – to those that oppose Exploratory Testing with superfluous arguments like ‘its monkey testing with a million monkeys at the keyboard’ – miss the point (maybe its because they want to quantify creativity but can’t …somehow…fit the square peg…into the…round..hole).
The point to Exploratory Testing is that the mind is the key to testing for it is the mind that allows inspiration and ideas to be generated and therefore expressed onto the ‘canvas’. It’s not ‘touchy-feely’ and to suggest otherwise may also suggest that the spark of creativity is missing from that person.
Otherwise, how do you explain music? How do you explain that feeling of ‘being in the zone’? How do you explain the artist that adds the touches to their work of art guided by their inner feelings?
Testing may be part of computer science but that doesn’t mean we need to conform to the discipline like robots. Testing doubles its effectiveness when its couple with intelligent thought processes.
I’ve just seen it!
CAST 2008
4 July, 2008 at 3:07 am | In Exploratory Testing, Software Testing, testing | Leave a CommentTags: AST, CAST 2008, Software Testing Conference
The Art of Championing Bugs – The Bug Advocacy Course
30 June, 2008 at 12:08 am | In Exploratory Testing, Software Testing, teamwork, testing | Leave a CommentTags: AST, BBST, Bug Advocacy, Exploratory Testing, Software Testing Courses
There are a number of positives aspects to the method of delivery and to the content contained within the course. First of all, you (as a student) are connected with software testers around the world (i have ‘met’ testers from Australia, India, New Zealand, Sweden and of course the United States) and learning starts straight away. This is because my testing context in New Zealand may differ from someone in India and will differ from other’s in the US. This is valuable because you are now connected to some real thought leaders and people who have different experiences ground in practicality.
Second is the quality of the instructors – Professor Cem Kaner (a leader in the testing world) and Scott Barber (a guru in the Performance testing sphere) coupled with other quality instructors such as Doug Hoffman, Pat McGee et al (refer to the Association for Software Testing website for the course instructors and then google their names for context). The instructors have *been around* (excuse the term
) and are willingly to share their knowledge and understanding freely. They critique with validlity meaning that what they have to say has substance and credence (i would cite the many examples from the course but that may detract from future opportunites of growth for the next crop of course participants) and allows the student to actually learn.
I can’t do that from a multi choice tickbox with no feedback given.
Thirdly, the questions in the exams/quizzes are designed to be read throughly and applied to the context at hand. I struggled with this. I could say that because i haven’t been to University and received a degree in anything (other than life!) my exam taking skills are outdated …. but that didn’t matter. See, you don’t need to have a degree to be successful in this course – just listening eyes, observant ears (yes that’s exactly what i mean) and a thinking mind. I struggled because i’m a jump in and do person – stepping back and thinking things through come second…
While i didn’t overcome this tendancy i did make progress and we as students got some great instructor led/peer feedback so learning was maximised through collaboration and guidance.
And lastly, working together as teammates in some course exercises (and this may be dependent on the course content) allowed us to utilise other testers thoughts, points of view and experiences together with our own ideas to deliver a stronger, better framed answer to some of the questions we were given.
Learning was therefore continual, learning was shared and learning was amplified. The AST courses are some of the best courses i had ever been on and i highly recommend them (…and they are free!)
Part of my email to Cem Kaner and Scott Barber capture my thoughts thus…
“…I have learnt alot from this course and i feel that i’ve gone better this time around compared to Foundations. Cem, the recent discussion on grading and call of questioning was like a big light bulb going off in my head when i read it….being someone that has not attended University, these ideas were ‘foreign’ to me but refreshingly interesting (i think my mind has ‘expanded’ during these two courses).
Scott, your insights and answers were ones that i learnt alot from and was drawn to (as well as Jeff’s, Dee’s and Anne’s) – you were like a stealth instructor/student…i’m sure that if you were my PM, i would flourish under your guidance! The discussion of Question 5 was gold!
Bug Advocacy and Foundations – I have learnt more, made more mistakes, kicked myself, got mad at the questions but came away with a feeling of actually learning something and achieving it. I compare this to a certain certification that is now prevelant in the marketplace (well in this marketplace). I sat the course and pass the multi choice questioned exam very, very well….but i don’t remember alot of it (except the V-model which is now ingrained in my head despite the fact that i don’t know if i’ve ever worked in a V-model environment) and I’m not sure if i learnt much.
That certificate for me is, at this stage, my commercial ticket (in this marketplace) but the BBST courses are, for me, where the real growth and learning have come.
Thank you both, thank you Doug and Pat for your time and also all the participants on the bug advocacy course!
Testing the Mindset
17 December, 2007 at 8:28 pm | In Exploratory Testing, Software Testing, agile, testing | Leave a CommentTags: Exploratory Testing, mindset, Questioning, Software Testing
I recently read an interesting blog entitled ‘How can i become a better Tester’ – http://thoughtsonqa.blogspot.com/2007/12/how-can-i-become-better-tester.html
This was my comment i left…
Hi John,
Enjoyed your article. I agree – its mindset (quality), its information gathering (read, read and more reading….asking questions…be involved)and finding that mentor who you can clicked with. Sometimes, when as a new tester, we can be blinded by the bias of that mentor so i would add – ‘When you are ‘ready’ question yourself, your understanding, your toolbox and then define yourself in the testing space’ – the trick is knowing when you are ready!
When i first started testing i was sure that testing was <b>ALL</b> about test scripts, test documents, writing documents and more documents because that’s how it was. Today, my thoughts and process have changed dramtically compared to when i first started testing but those earlier experiences shaped my thought processes today!
Great blog John!
Which got me thinking – how do our experiences shape our thought processes and ’steer’ us towards one method or another? For me embracing a more Exploratory approach was a logical evolution in the testing space. It allowed me to be creative yet structured at the sametime – it increased my toolbox – and i gain immense satisfaction from this approach to testing. Why? Because when i was involved in the more traditional form of testing, i got to the point that i wondered what is the point to what i am doing….in other words i began to question myself and re-examined the ‘tools’ i had. That’s when i became open to different methods to testing.
If i wasn’t as receptive or i wasn’t at that questioning stage, i doubt that Exploratory testing would’ve taken off for me as it has!
So sometimes, it comes down to timing as well as being open to new ideas!
Test Strategy vs. Test Plan
29 November, 2007 at 10:17 pm | In Exploratory Testing, Software Testing, testing | 3 CommentsTags: Exploratory Testing, Software Testing, Test Management, Test Plan, Test Strategy
Recently i have posted a couple of replys on the Microsoft Software Test forum – http://msdn2.microsoft.com/en-us/testing/default.aspx - click the link entitled Software Testing Discussion Forum.
There are a couple of posts on Test Strategy and Test Plans and what they are. Quite often the two terms are interchangeable and used indiscriminately. A Test Strategy (according to ISTQB) is the document that describes the methods of testing or the how. Whether this document is pitched at an enterprise level or a project level is open to discussion but essentially the Strategy is projecting ideas over a longer period of time.
The Oxford Dictionary defines Strategy as “… a plan designed to achieve a particular long-term aim” and as such looks at the ‘bigger’ picture.
A Test Plan describes the ‘How’ at a lower level. IEEE 829 (on which there is much debate on the revision currently being voted on) introduces the structure of should be incorporated in the plan. It is comparable to tactics which again according the Oxford Dictionary is “…an action or strategy planned to achieve a specific end.”
Whether you use either or both terms or documents is up to you. As testers we sometimes become involved in paper wars and become document heavy at the expense of efficiency and effectiveness. Whatever process you follow the key for any test document is effective communication.
Bj Rollison – a Test Architect at Microsoft (http://blogs.msdn.com/imtesty/about.aspx) sums up what happens if we stop thinking about how and what we use these documents for…”The only testers who stop thinking critically about tools and the application of tools we can use in the appropriate context are testers who have a limited understanding of the overall responsibility of testing, and know even less about the tools they are tyring to use.”
Great quote – i totally agree. Whether its a Test Strategy or Test Plan, it is a tool whose purpose is to serve us and guide us in our testing activities.
If you are responsible for producing said documents, please be critcial in your thinking and look at the best way to communicate to all those involved in your sphere!
The 2006 NBA season the Phoenix Suns Strategy vs. the LA Lakers was “…Phoenix’s strategy against the Lakers this season has been to contain everyone besides Kobe Bryant, and it’s worked. Bryant had 39 points in the first meeting and 37 in the second, but no other Lakers player scored more than 17 in the two games and the Suns simply outscored Los Angeles, averaging 114 points.” – Yahoo Sports.
There is your Strategy, the plan is how each Sun player played defense against their man.
Strategy without tactics is the slowest route to victory. Tactics without strategy is the noise before defeat.- Sun Tzu
Blog at WordPress.com. | Theme: Pool by Borja Fernandez.
Entries and comments feeds.



