KWST#3 is coming – 5/6 July 2013!

2 Comments

It’s that time of yeKiwi Workshop on Software Testingar again – Kiwi Workshop on Software Testing (KWST) #3  will  again grace Wellington, New Zealand.

This years theme is …

“Lighting the way; Educating others and ourselves about software testing –  (raising a new generation of thinking creative testers)”

 

And this promises to be an excellent peer conference!  We have invited test leaders throughout New Zealand and from Australia including Anne Marie Charrett.

So more details to follow but much thanks go to …

  • The Association for Software Testing
  • Software Education
  • The KWST crew (Aaron, David, Katrina, Oliver and Rich)

Star West Software Testing Conference 2012

1 Comment

During the first week of October 2012, I will be presenting at Star West at The Disneyland hotel, Anaheim, California on Using Agile techniques to Manage Testing – Even on non-agile projects (http://www.sqe.com/StarWest/Concurrent/Default.aspx?Date=10/4/2012#T19 ).

Its going to be an exciting testing conference and I’m looking forward to meeting fellow testers at such a prestigious event. Already as I scan the speaker list I see testers such as Michael Bolton, Dawn Haynes, Rob Sabourin and so forth who are leaders in our craft and I’m looking forward to meeting them (again) and talking – what else? Testing!

No doubt there are many more here that are not on the speakers list and I’m looking forward to meeting you too. 🙂

See you there!

Learning from the frustration of test case debates

9 Comments

What is a test case?

The reason I ask is that recently I have been following (and commenting) on a question in the LinkedIn group Software Testing & Quality Assurance  – ” hi guys do u think that creating Test Cases is must? According to me, creating Test Cases is just a waste of time rather we should utilize the time in doing testing. what is your opinion? ”

At first glance I thought it would relatively *easy* and pick apart this question and the ensuing replies. However, after reading through the comments, I immediately felt frustrated. Why?

Upon reflection, I noticed a couple of things.

First, it helps to view the comments from the start. I had missed the fact that there were something like 100 comments before I jumped in. Realising this would’ve help save the frustration because Griffin Jones said it from comment one

@Pradeep – I forecast that this conversation will become confusing because:

a. people will be using unstated assumptions about what is a “Test Case”. Some people’s working definition will exclude other people’s working definition of the term. This “shallow agreement” problem will not become obvious until comment # 78.

And Griffin’s prophecy came to pass.

Which led to *the* problem:

Comments were roughly divided between *a test case is a set of inputs with expected results* group that talked of the test case as a tangible artifact. The second group tended towards seeing the test case as an instance of a test idea and generally speaking this second group were the ones that seem to constantly challenge the assertions of the first group.

And then it dawned on me.

The second group appeared to be aligned with the context driven school of testing and as such realise that were *a lot* of dangerous assertions in the comments made by the first group. For example:

Testcases ensures the tester does not over do his testing and makes sure when and at what stage of his testing he could exit and say that the testing is complete.

If we were to look at the above statement a number of questions spring to mind. First of all, how does a test case ensure that a tester does not over do his testing? What does it mean to overdo testing and if testing is *overdone* what is it compared to be deemed overdone?  If the commenter means ignoring the risk of testing something else or finding information outside of the scope of the test case then overdone has potentially risky consequences for him or her (as they have now have jumped outside of the test case box and may find interesting information…tsk, tsk as now they may not meet their execution test case complete target because now they are THINKING about what they are doing as opposed to just doing *something*.). If the tester became engaged then they would be aware of their coverage and risk model and seek after information that may challenge that model. Notice that the engaged tester does not complete a test just because they have ticked off all of the steps to execute;   otherwise, we end up blindly following a script and we’re checking not testing. This highlights an issue of the commenter viewing a test case as a tangible item when in reality it is an abstraction. It is an idea (or collection of ideas) and *passing* a test case does not guarantee that the idea is finished with. Rather a good tester will most likely extend that idea into many ideas.

Of course we could critically pull apart the rest of the comment and show the fallacy in the statement (such as how does finishing your test cases mean that your testing is complete? It could in some circumstances but I suspect that the commenter meant completing testing – full stop). There are a number of comments like this and they all follow the same theme. We write test cases so that we can cover the requirements and we have repeatable tests so that we can teach others and because the v-model aligns with Saturn and Mercury in the house of Leo – so it must be good!

But I digress…

AND this was  frustrating for me. It seemed that no matter now many times (and in different ways), the second group (lets called them Team CDT) highlighted flaws in the first groups arguments (lets called them Team Factory) then another equally inane comment appears and it made me realise that (to paraphrase James Bach)…

If you are frustrated then it means that something is frustrating!

Realising this then made the rest of the journey…well…more fun.! I realised that I could not wilfully change anyone’s mind except my own. I realised that, regardless of what I shared, others are free to disagree. I realised that no matter how many times I pointed out a fallacy in someone’s argument, it’s up to them if they take heed or not.

AND I realised that I could actually benefit from this and not let the emotion of frustration take hold.

How you say?

By looking for like minded individuals and engaging with them knowing that I’m mostly likely to get a meaningful discussion coming back. By practising pulling apart a comment and challenging someone’s assertions. By applying James Bach’s Huh?Really?So? heuristic and what was initially a frustration quickly became a learning experience.

While it’s galling to see many testers fall into Team Factory, I am hearted to see a number of testers critical of the *status quo* and challenge them (as demonstrated by their replies to team Factory comments). It is through challenging that we grow the craft into something that is stronger, assertive and more critical overall.

Career advice from New Zealand

2 Comments

Two years ago I created Software Testers New Zealand (google group). It has taken a little while but there have been some fantastic discussions especially in recent months.

Yesterday a member of the group *ranted* (his words) about an *approved* job add that was posted.

It has spawned an interesting discussion on what it takes for a tester to get a foot in the door and has morphed into learning about the industry/certification.

I consider the discussions pure gold – check it out, comment if you wish – i think it would be helpful to hear about other testers thoughts/ideas/experiences from around the world!

Entaggle – a website built on reputation

Leave a comment

Elizabeth Henderickson has create a new website called Entaggle which allows users to tag another user with a reputation tag. I think this is a brilliant idea and in our testing community this may hold more *weight* than a traditional cv.

Check it out!

Mr T and the Art of Box Painting

Leave a comment

It’s funny how one can take different media and apply them to what you want to…in this case software testing. I recently watched a World of Warcraft ad with Mr T from the A-Team days (http://www.youtube.com/watch?v=bqJE5TH5jhc )

Mr T created a new character, a Night Elf Mohawk – the ‘directors’ of the ad said that he couldn’t do that. In Mr T’s own way, he boldly announced that he was ‘handy with computers’ and ‘hacked his own Night Elf Mohawk.’

Like most things software, the developer is looking for a solution to a problem. A tester (in this analogy, Mr T) is looking for a problem in the solution or in other words looking outside of the box.

Being *bound* by specifications and scripts is what I mean by box. Now I don’t mean that i am anti specification and anti scripts (they may be valuable resources, oracles if you will, in the right context) but reliance on these solely leads to the box being painted (http://viscog.beckman.illinois.edu/flashmovie/20.php for an example of *box painting* – INSTRUCTIONS FOR THE CLIP: Count the number of passes made by the team in white. Record the number of passes and continue reading….(at the end of this post is the next set of instructions but don’t go there yet!)).

In the ad, Mr T is looking outside of the box. He is thinking outside of the bounds of the requirements.

Why?

If the software delivers as per the requirements, has it not passed?

No.

Outside of the *bounds* are the areas testers love to tread because we then are looking at potential bugs. When we find bugs and report them, they are resolved in some way. As they are resolved, then potentially the quality of the product is increased.

I once worked on an application whereby the requirement of an input field (stated in the specification) said “truncate 32 chars”.

This was a java based browser hosted financial application.

A colleague and I started testing. We typed into the input field and as much as we tried, we couldn’t type past 32 chars.

So we created a very large string (1,000’s +) and copied and pasted into the same input field.

BANG!

CRASH!

DEAD!

The application fell over completely!

The developer had followed the spec and had coded for it but he did not cater for a copy and paste (let alone a large string!)

It took the developers about an hour or two to resolve it.

In this case, we thought outside of the box – we dared to push beyond the realms of the spec. We tested for something that wasn’t considered and this is an important consideration for testers – to question and challenge what is in front of us. Challenge what we have been given and the value that we will add as testers will be made manifest (i.e. bugs!!)

Happy hunting!

**INSTRUCTIONS from the video clip continued – what did you notice? Was there anything interesting going on? If haven’t found anything, review the clip and defocus your vision or in other words, look outside of the box.

Software test leadership is alive in New Zealand!

5 Comments

New Zealand flagI’ve been lamenting the state of testing in New Zealand or more specifically test leadership. Now, I’m not talking about the number of test leads or managers – I’m talking about leaders in our community.

I felt there weren’t very many leaders with most testers here settling for a *just do my job* mentality.

Until last night.

Last night, Software Education held a customer evening by inviting customers to view Software Education’s new premises. I met some interesting people and had some great discussions and then it dawned on me – I’ve met some strong testing community leaders already but I had thought of them individually not collectively and I’ve discovered that there are more test leaders than I’ve realised. Now, when I’m talking about community leadership, I’m talking about context driven, lets discuss and debate and better our craft type of leaders (and this is irrespective of whether these leaders are part of the ISTQB certification program or what have you).

And so what I would like to do is highlight these leaders as testers to watch because in their own way, they are helping the craft grow in New Zealand. 

Farid Vaswani – Test manager at Auckland University, associate editor for Software Test Professional and implementor of SBTM at Auckland University.

Oliver Erlewein – Performance tester/test Manager at Datacom Wellington, context driven space, will debate or challenge the status quo. Weekend Testers Australia New Zealand facilitator.

Trevor Cuttris – Team Leader IAG – involved in mentoring and upskilling testers in many different ways (at work SIGiSTs groups etc). We had a good discussion around ET and SBTM.

Rob O’Connell – Assurity Consulting – very similar to Trevor. Lots of passion. Not willingly to accept the status quo if it provides no value. Mentoring, upskilling, uplifting and highlight the craft.

Katrina McNicholl – AMI Insurance – Christchurch based – passionate about the craft, about learning and about sharing ideas and thoughts on testing at the local level.

Tessa Benzie – AMI Insurance – Christchurch based – the same as Katrina – involved wanting to better the testing craft at a local level.

John Lockhart – Webtest Auckland – context driven test automation – *guru* with fitness – first met Jon through the AST BBST series of courses.

Matt Mansell – DIA – is involved in many different areas that result in testing being given a higher profile particularly in the Wellington market.

Honorable mention: Aaron Hodder, Shawn Hill (what an awesome presentation at STANZ 2010!), Christo Bence, Andrew Black, Sophia Hobman, Richard Robinson, Jonathon Wright.

Is this an exhaustive list? No.

Are these the only community leaders in New Zealand? No – but these are testers that I’m tagging that will have an impact on the testing community – whether it’s locally or nationally and will help improve the state of our craft here in New Zealand.

Have I missed some testing leaders? Most likely – BUT i hope you come forward, I hope you stand up and I hope you begin to share your passion for testing with us all (conferences, SIGiST groups, STANZ, blogs, twitter – the list is endless).

To those whom I’ve *outed* – it’s time to highlight the incredible talent we have here in testing – and its time to share the passion that you have with everyone and become …leaders.

Older Entries