The dark art of testing in agile

***I am now back at Software Education teaching and consulting around testing and agile . I’ve just recently rewritten our Agile Testing course (ICAgile accredited) and this is my blurb on the course before I teach it on the 7th October for the first time (see http://www.SoftEd.com). Also I haven’t written anything here in a long time and being prompted by something else I sent to Lee Hawkins, I thought I would post this here as well***

Testing is like the dark arts. It hides in the shadows of projects probing silently, mocked openly and looked down with disdain by those who think they know better. But do they?

Testing was seen like this even by testing consultancies as they espoused the rhetoric that testing is simplistic, mechanical and artifact driven. The implied idea was that ‘any one can do testing’ was prominent. Fortunately two communities began to challenged these ideas. The context driven community broke the fallacies of mechanical, simplistic testing to human based, skill based, thought provoking investigations of self, product and relationships. The second community was the agile community who helped challenge the ideas of heavyweight documentation and adherence to process to one of experimentation with short feedback loops. With this came a more technical approach to testing using tools to assist (though sometimes there is an overreliance on these tools).

Our agile testing course looks to combine these two communities together by building key skills around critical thinking, using heuristics to build solid testing models and focusing on quicker feedback and leaner documentation. In turn, building these key skills then help testers to be better equipped to understand the agile context. Testing in an agile context requires quick, critical, skilled thinking and combined with some technical understanding enables testers to answer this question – How do I add value to my team today?

Our agile testing course is very hands on and experiential and looks to increase testing skills that help you become better in your role and add value. Testing is no longer in the shadows – it is front and centre and is our mission to help you to become indispensable to your team.

The question for you though is – how much better do you want to be as a tester?

Advertisement

Can’t Beat Experience!

It has been awhile since I’ve written and its mainly because i have moved into the “academic” side of testing – delivering software testing courses for Software Education in New Zealand. As a result i have been busy travelling and delivering!

One of the main things that I’ve noticed during the course delivery is  the degree of separation between a junior test analyst and someone with more experience. At the end of the day, it appears to come down to how many more stories or experiences that someone who has been in the *game* longer has to draw on. This lead me to think about a quote from W.Edward Deming:-

“Experience by itself teaches nothing.” This statement emphasizes the need to interpret and apply information against a theory or framework of concepts that is the basis for knowledge about a system. It is considered as a contrast to the old statement, “Experience is the best teacher” (Dr. Deming disagreed with that). To Dr. Deming, knowledge is best taught by a master who explains the overall system through which experience is judged; experience, without understanding the underlying system, is just raw data that can be misinterpreted against a flawed theory of reality. Deming’s view of experience is related to Shewhart’s concept, “Data has no meaning apart from its context” (see Walter A. Shewhart, “Later Work”). – http://en.wikipedia.org/wiki/W._Edwards_Deming

From my perspective, the more “battles” one has been in, the more experiences to draw from (even if one has “only” been in one organisation) and to some extent, the approach of the test analyst (Agile, Automated, Exploratory, Scripted, UAT etc) may not been as relevant as it serves to broaden the range of ones knowledge.

When i first started testing, one of the theories that i held/learnt was that testing breaks software. When i was asked what i do, i would often respond “I test  software by breaking it”.

Over time, associating with different projects and talking to many people, i view testing as Archeology – we sift through the dust and dirt using whatever approach is necessary to uncover the bugs – the software is already broken – we look for clues to find where these may hide!

Therefore, as testers, it is up to us to find our theory – whatever or wherever that may be. Seek to learn, broaden your skills and then apply this theory when getting your hands *dirty* . This will help to broaden our experience and maybe, just maybe, our individual value as a tester!

BTW – I’m currently reading an Introduction to General Systems Thinking by Gerald M Weinberg – so I’m beginning to walk the talk!

Happy learning!

The Art of Championing Bugs – The Bug Advocacy Course

Well its been awhile since i’ve last had the opportunity to post and there are a couple things that i will comment on in due course. The first of these is the BBST (Blackbox Software Testing) course 200A – Bug Advocacy. This course is part of the Association of Software Testing’s course curriculum (http://www.associationforsoftwaretesting.org/drupal/courses/schedule).

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 8) ) 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!