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.
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)
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
- 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.
Pose an arbitrary rule for using the product and then try to go through the main scenarios. The goal is to learn more about the product, using the extreme situations to get ideas for normal operations.
The Seven Basic Principles of the Context-Driven School
- The value of any practice depends on its context.
- There are good practices in context, but there are no best practices.
- People, working together, are the most important part of any project’s context.
- Projects unfold over time in ways that are often not predictable.
- The product is a solution. If the problem isn’t solved, the product doesn’t work.
- Good software testing is a challenging intellectual process.
- 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.