Author Archives: Sharon Robson

About Sharon Robson

Practice Lead with Software Education. Founding Board Member ANZTB. Former Chairperson Marketing Working Group for ISTQB. Certified Tester Advanced Level - Full (Test Analyst, Technical Test Analyst, Test Manager).

STANZ Wellington and Melbourne

Wow –how cool was it to catch up with everyone at STANZ in Wellington. The Amora hotel was great sized for the conference and it was fabulous to see so many familiar faces. It was also great to have such a line up of presenters. Then after Wellington we went to Melbourne. It’s fascinating how two different towns with almost the same conference presenters can create such a different event. I love the fact that STANZ is in two places to give this effect. Obviously the audience is the key factor! Different audiences, different questions, different learnings, different approaches – so many differences, but still some fabulous outcomes.
I know that Jonathan Kohl was awesome in his opening session and Karen Johnston had us all riveted with her view on the virtual teams (more on these later). It seems the whole conference was about challenging the way you think and what you currently do. We also had a really strong focus on providing value for the business. This was backed up by Mark in Melbourne talking about testing from the point of view of a CEO. I loved the fact that all of the presenters had a different point of view for how and where we can look at our work, our work place, our approaches and our mindsets. I really liked the way the audience interacted and challenged, and it was really funny to sit in Gorenka’s session on Testing Games and see how many people became hooked on SET as a way of stretching their minds (once again – more on that later). Jan Japp’s discussions on TMMi and thinking and challenging your approaches was also great! I enjoyed the checklists and new approaches that I took away from the conference, and I spoke with so many people who mentioned that they had things that they wanted to do as soon as they got back to work – now that is what I call a valuable conference!

Leave a comment

Posted by on September 23, 2011 in STANZ 2011


Scrum Thoughts

I’ve just spent the afternoon reading the updated Scrum Guide from Ken Schwaber and Jeff Sutherland.

There are some great points in it – some of which I have recorded here because in my experiences working with the various agile teams that I have met over the years it is good to have a reference point for some of the key things that I have noticed not working correctly, but are being done in the name of Scrum.

“Scrum recognizes no titles for Development Team members other than Developer. Regardless of the work being performed by the person, there are no exceptions to this rule; “

I like this – it is not the “developer” definition in the sense of a developer being someone who writes code, but a developer is someone who contributes to the development of the product. This has been used and maybe even abused in the past where teams consist of only programmers, rather than a cross skilled group of “developers”. We need to think about the skills needed in the team and the proportion of those skills, and what work is required to be done to complete the task as opposed to the titles of the team members.

“each event in Scrum is an opportunity to inspect and adapt something. These events are specifically designed to enable critical transparency and inspection. Failure to include any of these events results in reduced transparency and is a lost opportunity to insect and adapt.”

This one is a good one too – how many times to team decide to not do something because they don’t see the value and then head off down the wrong path. I was recently speaking to a group who does not do Showcases at the end of an iteration – why not? The extended team did not want to attend….what a missed opportunity and a “failure” according to the Scrum guide.

“Each Sprint may be considered a project with no more than a one-month horizon. Like projects, Sprints are used to accomplish something. Each Sprint has a definition of what is to be built, a design and flexible plan that will guide building it, the work, and the resultant product.”

This will challenge a lot of people’s thinking, particularly those teams who are tending to do incremental delivery of a predefined product, not looking at each interation as a separate activity that needs to be planned and actioned appropriately. I said something similar to this in a training session lately and almost everyone in the class gasped….until I explained the concept, then they all said “yup – that makes sense” (phew!).

“The Daily Scrum meeting is a 15-minute time-boxed event for the Development Team to synchronize activities and create a plan for the next 24 hours.”

How often do we hear of Stand-Ups being extended for the longer period. Meeting still need to happen but the standup or Daily Scrum is so important for this synchronisation and planning actions – teams that are dysfunctional and don’t understand the need for the stand-up or do them poorly often don’t have this coordinated view of what needs to be done by the whole team!

Leave a comment

Posted by on August 5, 2011 in Agile


Tags: ,

Advanced Agile?

I was at an Agile Academy Meetup last night and the topic was “The Agile Journey and beyond”. It was great to hear about the agile concepts and practices being applied, in real world scenarios – small and large organisations. But it was equally great to hear about how these organisations were using agile in the way I think it is meant to be used – not as a rigid framework, but as a guideline for an approach. All three of the speakers made a comment like this (please note that I am paraphrasing here) ….”We tried XYZ and it worked for a while, then it stopped working so well, so we changed it”. I had to giggle when Adrian said they sit down at their standups….because they use a webcam and it is not viable to standup. Another speakers said “we tried the 3 questions at the standup, but it did not work, so now we “walk the wall””. I was really excited to see this extension of agile practices and acknowledgement that the practices that we see, read about and talk about so widely are totally malleable and able to be modified to suit each and every organisation. But there is a gotcha! All of the modifications came as a result of trying the “proper” way of implementing the practices, and then careful and comprehensive understanding of what about the practice did not work, and why, and then careful and incremental changes to the practice to make it work better. It was described best by one of the speakers as “an agile implementation of agile”.
So I was wondering:
1. is taking the agile practices and modifying them a good indication of agile maturity?

2. which practices are the riskiest to change and why?

3. how long should you try the “proper” way before considering change?

4. is modifying the practices a sign of agile maturity of advanced agile usage?

What are your thoughts?

published by Sharon Robson


Posted by on February 23, 2011 in Agile, Culture



Testing in Agile – seperate or integrated?

I’ve been thinking about how to organise testing within an iteration. The challenge is that activities within an iteration are particularly related to a specific story. However, there are aspects of testing that are larger than a single story (e.g. integration testing). There are testing activities that are related to more than a single iteration (e.g. system and regression testing). I’ve seen models mooted where there is a parallel test iteration. This concerns me as it seems to split out testing (again) and has the potential to remove the emphasis on testing from the development aspects of the product. The risk is that the testers are once again excluded from the intra-iteration activities and lose visibility of what is occurring and what knowledge is being transferred. Another model I have seen is a specific test iteration as part of the overall release plan for the product. But is this not just “waterfall” by another name? What approach do we take that allows us to truly integrate testing into the agile iteration?

My thoughts?

1. include the testers in all core team activities from story elicitation through to unit testing

2. ensure that test automation is considered up front and time is allocated to automating the testing

3. ensure that Integration, System and Acceptance tests are integrated as tasks within the iteration

However, does this mean that we slow down development or do less “new” work during the iteration.

What do you think?

Posted by Sharon Robson


Top 10 Exam Tips

As Knowledge Engineers who work with people who are aiming for certification we often find people asking how to best do exams. This is really interesting! As established professionals in a field, it can be years since people have done an exam, so sometimes the exam can seem daunting and scary. So, we put our heads together and came up with this list of our top 10 Exam Tips:

  1. PRACTICE – get your hands on as many papers or example questions as you can…practicing exams will help you know the variety of question styles, understand how to structure your timing within the exam, will allow you to relax into the exam more easily on the day and will exercise your knowledge. Try and do as many exams, under exam conditions (timing, closed book, quiet room) as you can.
  2. Read the entire paper first – so you know what is coming and you can see if one question helps you answer another question.  This can also be called “Touring” the paper first before answering the questions. This allows you to minimise surprises and also allows your mind to be thinking of other questions unconsciously while you are working on a specific question.
  3. Read the question carefully – make sure your REALLY know what the question is asking – paraphrase to make sure you understand, what is it saying (i.e. looking for key words).
  4. For long questions (you know – the ones with half a page of text!!); read the last line first so you know what you are looking for when you read the rest of the information
  5. Pick the low hanging fruit – quick win questions answered first – if you know it – answer it!
  6. If you don’t know the answer – move on….come back to it at the end – you will have time to really think about the hard ones then. Some papers have all questions worth the same, others have weighted questions – so be careful about how you spend your time.
  7. Use a process of elimination – some answer options are obviously wrong so cross them off. Usually one of the answers is really wrong, another is pretty wrong, one could be maybe right and one is right. Getting rid of the obviously wrong answers to help you focus your thinking on the one or two answers left (this works multiple choice only).
  8. At the end make sure all the questions have been answered….you may just jag it! (once again – multiple choice). If you don’t write anything down then you have no chance of getting it right, so always put something down!
  9.  Wear your subject matter hat – leave your ‘reality’ at the door, don’t argue the questions – answer from how the text books/syllabus would answer. Remember the exam writers have not had your experience – they have only had theirs, and the syllabus or course content is the “common language” you all speak. Don’t try to convert to the real word – use the subject appropriate language, terms, techniques and thought processes.
  10. see point 1 – Practice, practice, practice.

These have stood me in good stead, so hopefully they will work for you. If you have any other suggestions – please let me know!

These suggestions came from Brian Osman, Shane Hastie and Sharon Robson

Posted by Sharon Robson


Posted by on January 21, 2010 in Uncategorized


Telling Stories & Test Pairing

STANZ 2009 was a fabulous event and I am so sorry it is over. It is great to be able to get so involved with some of the best minds in our industry. Karen N Johnson gave a number of presentations and a workshop in New Zealand. It was a pleasure to meet her and discuss various techniques and approaches.

One session of Karen’s that I sat in on was “Test Pairing” – how you can combine your testing to get the maximum benefits. It opened with an excellent discussion on the various types of testing that are available to us as testers. Karen challenged us to think about these test types and others…and it was a challenge. She has compiled a very comprehensive list. The thing that I like about it is that the definitions AND examples are the sort of information that you want to have available when you are talking testing to non-testers, and new testers, and testers who you don’t know. They provide an excellent reference point for common understanding. Karen laced her talk with hints and tips that made it truely invaluable. I’ve found at least 2 new tools and reference sites for my work! (perlclip and Karen also discussed a lot of the test types that are often forgotten or prioritised lower in the test effort. The use of exercises and open discussions from the floor was fabulous as it meant we were able to learn rather than just listen! I got so many hints and tips from this session that I would need 2 blogs to list them all! If you want them, let me know.

Karen’s key note address was about story telling. Which when you think about it, is what we do…and Karen drew that analogy very very well. Her presentation was a delight…a real change of pace. Slides with a picture and a single word! The audience’s world was rocked!!! Karen has become involved in various story telling groups and is working on the art of story telling and then has translated it into the testing world. Given that it is our role to provide information, it would behove us to do it in the best possible manner. Karen gave us hints and tips and pointers on how to make the most of our communication – given that is the primary role of testing – I thought it was great to have more information. It was a really enlightening and thoroughly enjoyable presentation!

Karen also participated in the panel session in New Zealand and nearly reduced us all to tears. One of the delegates asked “what was the best piece of advice that you have ever been given” to the panel. Karen responded with a heart warming story about her mentor, learning, the value of sharing and the place of knowledge in our world. It was great! None of the other panel members wanted to follow after that one! She aced it!

Posted by Sharon Robson


Posted by on October 16, 2009 in Testing, Uncategorized


Tags: , ,

STANZ 2010 – Who and what???

Someone recently asked me “if you could ask any person anything, who would you ask and what would you ask?” This was very thought provoking…and reading the discussion on the STANZ LinkedIn Group made me think about it too. Who and what? To assist I cast my eyes over my bookshelf, blog list, and magazine subscriptions.
Who would I ask and what would I love to hear them talk about?

Rex Black – metrics – best ones, quick wins, most effective

Michael Bolton – metrics – as above (I love to hear the variety of approaches)

Dot Graham – Automation

Capers Jones – estimation, metrics again (am I boring??)

Lisa Crispin &/or Tip House – testing agile!

Karl Wiegers (I know he does requirements – BUT….) – how to test requirements

DeMarco & Lister – Peopleware is a FABULOUS book – more on the soft skills and understanding how testers can work better.

Critical Thinking….anyone who can talk about how to expand my mental horizons and think “outside the square”.

Wow…and the list goes on!

Who would you ask, and what would you ask?

posted by Sharon Robson

Leave a comment

Posted by on September 17, 2009 in Project Management, Quality, Testing


Tags: ,

36 Testing Heuristics

I was able to see James Bach at STANZ  2009 and one of his slides REALLY stood out. He called it the Thirty-Six Testing Heuristics, and he uses it as checklist or reminder of the key things that need to be considered in testing anything. Sounds good huh? Well here we go:


Everyone got that? Any problems understanding? LOL – it is just a quick way of listing the following things…a checklist to help focus your thinking:

Group 1 – cidtestd = Customers, Information, Developer relations, Team, Equipment & Tools, Schedule, Test Items, Deliverables. These are the high level planning activities, the logistical and the “set-up” focus of the testing. This helps set the context in which the testing will be done.

Group 2 – sfdpot = Structures, Functions, Data, Platforms, Operations, Time. I also heard Karen N Johnson refer to this acronym as San Francisco Depot (SFDPOT). This allows you to understand the environment that you will be testing in, in terms of scope, resources and time – the key arms of the quality triangle. This is a vital part of testing in my opinion and one that we often forget to consider in detail.

Group 3 – crusspicstmpl = Capability, Reliability, Usability, Security, Scalability, Performance, Installability, Compatability, Supportability, Testability, Maintainability, Portability, Localisability. This is a great list of the quality characteristics of a system. I prefer ISO 9126 (it is shorter!) but this one gives excellent coverage of the key attributes that will need to be considered for any system. I really like the use of the “ity” at the end of almost all of these – keeps me focused on qual”ITY”.

Group 4 – fdsfscura = Function Testing, Domain Testing, Stress Testing, Flow Testing, Scenario Testing, Claims Testing, User Testing, Risk Testing, Automatic Testing. This list of the types of testing that may, could, should be done on a test project allows us to understand and explain that there is more than one way to test something, and to do it better we need to understand WHAT and HOW we are trying to test something.

Why do we care about this stuff? Well….I often find that people struggle to understand the “entirety” of testing…ie, all the stuff that needs to be considered when we do testing. This helps to outline it to people!

I recently presented a paper on Agile Test Estimation – and mentioned this aspect as well. No matter what lifecycle we are using – these things still need to be considered. And having an impressive party trick like this may just be the answer!

This is a great list, and I am going to be trying hard to remember it. If you see me, see if you can get me to repeat it and if I get it right!

posted by Sharon Robson

1 Comment

Posted by on September 17, 2009 in Quality, Testing


Tags: , ,

STANZ 2009 – The best of both worlds!

Have you ever had the chance to attend every session that you wanted to at a conference? I was lucky enough to be able to go to STANZ 2009 in Wellington, New Zealand AND STANZ 2009 in Sydney, Australia this month. I was able to attend all the sessions that I wanted to and what a boon that was.

The line up of presenters was enough to challenge anyone who only had the chance to go to one version of the conference. To do them each a justice, I’ll do a series postings: James Bach today, Lee, Karen, Brian, Geoff, Linden etc to follow….

 James Bach – a powerful speaker who has the ability to vitalise or revitalise you (depending on your age :-)) and makes you think, HARD! I find that James is really skillful at taking your happy little testing world and tilting it over…and making you re-examine what you are doing and how you are doing it.

“Becoming a Software Testing Expert” was a title that appealed to me, not withstanding that James was presenting. So I just had to attend to find out how to do this….and so I did….James talked us through the differences between perception and reality. He highlighted that expertise may not be dependent on the qualificationsthat you have but it is related to your ability to test things. He also outlined some key attributes that “experts” tend to have and tend to do.  I really enjoyed how he linked this back to Steve McQueen in Towering Inferno (for those of us old enough to remember this fabulous movie!). He also highlighted that sometimes expectations of the expert need to be tempered with reality and context! His levels four levels of learning (to be discussed in later blogs) really made me sit up and think, as did his concepts of developing expertise. The winner though….the 36 Testing Heuristics! Wow…I WANT TO BE ABLE TO REMEMBER THIS!!

cidtestdsfdpotcrusspicstmplfdsfscura ….to be explained in another blog later (I promise!)

As Brian said ( James approach of “Huh?, Really? and So?” is a quick and easy way for you to think about things differently, and to challenge the status-quo.  James is excellent at challenging any of your status-quos and is more than happy to have “vigorous” discussions about any state of play within the Testing (and other) communities. A key learning from this session was “always test your assumptions”. It is an aspect that we sometimes forget to follow up, usually because we don’t always know that we have made them. Critical thinking is something to learn and apply to your testing, and yourself!

As a proponent of ISTQB training I was very interested to hear how much overlap there was between James’ approach to testing in “Think Like a Tester” and the ISTQB Foundation and Advanced Syllabi. I’m glad that testing is growing in popularity within the Software Development Community, and I think that people of Jame’s calibre help enhance the profile and growth of testing.

I was also able to spend some time with James learning the “Dice Game” – no…we were not gambling our life savings away. James and Michael Bolton have established a series of games that allow people to practice and grow their testing skills. It was a wonderful way to spend an hour listening and learning from James. It was also challenging as I tried to figure out the pattern. Sadly I did not have enough time to finish the exercise (duty called) but I was able to learn a lot about myself (which always hurts!) and my testing approach (which is not bad but could do with some tweaks).

James, as always, made me think, made me challenge my assumptions and made me understand my limitations and potential!  He also fired me up again to be even MORE enthusiastic about testing (scary huh??)

If you ever get the chance…you have to see James speak. If you can’t see him, read his blog and books.

posted by Sharon Robson

Leave a comment

Posted by on September 4, 2009 in Agile, Quality, Testing


Common Testing Issues

What are the key things that we find are issues for software testing? How can we address these problems? In my experience we usually have a solution to most of the problems – we just need to identify the problems and then we can workshop the solutions!

Here is my top 10 problems
1. late delivery of code
2. poor requirements
3. wrong requirements
4. late engagement of the testers
5. shoddy code
6. problems in communicating with PMs
7. problems in communicating with developers
8. lack of career growth
9. lack of exposure to/access to test tools
10. lack of training on tools

What are your key issues?

Posted by Sharon Robson


Posted by on July 21, 2009 in Testing