Back in 2011, I approached Rob Lambert at the Software Testing Club on a small series, packed into a narrative format as I wanted to try that out. Rob decided to run that series on the Software Testing Club back then, and I had some fun writing it. Skip forward 11 years, and the Software Testing Club no longer exists, it’s been a while since I have been in touch with Rob, yet I figured, let’s see how this series aged over the years. As a sort of throwback Friday for myself, I will publish the entries on a weekly basis, and read along with you. I think I ended up with eight chapters in the end and might add a reflection overall at the end. Today, April and Peter attend a Testing Dojo at a company Lunch & Learn. In case you want to catch up with the previous parts, I published these ones earlier:
- Chapter 1: Session-based exploration
- Chapter 2: Facing the Business with Automation
- Chapter 3: Fallacies and Pitfalls
- Chapter 4: The Challenge
- Chapter 5: Logged In
- Chapter 6: The Presentation
The Deliberate Tester
Chapter 7: Lunch & Learn
Peter had just mastered his first challenge as John walks into his office.
“Peter, we will hold a Lunch & Learn session on Friday at noon.”
“Lunch & Learn? What’s that?”
“We’re taking over a meeting room, everybody brings lunch, and we’re going to learn something. This week we’re going to hold a Testing Dojo.”
“Lunch & Learn? Testing Dojo? This sounds confusing to me.”
“Oh, don’t bother too much for now. You really should join us. We’re taking our lunch while we’re learning something about testing.”
“Ok, I got that. But what is a Testing Dojo? Are we going to fight?”
“No, no, at least not physically. We get together, pick an application to test, and one pair tests it following some mission while the others are watching. Over the course, we will switch pairs several times. Jennifer will provide the mission for Friday.”
“Ah, now I understand. This sounds interesting. I’ll join you.”
“Alright, see you Friday at noon then.”
That Friday Peter takes his lunchbox to the meeting room only to see the whole team attending the Testing Dojo.
“Hi Peter, great to have you with us.”
“Indeed, Jennifer, I think we may now start. What’s the mission for today?”
“We are going to use the FCC CUTS VIDS heuristic today. The main mission is to evaluate whether it can guide our testing. The secondary mission is to test google maps with it.”
“Ok, I think we need some clarifications before we can get going. What’s FCC CUTS VIDS?”
Jennifer takes a pen and starts to explain the mnemonic on the flipchart.
“In this mnemonic, each letter stands for a certain aspect we may want to watch out for. So, F stands for Feature, the first C stands for Complexity, the second for Claims of the product, the third C is for Configuration, U is for User of the application, T is for Testability, S is for Scenario. The V is Variability, I is Interoperability, the D stands for Data, and the final S for Structure.”
Feature
Complexity
Claims
Configuration
User
Testability
ScenarioVariability
Source: Michael Kelly
Interoperability
Data
Structure
“Ok, I think we got the picture.”
“Great. We will run a paired session today, exchanging one tester every ten minutes. So, who’s going to start on this?”
John and April jump in to test first.
“As a reminder, I ask the audience to stay quiet until asked directly. You’re ready? Then let’s go.”
“Ok, April, I think we should give this some thought first. Did you use Google Maps, yet?”
“Yeah, let’s go over the mnemonic and see where to start.”
“Sure. Feature, I think there are plenty of these.”
“You’re right. I think this will be the biggest area to explore. Google Maps does not have much complexity, what about claims about the product?”
“I don’t know about any. So, we might want to use some time researching this. Ok, configuration, there are some settings.”
“Sure, we might explore these as well. Users using the application will be hard to simulate that in a short time period.”
“Testability, hmmm, let’s note this down for later. Scenario, I think we could come up with some good scenarios on testing this.”
“Indeed, let’s note down variability and interoperability in case we got some time left. Data is interesting, and structure as well.”
“Ok, let’s start with exploring the features. Let me open the browser.”
“Let’s start with planning your daily route to work.”
“Ok, I enter the work address, and seek directions from my home address.”
“Oh, a list of suggestions pops up while you enter addresses. Let me note this down for further exploration later.”
“Alright, I can plan a route. Now, say, I want to go here by walking. Ok, this also does look good.”
“Indeed. What happens, if you plan to go from New York City to Munich, Germany?”
“Let me try this. Oh, look, it tells me that it could not calculate the directions between New York and Munich.”
“Is this a problem or not a problem?”
“I don’t know. Far distances seem to be unsupported. Shall we explore the maximum travel range?”
“Let me note this down, too. We may get back to it later. Or should we tackle it now?”
“No, let’s get ahead. Now, what about zooming in on a road? This looks fine with me, but what’s that?”
“Oh, there seem to be some images missing when zooming in too fast. Let’s note this down as well.”
Jennifer interrupts the two: “I’m sorry, but ten minutes are up. John, I would ask you now to go back to the audience, April takes over the keyboard, and we need a new volunteer. Anyone?”
Peter decides to take the challenge: “I’ll volunteer. Let me take some notes while you test, April.”
“Alright, it’s April and Peter for the next ten minutes.”
“Ok, you were touring the features. How much time should we spend with it?”
“I think we should give it some more time, and then go to the next topic. We got mostly all the features of Google Maps covered.”
“Ok, what do you think about Streetview?”
“Oh, we didn’t take a closer look there. Let’s try.”
“When you drop the Pegman to the map, you can see where Streetview images are available.”
“Yeah, let’s see if they got images from our company building.”
“Oh, look, nice. Now, let’s walk down the streets. Ok, this works, too. Though the interface needs getting used to.”
“Noted down. Let’s see where we could go to lunch today.”
“You mean we should search for locations nearby? Let’s try that.”
“Oh, it lists up some restaurants here.”
“Yes, you were right.”
The team continues following the heuristic to test Google Maps. They switch the pairing partners every ten minutes. In the end, Jennifer calls for a short reflection.
“Alright, our mission today was to learn about a different approach to testing. Did the FCC CUTS VIDS heuristics help to guide our testing today? What do you think?”
“Sure, though there didn’t seem to be anything new. It was interesting to focus on generating ideas for a particular topic.”
“Yes, you’re right on this, John. I think we could have taken some more time initially to set up a brief charter and pick particular goals for test coverage.”
“Do you think we should use this heuristic to guide our testing?”
“Absolutely, we might try it out over the next few iterations and see how it can help.”
“Yes, I agree, it seems useful. but a simple session does not provide enough information about its limitations. Let’s try it out for some time, and reflect on the benefits during our retrospectives.”
“Thanks, Jennifer for providing this mission. It was a great session. Now, let’s get back to work.”
One thought on “The Deliberate Tester – Chapter 7: Lunch & Learn”