Wow we had tonnes of questions in this workshop with @ezagroba 
If you’ve got questions from the workshop, ask them here!
2 Likes
Who do you share your Charter results with? Do you just take the summary/bugs and share them? Does anyone else ever see your exploratory session notes?
1 Like
Have you ever combined Charters and Mindmaps to try and force you not to write test cases? - Lukas
1 Like
Do you use and go from US towards the charters? is that a best practice? - Shalini Tharakan @shalinigt
1 Like
I worry that I create test charters that are more like test cases than guides for exploration. How can I gauge whether I’m in the right spot? - Adjoa
1 Like
I’m much less formal in my exploratory test mission. I try to make the mission statement as short as possible, so that it removes “specificity”. I then write that down on the Jira ticket or on the wiki page I’m using for notes. (Other exploring note taking tools do exist.) I’m a great fan of timeboxing things and of vary my day, exploring all day long is tiring, so give yourself breaks by having other kinds of work to interleave.
To stop it feeling like actual testing, don’t bring too much baggage. I always use tools when testing, some questions are hard to answer if you are exploring with just your two feet. So I’m often times prototyping a new automation script when I go exploring, just to speed up a discovery. Fruitful exploring often involves bringing a few tools along for the journey, like good walking boots, a water bottle and so on. (Metaphorically speaking of course.) And this means leaving behind the very specific and heavy tools you normally use when testing, and instead bring just a spade, if you go exploring and don’t bring a spade, you are never going to dig up really useful big bugs. But just don’t bring the backhoe (mechanical spade.) By not bringing your usual tools with you, you force yourself to find different kinds of bugs by crafting what you need on the fly.
By forcing breaks in my exploratory test session, I gain enough time to step back and determine if I am still in the right spot. I also hate writing Jira’s while busy exploring, so I do it at the end of a day, which lets me get that sense of accomplishment from each session by doing all the bug logging in a batch. If the bugs I raised are not around my “charter-mission”, I use that as a hint I went off course.
1 Like
Have you ever combined Charters and Mindmaps to try and force you not to write test cases? - Lukas
For complex applications I’m not sure it’s possible to go without test cases unless there is a comprehensive automated suite to fall back on.
I might share the results of my charters with my product owner, my developers, other testers, UX, and if there’s a bug for another team or third-party, them too. When I get time to plan ahead, I also share what I’m going to test before I test it.
Yes, I don’t give people a play-by-play of what I did to test, there’s some summarizing involved.
It depends what kinds of notes I’m taking. For testing user stories, my notes mostly end up in the ticket in words or a mindmap. Sometimes I also have things on paper as a draft that people don’t get to see remotely anymore.
Yes and no. Yes, I’ve combined charters and mindmaps. No, I don’t try to force myself not to write test cases. When I’m capturing a record of some of my testing with automation, or someone wants to make sure I’m covering a particular scenario, going as deep as one test case on a mindmap will build that confidence.
But the way I’m thinking about the testing is one level up, if you collapse one (or more) sections of the deepest reaches of the mindmap.
Yes, I do use user stories as a jumping-off point for what is risky or confusing, where I have questions, and where it makes sense to explore. I’m not sure if it’s a best practice. It’s working for me in my context. I’d be curious to hear about instances where it hasn’t worked.
Ultimately, getting feedback from your team will help you find the right level of detail here. For me, charters are too specific when I follow one path and don’t have anywhere else to go. It could be that a very specific charter still takes you to places where you encounter bugs, gather important information about the risks in your product, and gives you ideas about where to go next. If you’re having “ah-ha!” or “oh no!” moments, you’re doing it right.