Now I’ve been working alongside many customer proxy team members (e.g. business analyst, product owner, product manager) over the years. I’ve learned how to create testable, executable, deliverable user stories in a real-world setting. I wasn’t going into this talk blind. I just haven’t always focused on the Product role.

This time, I looked at the role with the mindset of what it would take for me to check all the boxes in the “good” list. As each slide appeared, my list of TODOs lengthened. I started to feel overwhelmed by the number of things I wanted to improve…

“How you doin’, honey?” “Do I have to answer?!?”

I walked out of that talk thinking I’m not sure I want to sign up for this epic journey. The vision of the idyllic end state was more daunting than inspiring. How could I possibly succeed at this enormous task? Would I want to sign up for that? My initial reaction was no! How could I take on all the technical debt of stretching into a new role like Product? How long would the roadmap to “good” take?

Analysis

When I evaluate things off the cuff, I often consider good-bad-indifferent. Maybe knowing what “good” and “bad” look like wasn’t helping me. I knew I didn’t want to be merely “indifferent”… maybe what I really wanted to know was this:

What does a minimum viable product manager look like?

One of my big takeaways from Problem Solving Leadership (PSL) with the late, great Jerry Weinberg was limiting work in process (WIP) or “one thing at a time” (as close to single piece flow as possible) improves effectiveness. If I take that approach to a PO/PM role, I’m afraid that I would completely fail. So I will reduce the practices to as few as I possibly can without completely losing the value of the role. I want only the *critical* path skills or capabilities! Everything else can be delegated or collectively owned or done without. So what can I discard?

In this thought experiment, I’m proposing finding the least possible investment in each essential aspect of the PO/PM role that would move from bad past merely indifferent to viable (but only just!). I needed to reduce my expectations! If I allow minimum viable to rest somewhere in my default scale, then it fits between indifferent and good. That means I deliberately do *not* attempt to inject all of the good practices at once. So let’s revisit the axes of expertise and the lists of behaviors that are good and bad…

Style of leadership

Minimum viable: leads by example (models behaviors for others without trying to modify their behaviors) + doesn’t worry about respect + consultative decisions + experiments/loosely decides + sometimes available to the team but not constantly + flexible + defaults to already available metrics

For me, this one slides a bit too far toward indifferent… I’m not sure how little I could care about customers and still get away with being acceptable at PO/PM…

Relationship with engineers

Minimum viable: physically co-locates when convenient + T-shaped when it comes to the technical domain (i.e. aware but not trying to develop that skill as an individual contributor) + attends standup + shares business/customer/user information at least at the beginning of every epic + champion for the product & trusts everyone on the team to protect their own time

Approach to continuous improvement

Minimum viable: default timebox + takes on at most 1 action item from retrospective, just like everyone else + plans on an ad hoc/as needed basis (pull system) allowing engineers to manage the flow of work to match their productivity + prioritizes necessary work to deliver value regardless of what it’s called (bug, chore, enhancement, etc)

Product lifecycle perspective

Minimum viable: tweaks customer onboarding in a small way to improve each time + cares about whole cross-functional team (agile, DevOps, etc) + asks questions about impact of changes + allows lack of value in an existing feature to bubble up over time

Sourcing backlog items

Minimum viable: occasionally talks to customers + cares about whole cross-functional team (including Support) + backlog is open to whole team to add items that can be prioritized + intake system emerges + tactical prioritization

I do have twinges about the lack of strategy here, so I guess I’m looking at this part of minimum viable Product *Owner* (i.e. the mid-range focus that Richard points out in his 10th slide).

Decomposing work

Minimum viable: progressive elaboration (i.e. I need to know details when it’s near term work and not before) + thin vertical slices and willing to leave “viable” to the next slice in order to get a tracer bullet sooner + trusts the team to monitor the duration of their work & to self-organize to remove dependencies (including modifying story slicing)

Running through a sprint

Minimum viable: doesn’t worry about timeboxes (kanban/flow/continuous/whatever) + focus on outcome of each piece of work (explores delivered value) + releases after acceptance (maybe this is just continuous delivery instead of continuous deployment, depends on business context)

Meeting involvement

Minimum viable: collaborates with team members to plan as needed (small things more often) + participates in retrospectives + ongoing self-study of PO/PM

Approach to roadmap

Minimum viable: priorities segmented by theme + roadmap includes past delivery/recent accomplishments + adjusts communication as needed/updates for new info + flexible timeline in a living document + published roadmap accessible to all stakeholders on self-serve basis

Surveying/user testing – chat program that both team & user can access

Analytics – NPS score informally collected from customer conversation

Product visioning – I think this goes in with Roadmap for me?

So I’ll agree that the PO/PM role is critical and necessary. I would like for creative problem solvers to fill the role – and to be fulfilled by the role! In order for that to be viable, for people to grow into a Product role, there needs to be education on how to begin – and it can’t be spring-fully-formed-from-the-head-of-Zeus! Christening someone PO/PM doesn’t endow them with sudden wisdom and insight. Skill takes time to develop.

Set realistic expectations for beginners. Help teams to welcome people to grow in the role by offering both challenge and support from all the team members. As with any team need, the agile team has collective ownership to solve the problem, not relying on a single point of failure in the role specialist. Having a beginner PO/PM is an excellent time to reinforce that!

If I were a Product Manger, I would definitely prefer to be a full-featured representative of that specialization! However, I encourage you to revisit Richard’s presentation and do your own decomposition of the Product role. What is absolutely essential? What can you do without?

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

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.

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!

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:

donations from individual attendees

local sponsors (probably companies)

I’ll have to check on company budget to see whether I can do pizza & sodas every time but I know I can do it sometimes.

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?

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

One 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.

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.

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.

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.

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…

My 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.

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.

TMI

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.

Motivation

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.

Training through play

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.

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!

Takeaways

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

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.

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:

Read. Blogs, books. Or even watching videos and listening to podcasts. (I know not everyone is a visual learner.)