Category Archives: Experiences

Preparing for Winter

05 Tuesday Nov 2024

Posted by in Context, DevOps, Experiences, Experiments, Reliability

≈ Leave a Comment

Tags

I recently discovered a delightful niche celebration called Fat Bear Week. More than a million people voted for the final contest this year to crown winner Queen Grazer. Leading up to the final vote, many members of the community campaign for their favorite contenders, highlighting their different strengths and achievements. As a newcomer, I appreciate their posts with various kinds of analysis about the bears’ risks and coping strategies as they all try to solve the same problem: readiness for the months ahead.

To begin, park rangers highlight bears for the Fat Bear Week bracket. Some of this has to do with which bears are engaging in the parts of the park that are monitored; after all, this is a participation sport for all the fans. While some fans are engaged months ahead of time, others come to the party at the end for the last week of the season. I’m sure you’ve seen a variety of risk profiles for your applications and your contributors. I like to think of a particular company’s suite of applications as balancing resources with the needs of the whole portfolio as we iterate toward improvement.

We can take lessons from these natural preparations:

  1. Learn from Failure
  2. Prepare for the Unexpected
  3. Prioritize Health

“You take care of what you love, and when you observe it enough you fall in love… the more you connect.” – Charlie Annenberg, Explore.org re: bearcams

Learn from Failure

Year over year, having data to go on helps us to see our continuous improvement, just as it helps long-term bear watchers to see the ongoing story of bears as they survive and thrive. Not all bears survive or thrive, and an analysis of this season’s bear tragedies and conflicts is inherent to studying the brown bears of Katmai National Park and Preserve. Human behaviors like feeding the bears or driving in bear territory can lead to failures for the bears as well as heartache for the people in the park and bearcam watchers. Conflicts among bears are a part of nature and knowing about those aspects of bear life helps people to appreciate the survivors. (Yes, we know bears gonna bear, but it’s still a lot to bear when you see it live.) Despite loss, the community celebrates the successes those bears had and their legacy for the Katmai bears who continue, with a new generation of bears taking over at Brooks Falls this year.

During this emotional outpouring, my first visit to this world of bearcam devotees included hearing some community members wish to preserve the experience of knowing bears for years versus attracting new fans who don’t have that context. Long-term viewers felt that newer viewers didn’t appreciate the history behind the losses so that they might seem trivial. I believe both long-term experience within the context and fresh perspective can bring value to our conversations about what we’re focused on, whether that’s software systems or bears. Hearing what has worked in the past gives me options about how to judge the present situation that intermix with my new ideas as an outsider. I see many of my skills from earlier roles as portable to reliability engineering, and that overlap points me to the alignment of our preparations with the overall goals of teams and the organization. Experts are invaluable in these conversations.

Prepare for the Unexpected

In their chats, interpretive rangers or ranger naturalists “interpret natural and cultural history to help people understand and appreciate the significance of national parks…. with education and interpretation related to the world-famous bearcams.” Watchers can submit questions for experienced professionals to discuss and answer. Reminds you of some remote working knowledge shares you’ve seen, right? Done well, a docent’s remarks can inspire action and bring up different ideas for investigation. While we bearcam viewers at home may not be running experiments with the animals, we’re definitely considering different ways to judge the animals’ weight gain, incorporating the various data sources into our discussions as we cheer our favorite bears. (Terrestrial Lidar?! Yes! Yes! and Yes!) I get similar value from hearing experienced industry colleagues talk about how they have faced problems and the solutions they’ve implemented to address the challenges. Looking for similar risk factors or application characteristics helps me to form experiments when adopting different practices. Will these practices be “best” in a context-free sense or are they optimal for a particular kind of problem that we face (e.g., a peak event)?

For the bears, hibernation season is the time to survive, and all their preparations are tested to the limits. For retail technologists, there are annual events that tend to coincide with other retailers in the industry, e.g., the heavily advertised holiday season. (Did I really go pick the bones of the Halloween crafts right next to aisles of Christmas trees and decor? Yes, yes, I did.) That test of our technology systems and business readiness is most visible during peak business events, when we take extra precautions and think carefully about the unexpected impact issues can have on systems. While we prepare year-round to have our systems stand up to the needs of the market, our routine incorporates seasonal variations designed into our business cycles. We prioritize the most urgent and important work that will support our success.

Prioritize Health

Prioritization. Bears are masters. Limited resources to devote to the crunch time leading up to their goal result in instinctive decision-making. They focus on bulking up at the expense of most everything else, although the mama bears have a juggling act of feeding and protecting cubs as well. As a mama bear myself, I identify with that struggle to focus while also staying aware of my surroundings and changing circumstances to be ready to act, although I’m not likely to be roaring in the face of a competitor like Queen Grazer would do. We develop instincts about our systems over time through experience in running them and familiarity with the people involved.

May we collaborate effectively to have a happily boring (read: peak business as usual) season of surviving and thriving!

And if you love brown bears, contribute to supporting them in Katmai!

Work Horde, Play Horde

02 Monday Sep 2019

Posted by in Coaching, DeliverAgile2018, Events, Experiences, Experiments, Mob Programming, Protip, Publications, Soft Skills, Speaking

≈ Leave a Comment

I recently hosted a Magic-the-Gathering-themed tween party for 8 players.

Yes, you read that correctly. 8 players in a format I later learned is called Free-for-All (a.k.a. Circle). Little did I know that most MTG games were smaller, with an “epic” game being maybe 6 players… 🤦

While my husband did some excellent turn-based coaching for the new players – about half of the assembled – I noticed something essential was wrong. The kids were disengaged from the game unless it was their turn to play. Considering they’ve been rabid Pokémon fans, I couldn’t understand how they could completely check-out from a “grown up” monster beatdown game…

Then it dawned on me: the turn rotation was too long. The kids had enough time between turns to be restless from the sugaring-up and general high energy of being together outside of school.

This distraction is the same issue that I’ve seen with attempts at mob programming!

For any reasonably sized team (let’s assume <= “2 pizzas”) trying to mob program, short turns are essential. In fact, I’m not sure that group size figures into the turn duration calculation – short turns are just better!

How long is too long? For me, 15 minutes! Bias yourself to less than 10 minutes, preferably 2-5 minute turns. I’m aware that at-a-glance this feels absurd, but let me explain.

The basics of mob programming are 3+ people programming together at a single computer with 1 person directing the current activity, 1 person hands-on executing the current activity, and 1 person observing/commenting/contributing from the “mob” crowd seated around the computer. (In some descriptions, the “mob” may also be considered as part of directing the activity, but 1 person makes the decision about what to do/try next, so I prefer to differentiate between these roles.) Unlike strong-style paired programming, these roles are insufficient to be mob programming: for a mob, you must also have rotation!

As “circus performers” (a.k.a. mob programming facilitators) for Bryan & Bill’s Three-Ring Design Circus at deliver:Agile 2018, my pair Tim Ottinger and I instituted a 5 minute rotation schedule for our mob of conference session attendees (read: strangers). Our task was test-driven development (TDD) and refactoring of a sample programming project.

Short rotations encouraged:

  • low barrier-to-entry experimentation with TDD and mobbing
  • selecting and trying an idea quickly
  • refining communication patterns
  • collective ownership of goals
  • fast feedback

Tim and I were a bit more merciful with our 5 minute rotations in that we encouraged participants to continue the execution of the previous driver where another “circus performer” insisted on a fresh start (read: deleting code) when TDD automation wasn’t passing/green at the end of a 2 minute rotation (the hard-core strategy of one of our other performers). So much excitement!

In the workplace, over the years, I have participated in pseudo-mobs wherein a single programmer or a pair of programmers consult another team member on particularly challenging aspect of a programming problem. Often, this results in another programming team member chiming in with insight or advice and now we have an amorphous gathering around a single programming work station where the work is being implemented. This is even more likely when the consulted team member is also paired programming (i.e. 2+ pairs collaborating on a complex issue in the code).

While pseudo-mobs definitely help with resolving an issue, we miss out on some of the benefits of the mob structure:

  • explicit statements of intent through navigator-driver pattern
  • everyone having hands-on time implementing a solution
  • everyone directly participating in the decision-making and experimentation
  • single piece flow / avoiding merge conflicts (since only 1 unit of work in-progress)
  • novice or new team members developing shared understanding and receiving training opportunities from the explicit exchange of multiple points of view and potential solutions

Now back to the Magic game! Upon reflection, how would I have changed the game play to optimize for faster turns/better rotation?

The common wisdom seems to be smaller groups for quicker decision-making and turn progression, e.g. 2 player (1v1) games or team play (e.g. 2-headed giant, emperor).

I could also imagine a simplification of rules for younger/newer players to lower the barrier to entry…

Upon further investigation, I discovered a co-operative format for MTG: Horde Magic!

All the players form a group working to defeat an automated “horde” deck. The team members all take their turn together to attack and block. (This reminds me a lot of the mob programming format with a product team assembled to “defeat” a difficult software problem.)

In Horde Magic, if some aspect of game-play isn’t fun or isn’t working well within the rules, the team members come to a consensus as to what works best for them. (The mob can iterate on their working agreements as they work through the problem in order to work more effectively together.)

Given what I know so far, I’m looking forward to trying some new things, both at work and at play. Having a good mobbing experience takes a bit of planning and some skillful facilitation, but it’s the game for everyone!

Keep your options open

27 Wednesday Feb 2019

Posted by in Automation, DevOps, Experiences, Training, Uncategorized, Unconference, Volunteering

≈ Leave a Comment

Tags

, , , , , ,

In DevOps, there’s a pervasive theme of automating toil, which many would say contains all of testing. I’m just gonna say it: I come from the testing community. We’re people who constantly look for things we haven’t seen yet, who collaborate across roles, who explore the unknown, and who care about doing the right thing. Does that characterization surprise you? Yes, testing is complex enough to be a viable career and not just a thing we do until we can script it for a computer to execute.

So when I reached my limit of “X is going to kill Y” (in this case, DevOps and the testing profession), I finally went for it and joined a DevOps team as an agile tester. I wanted to see for myself that DevOps was the cultural sea change that would make my job role obsolete. If giving up my vocation was the right thing to do, I wanted to be ready with a deep understanding of the value of the new practices and to embrace the mindset shift. I wanted to be ready to bring others along with me on my voyage.

Free electron
Free yourself, electron!

When I attended DevOpsDays Atlanta 2018, I didn’t know what the community would be like. Sure, I’d helped to review their proposals as part of the program committee, but who would I meet who would change me for the better? It was my first time hanging out at an event for people who might identify as “operators” instead of just “developers.” Would they welcome me, a person without any operations background?

Inclusive collaboration wasn’t just the theme of the conference: attendees and speakers shared their authentic selves and wholly embraced it.

Although my discernment of future direction is ongoing, I see as much diversity of thought in DevOps as in agile. The afternoon unconference was my favorite experience! This format is less structured, as you might expect from the name, allowing for free-flowing conversations that address the most current burning questions of the attendees. I found operators wrestle with similar collaboration conundrums. My questions and concerns found ready listeners and new proposed solutions (in addition to new questions!). This diversity of thought helped to open up my perspective on what is possible.

Collaboration with people from diverse backgrounds and viewpoints is a competitive edge. It’s also the right thing to do. We want to keep our professional and organizational options open. Distinct perspectives provide a greater ability to handle the breadth of competitive situations we face. We need new voices and different perspectives to make change possible.

I’m particularly excited about the possibilities this year in bringing 3 communities together! Whether you’re someone looking to refine your role in the context of today’s accelerating software delivery cycles or just curious about how much DevOps, serverless, and (Wardley) mapping enthusiasts have in common, this year’s event is for you!

Our call for proposals ends February 28th (that’s today, procrastinators!), so there’s still time to share the unique experiences that only you can bring, whether through a 30 minute session or a 5 minute ignite talk. If you prefer to attend and then propose topics on the fly like I do, the afternoon unconference provides that space for emergent value.

Let me assure you that constant learning isn’t easy! Change is hard – and worth it. I expect the supportive environment I’ll find at DevOpsDays Atlanta / serverless days Atlanta 2019 / Map Camp 2019 is exactly what I need to just keep swimming. We could all use some help staying afloat.

Agile Testing Days USA links

27 Wednesday Jun 2018

Posted by in Agile, Agile Testing Days USA, Approaches, Coaching, Context, Experiences, Experiments, Exploratory Testing, Podcast, Publications, Soft Skills, Speaking, Training

≈ Leave a Comment

Here are some resources we’re using in my Agile Testing Days USA workshop Refactoring Test Collaboration

Slides

Abstract

Collective ownership for testing starts with understanding testing. Rework your team dynamics to evolve past duplication and improve performance through whole team testing. Take home practical patterns for improving your team’s collaboration on testing. Because teams who own testing have more confidence in the customer value of their results.

As the Pragmatic Programmers say, “refactoring is an activity that needs to be undertaken slowly, deliberately, and carefully,” so how do we begin? In this session, we will experience the complex interactions of an agile team focused on demonstrating customer value by answering a series a questions:

  • Where do testers get their ideas?
  • How are you planning to accomplish this proposed testing, tester?
  • Why not automate all the things?
  • Who is going to do this manual testing and how does it work?
  • How do we know whether we’re testing the right things?

Build your own list of TODOs from these various practical collaboration approaches and begin deduping your team’s testing for a better first day back at the office.

Key-Learning

  • Approaches to handle objections to executing the testing work
  • Ways to mentor test helpers, including pairing
  • Investing in testing the team believes in
  • Understand how other team members have been testing the work so far
  • Advising on opportunities to inject test thinking into all of the team activities, from story writing through to unit testing, to make the system more testable

Resources

Refactoring

Collaboration + failing at collaboration

WHOSE testing skills + Exploratory testing + Elisabeth Hendrickson’s Test Heuristics Cheat Sheet [PDF] + book Explore It!

Agile Manifesto

Walking Skeletons, Butterflies, & Islands + my blog post elaborating on the conference

Big Visible Testing + my blog post elaborating on the presentation

Testing pyramid + critique of the testing pyramid/alternatives

Extreme programming lifecycle

eBook: Katrina Clokie’s A Practical Guide to Testing in DevOps + Role mapping

Westrum model + organizational culture & safety

Linda Rising’s change patterns & books on Fearless Change

Deployment pipeline

High Performance Practices [PDF] + book Accelerate

Continuous Testing

Empathy-Driven Development + empathy practices

Many interactive aspects of my workshop were inspired by Sharon Bowman’s book Training From the Back of the Room

facilitation book Collaboration Explained

metrics book Measuring and managing performance in organizations

book Testing Extreme Programming + some follow-up thoughts

Soon to come! Claire Moss on Let’s Talk About Tests, Baby podcast

deliver:Agile2018 Links

02 Wednesday May 2018

Posted by in Agile, Coaching, DeliverAgile2018, Design, Experiences, Experiments, Exploratory Testing, Publications, Speaking, Training

≈ Leave a Comment

Here are the links we’re using in my deliver:Agile2018 workshop Beyond Waste: Exploratory Testing Charters in Action

Slides

Abstract:
Think manual testing is waste? Think again! If you’re not learning when you’re testing, you’re doing it wrong! People exploring systems can be your best defense against unknown problems and your greatest way of finding unexpected opportunities.
While automation is well adapted for repeating the same thing over and over again, human beings are great at doing things differently.
Doing is not enough! We need to think during our review and examination processes to improve outcomes. How do we design manual exploration to provide value in today’s fast-moving development culture?
Come to this workshop for hands-on experience with the full lifecycle of exploratory testing charters.

Learning Outcomes:

  • Structuring manual exploratory testing for transparency
  • Charter guidance during test execution
  • Outcomes of exploratory testing
  • Value delivery through debrief of testing session

Elisabeth Hendrickson’s Test Heuristics Cheat Sheet [PDF]

Which world do you prefer?

UI: https://xkpasswd.net/

UI: http://correcthorsebatterystaple.net

UI: http://password.optionfactory.net/

NodeJS: https://github.com/fardog/node-xkcd-password

Ruby: https://github.com/rasmus-storjohann/xkcdpass

Python: https://github.com/redacted/XKCD-password-generator

Shell: https://github.com/danielmcgraw/xkcdpass

PHP: https://github.com/cesarzavala/xkcd

Perl: https://github.com/CS-CLUB/xkcd-936

Organizing meetups

03 Friday Mar 2017

Posted by in Approaches, Context, Experiences, Experiments, Lean Coffee, Protip, Retrospective, Social media, Soft Skills, Software Testing Club Atlanta, Speaking, Training, Unconference, Volunteering

≈ Leave a Comment

Announcing Ministry of Test Atlanta

Last fall was the last of our Software Testing Atlanta Conference (STAC) events. An attendee at my Intentional Learning Workshop chatted with me afterward. I mentioned that I have been a local meetup organizer and have struggled with how much control to retain. My attendee urged me to give the meetup back to the community and I have been pondering that ever since.

I’ve been the primary organizer of the Software Testing Club Atlanta meetup since we began as an affiliate of the UK-based Software Testing Club in October 2013. My charter has always been to serve and develop the local testing community including connecting it with the global virtual community. Not everyone agreed about including digital attendees, but I am willing to experience the friction of a virtual meeting to help people to attend who otherwise would not have a chance. Inclusion matters to me.

I also prefer small groups and experiential events/activities that Justin talks about. I have never had a goal of increasing the size of our meetup beyond what a single facilitator could manage in a workshop.

STAC was just a bigger extension of the meetup for me. I always wanted to reach more people in the local community, so putting together a conference focused on my geographic region was a great chance to bring new local voices to the fore. I never wanted it to be a big formal event, so I’m working on an ATL software testing unconference for the fall: shortSTAC. More on that to come!

This has been an awesome ride over the last 3 years, but we’re re-branding and branching out into our very own Meetup now known as Ministry of Test Atlanta!

Please join us to keep up with our events!

 

As part of our reboot, I wanted to share some thoughts on what challenges a meetup organizer confronts every month and why monthly events are so difficult to sustain!

Meetups are tough for reasons

 

1. Location, location, location!

People interested in testing are spread out across ATL and traffic suuuuuucks. Plus, I have no budget, so someone has to be willing to host for free or sponsor the venue fee $$. I don’t want to hold the meetup only in one part of the city since that alienates interested test enthusiasts. Proximity to public transit is something I’m not sure matters, but it would make the meetup more accessible to more testers.

Over the past 3 years, we’ve had completely different crowds depending on which part of the city we chose. I preferred to rotate locations to give everyone some opportunity to attend, even though that introduced uncertainty that probably negatively affected attendance… It’s impossible to make the “right” choice for everyone who *might* attend…

Anyway, I work at VersionOne now and that means I can host, so that’s one variable taken care of!

2. Scheduling

We hold meetings on weeknights assuming that people are more likely to do work-related things on workdays – and would be more reluctant to give up their weekend fun time to work-ish things. Getting all of the stars aligned to schedule these meetups monthly *and* give enough time for people to RSVP and then work out the logistics of showing up… Timing is hard.

Since we tend to meet after work, providing food and drink encourages people to attend, but that’s not free… and I have no budget.

3. Funding

Food and drink cost $$ – someone has to be willing to sponsor the foodz, and drink

Possible sources of funding:

4. Content

Not everyone wants to present or run a workshop or host a round table or … yeah. People will show up but may not want to provide content. I have to find a willing volunteer to do it for free or someone to sponsor a fee $$.

We infrequently have presentations. Most of our events are workshops or rountables or some sort of interactive experience. My go-to is Lean Coffee since it lowers the barrier to getting groups together and provides value to attendees every time.

I’m definitely interested in scheduling joint events with other Atlanta meetups in the future.

5. Publicity

How do people find out about meetings? I do the social media management, but I have no budget so … mostly word of mouth otherwise? Maybe chat rooms?

6. Audience

I assume that most of the people who want to come to a testing meetup are testers, but not all test enthusiasts are testers. We’ve had development-types show up, so I want to keep it open and inclusive.

7. Viewpoint advocated

I refuse to insist people agree with me. I won’t call it a context-driven testing meetup or an agile testing [PDF] meetup because I want to welcome people who subscribe to other philosophies of testing. That said, I also don’t want vendor talks (and yes I work for a vendor now). This group is for engaging with ideas focusing on and around testing, not for mind-clubbing or selling or exchanging business cards. Active participation is expected and encouraged.

8. Volunteers

Organizing: While I have always had a core group of enthusiastic participants, I’ve never had a formal organizing committee. Being a one-woman-show most of the time is pretty exhausting, y’all. The meetup consumed lots of my free time. I made my professional hobby the primary thing I did for fun outside of the office for years. Um… not a sustainable model. I do not recommend it. At the same time, working with others means compromise, so consider carefully the tradeoffs and find allies who believe in your mission.

Presenting: Members of my core group have all helped out with content for the meetup – for which I am eternally grateful! I’ve also encouraged other local aspiring presenters to practice on us. Occasionally, someone I know from the wider testing community is in town and joins us to share their wit and wisdom. I resisted presenting at my own event for a long long time… until I needed content LOL

Coaching and Coffee

24 Tuesday May 2016

Posted by in Approaches, Coaching, Experiences, Experiments, Protip, Soft Skills, Training

≈ Leave a Comment

coffee-coachOne morning, my office had a fancy coffee machine delivered. The machine was fancy enough that we had training sessions to learn how to use it. The machine’s controls involved a few pre-programmed settings for common usage scenarios. Not being a coffee drinker, I didn’t appreciate the intricacies of preparing a morning cup, so while I was interested in the training it was not particularly relevant for me. I just wanted to know where to get the hot water to brew my tea.

Then, we had a local barista Joseph Yancey join us for a morning of coffee coaching. It was his day off, but he loves the artistic aspects of preparing coffee and wanted to share that with coffee lovers. The coffee machine was still somewhat intimidating to me since I didn’t know how to judge the results of the preparation process. Out of curiosity, I hung around to listen to what the barista had to say.

Co-workers arrived at the office and were ready to start their day. They joined us in the break room and gathered around our visitor. Instead of expounding about the principles of great coffee and the brews and mixtures he preferred, Joseph focused on helping individuals to achieve their goals.

As each person explained the kind of outcome they were looking for, he was very patient in coaching. He noticed the intimidation of trying something out of the ordinary and reinforced the idea that no one should be concerned about failing to produce exactly what they hoped for. Instead, he emphasized making better and better approximations of the desired result to accomplish incremental progress. This created a safe space for individuals to develop new skills.

Each person explained what they wanted and he told them how to refine their techniques. He showed them motions with his gestures and posture as a model but he didn’t take over. Each pair of hands became surer by trying for themselves the motions and mixing. He paired with each participant and brought attention to key moments and opportunities during the process without talking down to anyone. Rather than doing it for them, as he expertly would during his day job, he coached them into greater competence and self-reliance.

I noticed his consummate skill in interpersonal interactions and asked him about it. He said that his love for his craft motivated him to help others to greater mastery. When I mentioned that I wasn’t in his core demographic (as a tea drinker), he was willing to tackle that problem as well, teaching me how to judge the heat of the water produced by an electronic kettle so that I could pair it with the various mixtures with more demanding brewing precision. Even I, an edge case, benefited from Joseph’s enthusiasm and understanding.

Now that’s a coaching experience to start your day off right.

Baby Steps

19 Thursday Mar 2015

Posted by in Agile, Approaches, Design, Experiences, Experiments, Personas

≈ Leave a Comment

Leo: Bob, there is a ground-breaking new book, that has just come out. Now, not everything in this book, of course, applies to you, but I’m sure that you can see when you see the title, exactly how it could help.
Bob: Baby Steps?
Leo: It means setting small reasonable goals for yourself one day at a time. One tiny step at a time.

– What About Bob?

My friend is having her first babies. She shared her wonderful plans for the nursery with us and I saw an opportunity to create something special and new for the occasion.

I’ve blogged before about my crafting habits but not about my design process. Given the reference point of the nursery that inspired my mom-to-be friend, I immediately reached out to a more experienced collaborator, a friend who frequently scrapbooks with me.

We riffed on ideas until we landed on one that intrigued us, and we started to develop it more through discussion. However, given our short timeline, since we intended to have the gift ready for the baby shower, I started to create initial prototypes of the components we planned to combine for our project. Using scrap paper, I cut out the shape that had inspired us the most as a reference point. I made several variations that preserved the color palette we wanted to use, so that even those early attempts would provide better information about the final product.

I sent pictures of these prototypes to my friend so that we could evaluate them together before I moved on to the next small piece of work. She had great ideas for coordinating next steps, so I continued to design and construct independent components, evaluating each as I went.

Once I had gathered several together, I called my husband over to provide a second opinion since he is very familiar with the intended recipients of the gift. He liked what he saw and offered suggestions for additional enhancements that I loved – but I hesitated. While I was in love with my design, would our friends like it?

Having invested this much time and effort into the design, initial construction, and overall style, I was loathe to give up any part of my vision. Then, I reminded myself that while I was spending joyful hours creating this work of art, our friends would spend years in the nursery with their children. No matter what I thought of my design, I had to be ready to kill my darlings. I picked up the phone and made the call.

Our friends agreed to take a look at the in-progress photos, to confer privately, and then to get back in touch with us. To my delight, they loved what they saw! Their vision for the nursery matched our vision for the gift. I breathed a sigh of relief.

Armed with this early feedback, I felt more confident about moving on to additional design and implementation. However, an unexpected illness kept my friend from being able to collaborate, and our work fell behind schedule. Not wanting to show up empty-handed to the party, despite knowing how welcome and appreciated I would be, I put together a smaller sample of our project as well as the latest work-in-progress photos of the whole.

At the party, I revealed one of the most recent developments to the excited couple. Other guests brought lovely gifts, from necessary supplies to handmade blankets. We enjoyed the serendipity of another decor gift perfectly coordinating with our project! The nursery is coming together, one baby step at a time.

While we weren’t able to deliver everything we hoped at the time we intended, we delivered something valuable as early as possible with the knowledge that the mom’s “delivery date” milestone is a bit farther down the road – the only delivery in our project that won’t be early and often.

Perception and Certainty

27 Friday Feb 2015

Posted by in Approaches, Context, Design, Experiences, Experiments, Soft Skills, Testing Humor, Training

≈ Leave a Comment

A funny thing happened today at work. I found out that some of my colleagues literally see things differently. Many of us found ourselves surprised by what others perceived to be true about something as simple as an image. We were swept up in #dressgate: a raging internet controversy about a photo of a dress and its colors.

I’m on Team Blue and Black. However, I wanted to see how the other half lives. I tried various ways to see white and gold: viewing the image on different devices, changing screen brightness, angling the screen, walking around in different ambient light. The various experiments all produced the same results. Trusting my perceptions, I could not give any credence to the perspective that the dress was a different pair of colors, despite seeing many online posts to that effect.

I mentioned this to my team at work, only to discover that there were others who had no idea anyone disagreed with them. As a member of Team White and Gold, my team’s designer was surprised to hear there was a Team Blue and Black – as surprised as I was. 🙂 I couldn’t help wondering whether she was expecting a covert camera to emerge as part of some elaborate prank.

Fortunately, working with designers means having deeper organizational knowledge about colors. By the time lunch rolled around, another colleague had created an online tool for experimentation with the image to see for ourselves how image manipulation would change perception. Another designer mentioned that he had sampled the original image to identify the colors and then created swatches of the colors perceived by others to overlay the image in order to show both positions contrasted with each other, explaining about the impact of shadows and subtle colorblindness.

Designers FTW!

Designers FTW!

Then, he suggested another avenue of investigation: flash blindness. In flash blindness, a bright light bleaches (oversaturates) the retinal pigment resulting in sudden vision loss that doesn’t immediately return to normal, but it usually wears off gradually. So my team devised an experiment to expose our designer’s eyes to a bright white lightsource: a blank page on a screen. When she quickly switched from the bright white background to the original dress image, she was able to see blue and black coloration. However, after a few moments, when she glanced at the dress image again, her retinas had recovered and she saw the original white and gold pigments. This was consistent with reports from other online posters who mentioned scrolling down the page and then being able to see different colors. This transient state seemed to be a source of great consternation and some panic.

While this was a fun way to spend our lunch hour, it was also a great opportunity to practice some of the problem-solving skills I learned at last year’s Problem Solving Leadership workshop:

  • Experimenting to gather information – Although I was not able to see the white and gold version of the dress without manipulating the image, I learned new ways that didn’t work.
  • Perceptions, What’s true for you – I felt quite certain about the stability my own perceptions after looking at them from various angles
  • Watch how other people are behaving – While I thought it was quite surprising that many others had such completely different perceptions, I did not assume they were wrong just because I couldn’t observe the same things.
  • Be cautious about not noticing – I gave others the benefit of the doubt knowing that I can bias myself to ignore information sometimes.
  • How to take in info – I looked for a variety of sources of information about the disparate points of view to obtain a balanced set of data.
  • Resisting information – I paid attention to reports of heated arguments between people from the different viewpoints, noticing the emotion involved in what seemed like a purely factual question.
  • Motives (test interpretation, seek intent) – I asked two observers from Team White and Gold questions since they could see what I could not
  • Reading minds – I tired not to assume that anyone was punking me or simply being ornery but instead was open to the possibility of being wrong.
  • Style vs intent (make more congruent) – Rather than trying to convince anyone of my point of view, I listened to their experiences and observed their learning process.
  • Social structures – It was interesting to see that even within the design group there were opposing assessments of the information. I also saw how team members collaborated rather than confronted each other when trying to understand where each was coming from.
  • How do you get people to recognize what you saw? – I waited for an opportunity for them to experience it directly and shared the information that I had so the other team members could judge for themselves, now that they had more to work data
  • Show you care by speaking up – I could have ignored people who didn’t agree with me, dismissing their viewpoint as simply wrong. However, engaging in dialogue was a great team-building experience and helped to establish more common understanding.
  • Reactions – By giving myself a charter of observing others’ behavior, thought processes, and evidence, I was better able to empathize with what was a shocking experience from their point of view.
  • Eyes open! Use your senses – I took suggestions from the designers about resources for assessing color perception and did not assume that I could gather unbiased information. In the end, I know more about myself than I did when this silly discussion started.
  • Learn from others – I certainly know more about color, perception, troubleshooting, experimentation, and these particular colleagues than I did before I posted the question “What color is this dress?” so I call today a win. 🙂
  • Aaaaand I couldn’t help trolling just a little bit by “wearing the colors” today…

Blue-Black or White-Gold?

Blue-Black or White-Gold?

 

March 2014 Software Testing Club Atlanta meetup

27 Thursday Feb 2014

Posted by in Approaches, Context, Experiences, Software Testing Club Atlanta, Speaking

≈ Leave a Comment

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 testthisblog.com every week since.

When Meetup.com 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!)