March 2014 Software Testing Club Atlanta meetup

RSVP for the March 2014 meetup of Software Testing Club Atlanta features our own Eric Jacobson’s “Maybe We Don’t Have to Test It” from STAREast 2013:

Testers are taught they are responsible for all testing. Some even say “It’s not tested until I run the product myself.” Eric Jacobson believes this old school way of thinking can hurt a tester’s reputation and — even worse — may threaten the team’s success. Learning to recognize opportunities where you may not have to test can eliminate bottlenecks and make you everyone’s favorite tester. Eric shares eight patterns from his personal experiences where not testing was the best approach. Examples include patches for critical production problems that can’t get worse, features that are too technical for the tester, cosmetic bug fixes with substantial test setup, and more. Challenge your natural testing assumptions. Become more comfortable with approaches that don’t require testing. Eliminate waste in your testing process by asking, “Does this need to be tested? By me?” Take back ideas to manage not testing including using lightweight documentation for justification. You may find that not testing may actually be a means to better testing.

As quality assurance manager for Turner Broadcasting System’s Audience & Multi-Platform Technologies (AMPT) group, Eric Jacobson manages the test team responsible for Turner’s sales and strategic planning data warehouse and its broadcast traffic system. Eric was previously a test lead at Turner Broadcasting, responsible for testing the traffic system that schedules all commercials and programming on Turner’s ten domestic cable networks, including CNN, TNT, TBS, and Cartoon Network. Prior to joining TBS, he was a tester at Lucent Technologies. Eric joined the tester blogosphere in 2007 and has been blogging about testing on every week since.

When is back up, I’ll link to the page so you can RSVP.

For now, plan to join us on the evening of Thursday March 20th.

Location TBD (Let me know if you want to host us!)

Potty training

STC ATL Dec 2013 MeetupMy first experience with testing games was back at my first testing conference when Michael Bolton gave me a testing challenge at lunch: a rubber ball. I didn’t know what I was getting into, but I knew I loved games. And that is a key aspect of how games help us to learn: getting past our resistance by promising us fun. Since software testing is a complex mental activity, exercising our minds is an important part of improving our work.

After attending several testing conferences, I can safely say one of my favorite aspects of these gatherings is evenings filed with testing games. (That is, games for testers, not testing video games.) Whether you’re rolling the dice (more, spoilers), deducing when a pen is not a pen, building a tower of pyramids, or shouting out “Set!” as you casually wander past, testers love a challenge.

So it was no surprise that John had his game bag already on the table when I arrived for the STC ATL holiday meetup. What I didn’t expect was Disruptus, a new-to-me game. He explained for a few minutes and then we jumped right in to playing. Almost immediately, I flipped over a card with an image of a toilet and the improve card:

Add or change 1 or more elements depicted in the card to improve the object or idea.


Skip this TMI stuff!

Since we are currently potty training at our house, this was a particularly relevant subject for me. I started rattling off ideas as they came to mind. John stopped me and said that I wasn’t coming up with new ideas but instead listing things that had already been done. While I agreed, I found that saying each of the knowns out loud helped me to clear my head for the next idea to come along.

Ideas that sprang to mind:

You know, for kids

    • toilet seat lock for babies just learning to walk
    • toddler height toilet
    • step stool for standing toilet training (boys)
    • separate lightweight plastic toddler toilet – could be portable
    • folding travel toilet seat for toddler on-the-go
    • built-in potty seat for toddler years that is easily removed for cleaning
    • moveable toddler handled seat for better balance
    • splash guard for boys potty training
    • tiny plastic urinal – I’d seen one once at a kids consignment sale
    • toilet target for potty training boys
    • soft-close lid that doesn’t slam down on little fingers
    • tie-in to children’s book/video for better motivating child (i.e. matches picture) – with audio/musical accompaniment for better motivating child
    • toilet with book rack attachment – also good for adults!
    • tie-in to popular children’s character for better motivating child
    • And of course Pinterest is awash in toilet training ideas

Adult toilets

    • Dune’s Fremen stillsuit (okay, so that’s not real…)
    • water-conserving toilets – high efficiency, multi-flush options
    • recycling water from washing hands for next flush
    • elevated tank to use gravity for flushing
    • recently read an article about posture and advantage of raising feet using step-stool
    • bidet attachment that I saw at a co-working space
    • soft seat vs. hard seat
    • toilet scent spray that a friend mentioned to me & has ridiculous commercial
    • elongated seat
    • elevated seat for elderly with limited range of motion – vs. seat riser/handles
    • foot pedal to raise/lower the lid without using hands
    • putting the seat back down in the first place
    • self-cleaning – or at least those tablet attachments
    • germ resistant surface
    • I’d once seen a toilet with an automated toilet-seat-cover replacement system
    • I’d seen more exotic toilet options in a local farmer’s market store
    • a friend explained the composting toilet to me
    • chemical toilet/waterless toilet for big events like outdoor concerts
    • urinals – I’d seen a public outdoor urinal in Amsterdam that was just two large crosspieces for minimal privacy
    • device allowing women to stand for urination – thanks, Twitter!
    • chamberpots
    • outhouses
Things I’d never heard of
    • Glow-in-the-dark toilet seat – this would be a big hit with the kids!
    • Squat toilets
    • proximity sensor
    • toilet seat warmer – including power saving mode!
    • electric lifting seats for the elderly
    • female urinal
    • sound cloaking
    • toilet slippers
    • pretty much anything shown in Cars 2 when Mater visits the restroom


Of course, it wasn’t until much later (esprit d’escalier) that the thing I really wanted to improve came to mind: I hate toilet auto-flush algorithms. As a happy user of toilet seat covers in public restrooms, I always feel concern about whether I’ll have to contend with a particularly sensitive hands-free toilet. Despite my years of experience, I have not yet mastered the art of evading the motion sensor while placing the toilet seat cover.

I would love to rewrite the algorithm to some set pattern of motions that would distinguish between someone leaning toward the seat to place a liner – and so avoid germs – and someone leaving the stall having completed her errand. Even clap-on, clap-off would be preferable to spray in the face from an unexpected flush.

Protip : My husband takes a 2 foot length of toilet paper and blindfolds the sensor. Manual flush never felt so good.

Training through play

So now that you made it past TMI, let’s get back to the notion of testing games for training testers. Do testing games help testers learn how to test? Many testers are making an argument for this.

John Stevenson is one of them. He uses Disruptus to encourage disruptive thinking that leads to innovation – in testing. Create, Improve, Transform, Disrupt: these 4 approaches are important when designing and executing tests. Finding new ways to remix our tests helps us to focus on things that matter but to approach them in a new way, extending our coverage of various paths and potential usage patterns. My experience with only a few turns of this game left me invigorated and encouraged to try new things at work.

How have you used games to learn about testing?

Sketching for fun and profit

Have at you

As I recently wrote in Better Software magazine, I tend toward visualizing information. While this does not mean I skimp on words – as anyone who has been near me for 15 minutes can attest – it does mean that I think more clearly when I have a whiteboard in front of me and a chisel tip marker in my hand.

Ode to whiteboards


One Christmas gifts my husband installed a wall of whiteboards in our home for the children to draw and scribble. The children loved it and happily covered it with unintelligible childhood graffiti. As it turned out, this blank wall was a greater gift to me. When I was preparing to present at conferences in 2013, I was feeling quite blocked in writing proposals and producing presentation materials until I relaxed and just let myself have time with my home whiteboard.

I hadn’t realized how much I missed having a large expanse to fill with thoughts as they came spilling out. At my first testing job, my XP development team installed a wall of whiteboard for just this sort of thing, removing barriers to collaboration by having enough space for any conversation the team needed to have. Of course, some corners were dominated by persistent big visible charts but those lasted only as long as they were needed. Yes, I was spoiled.

I decided to keep my presentations simple and sketched the images I wanted to have in my slides on this wall. It turns out taking well lit pictures of whiteboards without glare is sufficiently difficult that there are apps for that. Go figure!


I also realized that I would be in a fix at the conference if I didn’t have a whiteboard handy, so I scoured the internet looking for portable options. It just so happened that one of my favorite nerdy websites was advertising a foldable pocket whiteboard. One look and I was in love. I was able to easily take notes in any way I saw fit and at a scale that pleased me, not being limited to eight and a half by eleven or whatever dimensions a digital application considered adequate.

In my day-long tutorial preceding CAST 2013, on a team with people I’d never met, I wasn’t sure how to begin solving the problem, but the casualness of a portable whiteboard that could be unfolded, scribbled on, wiped away, and stowed out of the way was definitely an asset to establishing good communication from the beginning.

It also came in handy when I was able to snag a table at one of the Agile2013 social events to catch up with a speaker whose talk I had missed. He liked it so much, he bought three. Subsequently, another friend from the conference asked whether that would be a good speaker gift and I heartily assented. Now I’m wondering whether this company pays for referrals. 🙂

Drawing pictures at work? Really!

At Agile2013, in his presentation Sketch you can!, Jeremy Kriegel explained using graphic facilitation to craft meetings that better involve attendees. People can focus on visuals easily and suggest improvements. This sketching is a combination of note taking and wire framing, which is something user experience (UX) folks do routinely as part of their work. He describes trading quality of the drawing for speed in order to keep the focus on communication, then enhancing the drawing later. The focus is on the need people are trying to satisfy and understanding the context of that need.

By sharing in a concrete way, you can validate precise language and discover where meeting participants are not agreeing. The result is a public record of the conversation that can be shared. (I’ve been known to take many many pictures of whiteboards in my day.) However, the communication is more important than the deliverable, which helped to free me of my concerns about how much artistic talent I have. I felt comfortable improvising and the sketching was a sort of performance, although in the class we were not standing up in front of a group.

Earlier today, I was having a conversation with a colleague at a whiteboard and sketching the interacting parts of the problem we are testing was very helpful for focusing the conversation and revealing areas that we needed to investigate. I’m definitely a fan of drawing pictures at work and I appreciate Jeremy’s encouragement.

Sketchy people

Periodically, I rediscover Gaping Void and wallow in the talent and inspiration of these images. My most recent visit followed a tweet to his blog on new year inspiration:

I guess my “mountain” was drawing cartoons (like the cartoon at the top rightfully indicates), although it took me DECADES to find that out. – Hugh MacLeod

However, I was so drawn to his live sketching videos that I decided to give it a whirl. Not sure where to begin, I snagged a photo of my 95-year-old grandmother off a family member’s Facebook and took a shot at digital sketching. I’m pretty pleased with the result. It’s not my best effort and I’m not worried about that because it was so much fun to try.


When I’m so busy that I don’t have time to blog or read a book or play a board game, I still have time to sketch something out, however crudely drawn the result might be. I know I won’t turn into an Andrea Zuill overnight, so I keep at it a little at a time.

I’m finding that sketching on digital photos or enhancing existing images (so far no original memes!) is much much easier than starting from nothing, so that’s kind of my thing at the moment, but I’m finding the courage to stretch a bit more into original composition. We’ll see if anything comes of it. For now, it gives me something creative to do that personalizes my slides a bit more.

How do you use sketching for fun or profit?

Guest Author in Better Software

Check out my recent article Feeling Lost in the Woods? Mind maps Can Help! [PDF] on page 26 of Better Software magazine.


Claire takes us on a nontraditional journey where designing and implementing testing approaches can be rapidly organized into a hierarchy of connected elements. Mind maps, used primarily for visual and conceptual thinking, may be just the answer for quality assurance professionals.



Recently, Testing Circus was asking about how testers are framing their new year. Many testers contributed their plans to form quite a list! Will sharing our plans with others help us to achieve what we set out to do? It seems worth a try. More to the point, will we actually execute all the plans we make? I think it will be much like exploratory testing in adjusting based on new information we learn, but at least I’m starting out with a plan.

Here are my charters:

  1. Read. Blogs, books. Or even watching videos and listening to podcasts. (I know not everyone is a visual learner.)
  2. Small groups for collaboration, especially local. This year, I’m focusing on our fledgling Software Testing Club Atlanta.
  3. Put yourself out there to get public feedback (blog, pitch to a conference, etc). I’m currently pitching to Agile2014 and trying to get back to blogging and writing articles after the holiday lull.
  4. Experiment (trying what you’ve read, discussed). This. Everyday.
  5. And, of course, connect through social media!

Image credit

Est testing parfait?

I heard that Gerry Weinberg has an exercise called “Mary had a little lamb,” in which you analyze each word in the sentence to elicit implicit meaning that might be important. This sounded interesting enough to try, so when the opportunity came to propose a topic at Test Retreat 2013 I went for it. My topic “Is testing for me?” didn’t end up formally scheduled but made a nice interstitial topic to discuss with those milling about in the main room.

I chopped the sentence into separate words and wrote them top-to-bottom on a large sticky note. Then, instead of giving some sort of prepared remarks, I elicited brainstorming from the gathered participants. Having received interesting feedback on my professional and personal strengths at Agile2013 that had left me questioning how best to use my evil powers for good, I wanted to hear how others were thinking about the testing field and how it fit them.

The resulting scrawled notes ended up a mindmap, the path of least resistance for me. I won’t say the discussion solved all my problems, but it did give me some direction for future exploration – exploration that might also be helpful to a newbie wondering whether to pursue a career in testing.

Is testing for me?Which brings me to some interesting recent events:

I started composing a list of things I’d recommend to people just starting out as testers to help them to evaluate whether to continue. I wanted to encourage them to jump right in but also think big, not waiting them to wait 5 years to reach out to the wider world of testing (like I did).

Here’s my current list. I blogged about various experiments I tried, so you can read for yourself to see what it’s like to select what’s a good starting point for you.

No matter how many times I think I’ve found all the meaning in my testing career, suddenly I realize there are more layers… but like a parfait, not an onion.

Donkey: Oh, you both have LAYERS. Oh. You know, not everybody like onions. What about cake? Everybody loves cake!
Shrek: I don’t care what everyone else likes! Ogres are not like cakes.
Donkey: You know what ELSE everybody likes? Parfaits! Have you ever met a person, you say, “Let’s get some parfait,” they say, “Hell no, I don’t like no parfait”? Parfaits are delicious!
Shrek: NO! You dense, irritating, miniature beast of burden! Ogres are like onions! End of story! Bye-bye! See ya later.
Donkey: Parfait’s gotta be the most delicious thing on the whole damn planet! – Shrek

Thanks for the inspiration to write, EmJayKay80 and Niyi!

STC ATL Lean Coffee #1

STCATLMeetup1-DotVotingOver the last few years, I have been getting to know other software testers here in Atlanta. Frequently, beginning this new acquaintance is such a positive experience that the other tester urges finding others similar to us to meet more regularly. This is such a common outcome that I am no longer surprised when first conversations end this way.

I don’t have much experience with the particulars of sifting through a large tech community for people interested in hanging out during their personal time to chat about testing software. However, when others insist on giving you a boost, it’s harder to say no.

I have demurred all these requests until now. Eventually it seemed silly to continue to turn down the genuine offers of resources, energy, and enthusiasm. I almost felt bad about denying people the community they so clearly craved. So here we are.

I love meeting new people and engaging them in conversations. However, I realize not everyone is comfortable doing that. I’ve noticed that having a structure to interactions can reduce the social barriers for those who might otherwise hang back.

At Agile2013, I noticed that Lean Coffee was an easy way to get to know a group of strangers, so I thought it would be a good place to start for the newly formed Software Test Club Atlanta.

I have participated in several Lean Coffee events run by different facilitators. I liked the simple style and frequent feedback so much that it was the first thing I brought back with me to work after Agile2013. The format proved fruitful for an internal meeting and so it seemed like a good idea for starting this local meetup.

Another good idea for starting something new is affiliating with established allies. Since one of my benefactors was part of the Software Testing Club community, I thought co-branding made a lot of sense. I led the idea of extending their brand to the United States since doing so would bring more people together worldwide than I could on my own. I wanted our nascent local group to be connected to the larger world of testing enthusiasts from the beginning. That would support the new members’ sense that each of them is not alone, the connection that drove creating this group in the first place. This is really a community building itself. I just happen to be in the center of it.

I love helping people to connect deeply with one another, so it seems only natural to put in the effort of providing the means for others to come together. Now that I work in social media, setting up channels for others to find us and join in the discussion was my first step. I want to be discoverable so that other local testers who feel the need for connection won’t have to wait so long for me to happen along.

I really appreciate that local businesses are supporting our efforts to make time to tackle difficult questions in testing and to share what we’ve learned through our professional and personal experiences. So you will definitely hear me being vocal about thanking them. I wouldn’t choose to do this alone and I’m encouraged that others think this is a cause worth the investment. I’m confident that we’re building a strong community of thoughtful and curious folks who give each other’s ideas a chance.

At our first meeting, I facilitated the Lean Coffee format since I didn’t want anyone to feel put on the spot to take over something they hadn’t experienced. Since we had 15 other in-person attendees and 3 online folks, this was a much larger group than normal. Although I recognized that groups of this size would normally split, I thought keeping everyone together would be better for cohesiveness.

We did use a simple personal kanban board. Each person had a chance to contribute topics. Due to the size of the group, each person had 3 dots to vote on which topics had priority. We established a 5 minute interval between votes to continue. Then, I added a “mercy kill” rule that after 10 minutes we had to move on to the next topic. I wanted everyone to experience the variety of Lean Coffee and knew that our topics were so complex that they could easily take over the entire time we had to meet. Those topics we still wanted to pursue went into our future meeting backlog.

As a result, we covered all of the topics that had received a vote. When items in the To Do column had an equal number of votes, I picked one to be the next to proceed to the In Progress column. Any topics we had covered sufficiently went into our Done column.

While this execution wasn’t a strict interpretation of Lean Coffee, it was a perfect adaptation to our purposes. The conversations continued after we had officially ended and people are looking forward to getting together again next month. We had lots of leftover pizza and beer, possibly because we were too engaged in the interaction to step away to enjoy the refreshments. All in all, it was a great investment of my time and I look forward to doing this again and again.

Please join us again this coming Thursday for another rousing Lean Coffee! We will have a WebEx available for virtual attendees, so tweet us to let us know you want to join in. See you then! Or on Twitter, Software Testing Club, Facebook, Google+, LinkedIn, etc

Software Testing Club Atlanta’s 1st Lean Coffee topics

  • 7 dots:
  • 5 dots:
    • (4th) Testing in SAFe
  • 3 dots:
    • (2nd) ATDD and/or BDD
    • (2nd) Specification by Example – getting started
    • (3rd) Exploratory testing
    • (5th) Testing in Kanban – its own column? encourages handoffs?
    • (6th) Test Manager Role on Agile Team
    • (7th) How to integrate off-shore testers w/agile teams
    • (8th) Hiring GREAT people – finding testers
    • Logic Flow Analysis and test coverage
  • 2 dots:
    • (3rd) What is breakdown of time/resources for: exploratory/scripted/automated testing (rough %)
    • (9th) Test/programmer pairing – success stories? Does it work?
    • (10th) Testing Meetups near us and around
    • Creating User Acceptance Testing
  • 1 dot:
    • Let’s get speakers! Topics?
    • What do you use to test multiple browsers?
  • No votes:
    • When to Automate?
    • What avenues do people use to find out about testing methods/tools?
    • LAWST Workshop in Atlanta?
    • Developers don’t test (?!!) (What?!!)
    • Test metrics
    • Whole team testing – good idea? How to get it working?
    • Gov’t shutdown & testing

Guest author at AgileConnection

Check out my recent article Eat Your Veggies over at

Claire Moss shares with us a personal story on how using agile methods helped her family with managing meals and groceries. By using techniques like a Big Visible Chart, dinnertime for Moss’s family became less of a chore. Remember, nothing ever goes according to plan, but that’s true for any healthy team.

Here’s the big visible chart that turned our dinnertime struggles around:

Agile will FAIL

The closing keynote at CAST 2013 was Scott Barber and Rob Sabourin describing takeaways from each of the talks of the conference, bringing together many different talks into themes or striking moments. As a speaker, I was on tenterhooks waiting to find out what Scott would say about my talk. It was not what I expected, a moment from before my talk that he described as a “kick to the head” (in a good way):
Scott's Takeaway from my Walking Skeletons talk
He pointed out that I was emphasizing empathizing with people with different experience and perspective, which was important enough to say explicitly before I began my talk. So with that in mind, I want to talk about a foreign perspective I encountered at my other software conference of the year.

At Agile2013, someone taped large sheets of sketch paper to the wall with a large writing prompt:


to which many people replied in various ways during the week. Some of these responses were rebellious, resisting the seeming prophecy of failed agile. Others felt trapped by unresponsive or rigid organization behavior and hierarchy, industry regulation, or even customers. Contributors felt that companies with only a shallow understanding of agile or simply name-only “implementation” had no real difference in the way of working. Culture weighed heavily on the minds of attendees: belief, passion, desire, emotion, infighting, courage, trust, support, motivation, thinking. So people problems were at the heart of most expectations of failure.

To me, the most provocative perspectives I saw on that wall were not focusing on agile but on the demonstrated value delivered through whatever works, focusing on outcomes. Today, a friend pointed out a Mike Cottmeyer article from 2009 that discussed defining value in agile but at the enterprise level in terms of real business outcomes:

As an organization, we know that we need to deliver value as fast as possible… but we can’t figure out how to apply the small team concepts to our particular business problems. That’s why you get the classic “agile will never work here” comments. There is an inherent disconnect between the team level guidance agile methodologies talk about and the bigger concerns your senior executives are struggling with. There is a gap between value at the team level and value at the enterprise level.

Four years later, Agile2013 conference attendees are still wrestling articulating delivery of complex business objectives to business leaders. And while I also struggle with messaging how my work provides value to the enterprise, I’ve never experienced an agile transformation and so it hadn’t occurred to me to wonder whether agile could succeed. It’s always been business-as-usual, in my experience.

The full (transcribed) list from the Agile2013 wall:

  • We think we are “Agile”
  • The concept of “dedicated to one task at a time” is not supported!
  • They won’t change
    • Response: “They”? Maybe this is contributing to the problem
  • Because CEO manages with fear and intimidation
  • … Only focused on changes in development teams; not looking at whole value stream (product ideation & management)
  • No buy-in from the business
  • Duplicitous product owners (two masters)
  • because of our culture
    • Response: √
  • because my customer prefers waterfall…
  • Because the company wears “agile” as a label and yet does nothing to remove the bureaucracy and obstacles teams face daily while trying to implement agile.
    • Response: √
  • We lose trust in each other
  • … Adoption is done because of convenience not because of conviction.
  • We are different
    • Response: … Just like everyone else who has done it.
  • Our egos are bigger & more important than the company goals
  • A re-org will set us back to the beginning, again and again. (weekly)
    • Response: √
  • Of me.
  • …Insufficient support from leadership
    • Response: Totally agree
  • Different part of the biz use different types of agile
  • Deeply hierarchy…. Project leader doesn’t want Agile.
  • my leadership team no longer believes in it 🙁
  • … it’s counterintuitive & hard to practice
  • Because agile is a state of being… NOT doing! Agile is grossly misunderstood… SADLY!
  • … because Agile is not the goal. Agile is simply a MEANS to and END
    • Response: Agree!
  • We only fund CAPITAL projects
  • Because I just think on the consequence not the cause. We should be able to teach the noble truth behind agile methods. Teach that discipline is not a fantasy. If we try hard as a team we can achieve anything. – She Liang
  • My manager has to assign work to the team
  • It does not support SECURE software (ISO27000 or code analyzers)
  • They don’t want to change. & no lean leadership.
  • Too much focus on the mechanics of the process. Not enough on the motivation/passion behind it.
    • Response: +1
  • We have not explained the ‘why’
  • Not everyone on our team understands it.
  • It won’t, because I work at Rackspace! 🙂
  • “Lack of Courage…”
  • We don’t want it badly enough
  • Because I’m writing on this wall & I think it will so it will
  • We can’t show the value
  • “What we do already works!?”
  • Crash at current (complex) business model
  • Jim
  • Strong and growing PMO traditional structure being instituted
  • We don’t think by ourselves. We need to think everyday, every time, everywhere!
    • Response: Agreed.
  • Our culture won’t *change*
    • Response: √

Q: Maybe someone can clarify that business model remark for me? I wasn’t quite sure what that said…

Fresh Perspective

fresh_princeI can’t remember what it was like to start working as a tester. Ten years later, the only impression I have left of that time is voracious learning. So yesterday’s debut of the ISST webinar series focusing on the first 2 weeks on the job as a tester was a good refresher for me.

Ben Kelly gave a description of two distinct new testers and their experiences of adjusting to the expectations for testers. This reminded me of Pradeep’s talk at CAST this year about his “baby shark” new testing trainees. I suppose that shouldn’t surprise me since they’re among the founding members of ISST.

Both emphasized that novices have an advantage: ignorance. While that doesn’t sound like a very positive description, one you might not want to claim for yourself, it resonates with me. Most of my professional progress has been made asking the dumb questions that filled in my ignorance, pointing me in the right direction rather than remaining stagnant.

But ignorance is not enough, merely lacking information one stagnates. Curiosity turns ignorance into action, transforming it into a powerful tool. (I think this is what people refer to as beginner’s mind, though I haven’t studied that concept myself.) Pradeep explains that newbies have a tactical advantage in not having been misled yet. Ben reminds us that while asking questions seems so simple it’s actually deep exploration of context, not just about business content but also about team expectations.

When Pradeep’s freshers (I think I’m using that right, right??) go out into the world to help start-ups with testing, they’re learning multiple contexts. This adds a bit of complexity to the already daunting task of acquiring testing skills. Sounds intimidating, doesn’t it? While these testers get on-the-job training, the start-ups experience the value of a context-driven testing approach focused on providing business value, which shifts from business to business.

Ben and Pradeep emphatically drilled us on providing information in the way the consumers can understand. Knowing that they have multiple audiences, testers must be excellent communicators. As an intuitive person, this intimidates me – and it sounds like other empathic testers may have similar trouble. I took my first stab at messaging about testing with members of my product team since that was most familiar to me. However, test reporting above the product team hasn’t been a big part of my career so far. My primary approach there has been getting to know the end users.

I know this webinar was aimed at less experienced testers, but I’m reminded that I could use a fresh approach myself. Like some (formal) practice in session debrief? Joining forces with sales for product demos? What approaches keep test reporting fresh for you?

Image credit