Tonight, @darktelecom will be joining us for a masterclass exploring exploratory testing 
(can you say that 10 times fast? 
)
If we don’t get to your questions tonight we’ll add them below. If you’d like to continue the conversation from the webinar, here is an excellent place to do that 
Of course, the recording of the masterclass will be available to everyone in the Masterclass section of our website after.
Looking forward to it 
Wow what a session!
Well, as I’ve shown, quality assessment is different with exploratory testing; it’s a true assessment, so it means we got our own perception of quality based on what we explored.
With a traditional test management tool, you could for example create custom statuses to indicate an higher or lower confidence.
You can still mark it as FAIL if you have a blocking problem there.
Marking it as PASS, as you’ve mentioned, can hide issues. But you can also create a PASS_NEEDS_DISCUSSION for example. I would advise you to try what works with your team. It also depends on how you share/debrief afterwards… you may want to have a more visible status to signal something or not.
Well, whenever debriefing it’s important to have there the people that were mostly involved in that feature/story/etc.
So, having the developers and testers makes all sense. In one of our teams, we do mob-programming with testers also involved. So feedback comes early. But later on, whenever exploring it in more depth, maybe we need to have the product owner involved. I all depends on the risks that were addressed. If some usability issue comes, maybe we need to bring one of the experts to the discussion.
In terms of single testers, in my experience doing the scripted testing => exploratory testing migration requires that people understand what they’re doing, the limits of what they’re doing, what they could achieve if done otherwise.
We need to understand why they have been working in that way… maybe they were told to do so, or simply they aren’t aware that there are different and better ways.
Depending on the context, one thing we can try to do is to remove the inner details of scritped test cases… and start giving more and more freedom to the tester. At a certain point, people may reflect that they don’t need that guide anymore and that the guide/script actually limits themselves to discover valuable information.
To management, I think we have to show them the limits of scripted testing and traditional test cases. How they miss unknown risks.
Pairing with them could be something interesting to try out. In that case, I would not say “let’s write some test cases and then let’s try exploratory testing”. Instead, I would say “do you have some time? I woud love do to an exercise with you and use your expertise to provide feedback on something”… and then let that person explore somethiing and share thoughts with you. And then you could say “see, this is precisely the kind of value we can get with exploring… we learn, together… find problems, find ideas, gaps”.
It’s important to understand where that person stands (needs and concerns) and format the message accordingly. What I’ve seen is that people wants numbers and green/red flags because that gives them an easy way to deal with information.
Another way to look at it, is that with scripted tests, even if the system and risks were static (which they are not), we focus on finding bugs by looking at our expectactions.
With exploratory testing we have the ability to further improve the product… because we raise concerns, new ideas and we also find gaps. Checks won’t find gaps. It’s essential in a product to improve it by making sure we have there the things that matter and not just the things we’ve implemented.
Every time is a good moment to explore It’s not time that we waste, even if the product doesn’t change.
Remember that risks are dynamic (team is dynamic, context is dynamic, relevance of certain features is also dunamic, etc). Therefore exploring always provides value (unless you do exactly the same).
If you have a big feature, for sure you’ll need to explore it - and by explore I just don’t mean “explore after being built”; I mean it needs to be explored conceptually, discussed, explored whenever is being built and afterwards.
If you’re going to address a user story, then it’s good idea to explore it and at the same time implement some test automation for the happy paths, for example. Exploring complements automation (exploring also gives ideas for automation… and automation is also a way of exploring btw).
Whenever exploring we are walking in the unknow, and learning. If we postpone learning to somewhere is the future, the risk will still be there… the problem that it’s going to be harder to deal with it.
Each person brings a perspective. As I mentioned, and quoting once again professor Cem Kaner,
Use “diverse half-measures”-- lots of different points of view, approaches, techniques, even if no one strategy is performed completely. – Cem Kaner, Black Box Software Testing
so each person has its own perspective, its own backpack of knowledge. Part of it may be overlapping, other not really.
Traditionaly, a developer has a greater backpack of knowledge in terms of the product, from a technical standpoint. Traditionaly, a tester has a greater backpack of knowledge in terms of testing.
Having developers and testers together, pairing, is for sure beneficial.
A conversation can start around the feature, from a funcional perspective, then go more to a technical side and back to the functional side.
In one of my teams, we have testers involved in mob-programming, being there to provide feedback and also do some guidance.
Well, just to clarify: there are 2 apps
What we call Xray (https://www.getxray.app/), that everyone knowns as such, is a test management solution that works inside Jira.
And now we have Xray Exploratory App (https://www.getxray.app/exploratory-testing-app/) which is just a desktop app… that may connect with Jira+Xray, or you can simply use it without Jira+Xray
You can save your sessions locally, in a file. You can also export the session results to a .zip file, containining a PDF with all the notes and screenshots, plus the evidence as individual files.
If you do have Jira+Xray, then you can have some additional benefits such as uploading the results to Jira and also the ability to create defects right from the Xray Exploratory App.
Yes, what you do whenever exploring is up to you. In that case you would probably record the whole screen, instead of picking up a specific application and/or browser.
What’s important, is that you have a charter that gives you the mission and some limited scope. Otherwise, you can be wandering around as James Whittaker mention.
Exploratory testing without good guidance is like wandering around a city looking for cool tourist attractions. It helps to have a guide and to understand something about your destination. - James Whittaker
It’s also better in terms of analyzing progress, because you can have a more limited and concrete scope that you can be able to provide a quality assessment.
Timeboxing has some benefits
I would say that using 30m or 45m is fine but this is something that needs to be tried in the team.
One of my teams is not really timeboxing though; that is working for us until now.
You mentioned about being fresh; I totally agree, we need to focus and defocus to foster different types of thinking. Making a pause, walk a bit outdoor, even washing dishes (which works for me), can provide you new ideas you can try when you get back to the keyboard