Tuesday, January 28, 2020

Testing Tour Stop #8 : Pair exploring about exploratory testing with Simon Tomes

I was on my eight stop with Simon Tomes to discuss all about exploratory testing. When I was very new to exploratory testing, where i was trying to figure out how I can structure my exploratory sessions and show value to my team, I came accross Simon's #PQIP Problem , Question, Ideas, Praise and here's the blog for more details.  I started using this approach along with various different approaches to document and share it with my team. It was so great to pair with Simon and learn more about exploratory testing.


When I reached out Simon about doing this session, he was so kind that he just gave me his available date straightaway and we booked in 2 weeks time.

It’s incredibly kind of you to ask, I’d love to pair up on a testing tour session with you. It’s not something I’ve done before and I’m super curious to learn from the experience and from you.


Session


We started off our session with lot of energy and excitement and the first thing we discussed about was about testing community. Then I asked Simon, how and when does he integrates exploratory sessions and how does he plan for it. And I shared that I sometimes use mindmap as well to take notes during each session and then add all this information to the ticket. The reason why I add information to the ticket is not as a proof or something, but to help us reflect/revisit our testing approach. Simon translated this very well - 

“We don't document our discoveries to cover our backs. We document our discoveries to give back to the product.”

Then Simon ran ran through an example of exploratory testing notes for an exploratory session : "Explore Lean Coffee Table, cross-browser, to learn about sharing a board".



Then Simon mentioned that we always need to think first about what value does the product need to provide to the users, what are the potential risks that might come up, what questions do we have to come up with to identify those risks and then taking those questions and turning them into tests. This for me was #VRQ - Value, Risks, Questions.

Then after a long interesting discussion we decided to explore the product I'm working on. Zoom was great to share the screen and then I started to give some context about my product. Simon asked me how did I approached to understand this product when I was new to this. Initially it was difficult to go through the documentation and then explore the product because I was completely new to this domain. Our product is called Mia platform  which is a cloud platform that automates the accounts receivable life cycle which delivers greater efficiency, accuracy, visibility and cost savings for companies.

Then I shared with Simon that , I started to pair with project managers/product owners who were very close to the product and the users/clients to understand how it used.  I then reflected back on what Simon mentioned about asking questions to understand risks on one of the functionality of our product.

  • When the user logs in, the user can see a diary panel that gives the information about what kind of tasks needs to be done and for which customers and lot of other information. Its just like a simple diary or journal with notes of what needs to done today. 
  • Once the user clicks on one of the item from the diary panel, it takes the user to the customer account to perform the task or action or can also create a task.
  • If I'm exploring these two steps without asking any questions then its just a page with some call to action links which takes the user to customer account and we can click through to create or complete a task. It feels simple. 
  • But, if we ask some questions like - 
      1. How does the user use this diary panel?
      2. What problem is the user trying to solve by using this diary panel?
      3. What is the impact or risk of this diary panel not loading up with the items?
      4. What is the impact or risk of this diary panel loading up with incorrect details?
      5. What is the impact or risk if each item on the diary panel is not clickable?
      6. Where does the information come from on this diary panel?
  • By asking these questions(which are just few and there might be more questions that can be added) we can understand what value is this diary panel providing to the user, what are the different risks and then these could be in turn tests to check this. 


  • Then we discussed what if we applied the same approach for creating tasks functionality to find out value and risks. 
It was really interesting to share and discuss different approaches while testing. Here is the video which Simon shared  about - Exploratory testing  - Risks and questions and a handy note taking template .

Learnings from the session

  • A new approach of converting questions into tests and using those questions to find the value and risks. 
  • Being a solo tester you always have that fear of being not sure if you doing it right, by having conversation during this session and sharing my approach and getting the validation gave me so much confidence. 
  • We can always prioritise(by getting what is important from the team) which part or where to explore and come up with risks.
  • Its not just about finding issues while exploring but also finding useful information.
  • Technology can always give us troubles, even if you have back device as an option :D. We did face lot of unstable connection issues which is part of the remote pairing challenges but we overcame by switching to back up devices we both had. 
We could have really continued for another hour or so if we have not had this technical difficulties. Simon did mention that he would be happy to collaborate again which was awesome. Thanks to Simon for sharing all the valuable information and being part of my #TestingTour



No comments:

Post a Comment