Helping Jim

Let’s take a look at a tester:
Jim is doing well in his current position, he is considered a good colleague (also by developers). No-one is saying Jim is lazy or incompetent. He browses a few blogs every so often and figures out how to slightly improve he performance at work. So why should he try new things?

I’ve found that in my work I deal with 2 types of situations:
a) Simple – something I can handle due to experience, skills, knowledge of the context, etc.
b) Complicated – something that I can’t handle easily. Due to new context or time/peer pressure or lack of skills, etc.
Continue reading


Summary of my presentation at PEST 4.5

For brief overview what was it all about read:

I threw my creativity at the first task:
* Feature/area vs bugs/severity (how to show you have major and minor bugs in different areas of the product/system under test)

Continue reading

PEST3 – About session debriefing

More PEST3 notes, this time about debriefing in session-based test management.

For working with novice testers, it is a way of coaching. Few ideas what to do:

  • Check if report is formatted and written in usable / readable way and there is balance between what is said during debriefing & what is written
  • Question every sentence
    • why is it written down
    • why is this relevant
  • Look for what is not written as people omit “common sense” things
  • Find out what was actually tested
    • how tested, what data used, etc
    • what way the tester thought about the testing
  • Give out own ideas about the test area
    • special domain knowledge
    • background
    • test ideas how to think about

With experienced testers, it more of a information sharing/peer review:

  • About the product/feature/etc
  • About the (possible) problems, tiny details, etc
  • “Remarks section” analysis and questioning is very useful
  • How other people test, their insight and ideas are fascinating

Pro tip on how much to write in session report:

Write as much you need that after 2 weeks (or months) you could clearly remember (by reading your own report) what was tested & why it was tester.

PEST3 – talking testing to management

PEST3 Notes.

  • Be clear when asking for different way of testing. What do you really want and what the impact is.
  • Don’t lie or be too fluffy.
  • Practical results speak more about their work then the explanations
  • Patience and less sarcasm works (specially when they don’t get it, don’t be bitter)
    • Say “No” fiercely to save time to start dialog.
    • You can be direct instead of ‘nice’, but being “bad/bully” for no good reason then that does not help cooperation too. There is fine line between “Firm” bad and “Firm” good.
  • Be concious about the tone of your voice specially when you don’t agree with what’s being said.
  • Don’t fight in front of the group with just one person
    • Call him/her later and discuss it then. All is easier.

CDT School of thought. Reminder.

The Seven Basic Principles of the Context-Driven School

  1. The value of any practice depends on its context.
  2. There are good practices in context, but there are no best practices.
  3. People, working together, are the most important part of any project’s context.
  4. Projects unfold over time in ways that are often not predictable.
  5. The product is a solution. If the problem isn’t solved, the product doesn’t work.
  6. Good software testing is a challenging intellectual process.
  7. Only through judgment and skill, exercised cooperatively throughout the entire project, are we able to do the right things at the right times to effectively test our products.

Read more here.

Why is this important?

When discussing and going deep into details of testing ideas it is easy to forget where we came from. It is very refreshing every now and then to pull out and remind yourself the basics of CDT. Go read it now. And relate that to whatever you are doing/thinking about.