As a Constellation We Shine: Mentorship Through the Lens of Shine Theory with Sophia McKeever (A PNSQC Live Blog)

The traditional view of mentorship often paints a one-sided picture—an experienced mentor guiding a mentee, offering advice, and providing support. What if mentorship could be something more? In Sophia McKeever’s talk, “As a Constellation We Shine,” she explores how mentorship, when approached through the principles of Shine Theory, becomes a powerful two-way relationship where both mentor and mentee grow and thrive together.

At its core, mentorship is about growth. But too often, we think of that growth as a one-way transfer of knowledge, with the mentor imparting wisdom to a less experienced mentee. Shine Theory transforms this into a mutual exchange of knowledge, energy, and growth.

Shine Theory, coined by Aminatou Sow and Ann Friedman, is the idea that “I don’t shine if you don’t shine.” In the context of mentorship, this means that both the mentor and the mentee invest in each other’s success. By supporting one another, both individuals flourish, creating a "constellation" of talent, insight, and progress that benefits not just the participants but their entire community.

When mentors and mentees mutually invest in each other, their relationship evolves into something far more enriching than a simple exchange of information. Shine Theory encourages both parties to approach the relationship with empathy and intent, focusing on how they can elevate one another.

For example, a mentor may share technical expertise and career advice, while the mentee offers fresh perspectives, creativity, and a deeper understanding of new technologies. Reciprocity ensures that both parties benefit, no matter their level of experience or their role within the industry.

Sophia shares several anecdotes of her own journey as a testament to the power of mutual investment. A self-taught SDET, she has navigated a dynamic career in tech, moving from customer service to key roles at Microsoft,  Apple, and now at Pokemon. Along the way, she has found that her most rewarding mentorship experiences were those where she could both teach and learn, growing alongside her mentees as they collaborated and supported one another.

When mentorship is approached through the lens of Shine Theory, it becomes more than just career development—it becomes a source of mutual enrichment and excitement. Sophia highlights several key ways Shine Theory can elevate mentorship:

Fostering a Growth Mindset: Both mentor and mentee approach the relationship with the mindset that they can learn from each other. This creates a more dynamic and creative exchange of ideas.

Building Empathy: Mentorship based on Shine Theory encourages empathy, as both individuals invest emotionally in the other’s success. This empathy fosters deeper connections and a stronger sense of community.

Celebrating Mutual Wins: When one person shines, both shine. Mentorship becomes less about individual achievements and more about shared success, creating a supportive environment where both mentor and mentee can thrive.

Breaking Down Hierarchies: Shine Theory shifts the traditional power dynamic of mentorship, making it less about hierarchy and more about collaboration. It doesn’t matter if one person has more experience or a higher title—both are equals in the relationship, learning and growing together.

Mentorship isn’t just about guiding someone along their career path. It’s about "creating a constellation", where both mentor and mentee shine together, contributing to each other’s success and elevating their collective potential. In today’s fast-paced tech world, where innovation and growth often come from unexpected places, this approach to mentorship is more relevant than ever. By embracing Shine Theory, mentors and mentees can build meaningful, two-way relationships that not only enhance their individual careers but also help to develop a more inclusive, supportive community.

Mistakes I Made So You Don’t Have To: Lessons in Mentorship with Rachel Kibler (A PNSQC Live Blog)

I have known Rachel for several years so it was quite fun to sit in on this session and hear about struggles I recognized all to well. I have tried training testers over the years, some I've been successful with, others not so much. When a new tester comes along quickly, seems to get it, and digs testing, that's the ultimate feeling (well, *an* ultimate feeling). 

However, as Rachel points out, it’s also full of potential missteps, and as she said clearly at the beginning, "Believe me, I’ve made plenty!" This was a candid and honest reflection of what it takes to be a mentor and help others who are interested in becoming testers, as well as those who may not really want to become testers, but we mentor them anyway.

We can sum this whole session up really quickly with "Learning from our mistakes is what makes us better mentors—and better humans"... but what's the fun in that ;)?

Mistake 1: One-Size-Fits-All Training Doesn’t Work

There is no single, ideal method to teach testing that would work for everyone. Rachel had clear plans and expected to get consistent results. However, "people are not vending machines". You can’t just input the same words and expect identical outcomes. Each person learns differently, has different experiences, and responds to unique challenges.

Mistake 2: Setting the Wrong Challenges

It's possible to give team members tasks that are either too difficult or too easy, failing to gauge their current abilities. The result? Either they are overwhelmed and lost confidence, or they felt under-challenged and disengaged. Tailoring challenges to a trainee’s current skill level not only builds their confidence but also keeps them engaged and motivated. As mentors, our role is to provide enough support to help them succeed while still pushing them to grow.

Mistake 3: Don't Forget the Human Element

At the end of the day, we’re working with humans. Rachel’s talk highlights the importance of remembering that training isn’t just about passing on technical knowledge—it’s about building relationships.  Everyone has unique needs, emotions, and motivations. By focusing on the human element, we can create an environment where people feel supported and valued, making them more likely to succeed.

Mistake 4: Not Embracing Mistakes as Learning Opportunities

Mistakes are opportunities to learn. Mistakes aren’t failures—they’re stepping stones. Whether it’s a trainee misunderstanding a concept or a mentor misjudging a situation, these moments are chances to grow. They teach us humility, patience, and resilience.

Rachel’s talk is a reminder that no one is a perfect mentor right out of the gate. The process of becoming a great mentor is filled with trial and error, reflection, and growth. Also, Imposter Syndrome is very real and it can be a doozy to overcome.  Ultimately, the key takeaway is this: mentorship is a journey, not a destination. We will make mistakes along the way, but those mistakes will help shape us into more effective, empathetic, and responsive mentors.

Farewell, My Dumbledore

On August 7, 2018, the Cosmos reclaimed one of the greatest and most benevolent minds I’ve ever had the pleasure to work with. Granted, the man in question was someone I never met in person but through his books, blog posts and our occasional correspondence over the past eight years, that didn’t matter. I considered him a legitimate friend, mentor and, yes, a wise old wizard who helped me see things differently.

Jerry Weinberg will be remembered for many things. His absolutely prolific writing career. His career as a computer scientist is legendary. He almost single-handedly created the software testing profession (that’s a bit hazier, of course, but it’s hard to argue with how profoundly his effect on the craft and profession of software testing has been). “Perfect Software and Other Illusions About Testing" is my most gifted book to others on the subject. I've read it multiple times and will be rereading it again, along with several other works of his I've had the pleasure to own and read.

My Interactions with Jerry have been varied but I appreciated the fact that, were I ever to write a book review, no matter how old the book, he would always write back with a note of appreciation. If I had a question in the review, he would patiently explain it and help me see the intended meaning or bigger picture.

His “Fieldstone” method towards writing was the single biggest revelation for me and how I could organize ideas and thoughts when it came to writing. Too often I would start something and I’d either consider it not worth continuing or I’d question my direction. He taught me that was fine and perfectly normal. Just like a stonemason doesn’t use every rock they pick up immediately to create a wall, they often store those rocks in a spot so that, when the time comes to use that stone, they can shape it with minimal effort and put it in its proper place. An idea was not necessarily good or bad (well, some were just plain bad) but many ideas just weren’t ready to be put into the wall of my work just yet. Worry not, the time to use it will come.

What I will always remember about Jerry was his immense kindness, to just about everyone. I’ve thus far never met anyone that actually interacted with Jerry and had a negative thing to say about him. His various workshops over the years have been attended by several of my peers and to a person, every one of them said that Jerry took the time to understand them, learn their issues and frustrations, and somehow work beyond them. A phrase of his that I love is “whatever the problem is, we will deal with it.” I’ve taken that phrase and, in my own black humor have repurposed it as “we will jump off that bridge when we get to it” but the sentiment is really the same. Jerry always inspired me to try to solve problems, no matter how difficult.

We have lost a loving wizard, a true Albus Dumbledore in the flesh. That phrase was first mentioned by my friend and colleague Martin Hynie and I realized at that moment that that really was who Jerry was to me. Jerry was my Dumbledore. Always approachable, at times intimidating at a distance but never up close. He always endeavored to make you feel like you could overcome anything and that ignorance was a definitely curable condition. He has left us with a body of work that is frightening in its quantity but as has proven to me time and time again, reading it is so very worth it.

Farewell, my dear wizard. Thank you for making me just a little bit better as a tester, a technologist, an inquirer, a writer, and hopefully as a human being.

Knowing When To Step Down

For the past four years I have had the joys & frustrations of working with an organization, as well as serving on its Board of Directors. That organization is the Association for Software Testing (AST). The positions I’ve served in for those four years include three years as the organization's treasurer, and this past year (so far) as its president. These years have been filled with successes and challenges, satisfying goals completed and frustrating loose ends still to be resolved.

In August, at the Conference for the Association for Software Testing (CAST), those candidates who wish to run, or who are up for re-election, will put their hats in the ring and make a case as to why they should be selected. Earlier this year, I anticipated I would be creating a post asking for your support. Instead, I am putting this post together to encourage others to run and get involved, as I will not be seeking a third term.

Why am I making this decision, and why am I talking about it now?

First, I want to give those who want to run for the board a chance to get their names out and be considered. Second, I want to discuss some of the things being involved with the board entails, and how you can be effective or hope to be effective. Third, I believe that becoming entrenched within an organization for too long can be a hindrance to moving forward, whether intentional or not.

Due to circumstances in both my work and personal life, and the time and attention needed in areas important to me (my family and my career), it is clear the time and attention I can provide to AST, in the role of a board member or executive officer, is no longer sufficient to be effective. To make the time to be effective, I will have to pull away from two critical areas. My kids are at a key point in transitioning from teenage years to adulthood. My work environment has changed due to the death of my director. I've stepped in to fill many of the roles he played. In short, the conditions that made it possible for me to be effective as a board member are not there now. To keep serving in this capacity would be a disservice to the organization. I want to make sure that the work I care about regarding AST can be accomplished. I still want to be part of that mission, but I have to be realistic as to what I can offer and do.

For the first three years of my involvement, I was the treasurer. That meant I had to make sure our financial house was in order. Making sure the money that came in and the money that went out was accounted for was my primary responsibility. Once you get a handle on it, you can do it reliably and have time to think about other things. During the years I was treasurer, we made great strides in breaking out where our money was going, and how to use that money effectively to help local and international initiatives. I still think the AST Grant Program is one of the best kept secrets of our organization. It’s there, but only a handful of people take advantage of it.

Three times a year, we gather together as an in-person group to discuss the business of AST. We have done our best to pick a central location to minimize traveling costs.  For the past four years, that has meant the U.S. midwest or east coast. One of those tri-annual board meetings also coincides with CAST. Anyone who runs will need to be cool with being able to travel for those meetings.

Getting seven people to agree to a decision can be daunting. While we can reach consensus on a number of areas, sometimes we just don’t have the bandwidth or the agreement to put those items into motion. We have been criticized for moving too slowly. The fact is, in some areas, we do move slowly. We are aware that we represent a large and diverse membership. No decision we make will please everyone. Still, we try our best to make choices and develop positions that will benefit the entire organization, rather than be of benefit to only a small number of members. Additionally, if we must make a choice, we will choose not do something if the alternative is to do something poorly.

Once a month, we get together for a monthly conference call to discuss business that needs to be moved forward, and making the time to have that call happen each month is important. Outside of these calls, and triannual in-person meetings, the work of the organization needs to get done and moved forward. Often, real life interferes with that happening.

If you are interpreting my words here as saying “those who wish to run need to have both vision and bandwidth to make sure things get done”, you have interpreted correctly. If you are reading this and thinking I am dissuading others from getting involved, that is the opposite of my intention. I encourage those who do want to run for the board to do so, and do it loudly! While there have been stressful moments, it’s also been fun, and I’ve been really excited about what we have been able to do. I think CAST is one of the best software testing conferences out there. The vision of AST and the members of the board and its various committees make it possible. I think that BBST is a very valuable series of classes. I’ve enjoyed being an instructor these past several years. Even though I will not be on the board after November, 2015, my involvement with BBST will continue. I intend to keep teaching, and aiming to help improve the process and delivery of that teaching.

My recommendation for those interested in running would be to look at something AST does, and demonstrate how you can help sustain and/or improve what we are doing. If AST is not doing something you think we should be doing, make a case as to why you feel you can make that possible, and how you can help make that happen. In the past, those who've been elected had a goal they wanted to see achieved, and they had the energy to see it through. If this fits you, I wholeheartedly encourage you to see our Election page, and make a bid to run for AST's Board of Directors.

I want to thank the AST membership for four memorable years. Thank you for giving me the opportunity to serve in this capacity. I’m leaving the board, but I am not leaving AST, nor will I stop focusing on initiatives I feel are important. I must adjust to current realities, and serving on the board is a commitment of time, talent and energy. There’s a great group of people already there, and we will need great talent going forward. You could be one of those people.

The Case for "Just a Little More" Documentation

The following comment was posted to Twitter yesterday by Aaron Hodder, and I felt compelled not just to retweet it, but to write a follow up about it.

The tweet:

"People that conflate being anti wasteful documentation with anti documentation frustrate me."

I think this is an important area for us to talk about. This is where the pendulum, I believe has swing too far in both directions during my career. I remember very well the 1990s, and having to use ISO-9001 standards for writing test plans. For those not familiar with this approach, the idea was that you had a functional specification, and that functional specification had an accompanying test plan. In most cases, that test plan mapped exactly to that functional specification. We often referred to this as "the sideways spec”. That was a joking term we used to basically say "we took the spec, and we added words like confirm or verify to each statement." If you think I'm kidding, I assure you I'm not. It wasn't exactly that way, but it was very close. I remember all too well writing a number of detailed test plans, trying to be as specific as possible, only to have it turned back to me with "it's not detailed enough." When I finally figured out what they really meant was "just copy the spec”, I dutifully followed. It made my employers happy, but it did not result in better testing. In fact, I think it's safe to say it resulted in worse testing, because we rarely followed what we had written. Qe did what we felt we had to do with the time that we had, and the document existed to cover our butts.

Fast forward now a couple of decades, and we are in the midst of the "Agile age”. In this Agile world, we believe in not providing lots of "needless documentation”. In many environments, this translates to "no documentation" or "no spec” outside of what appears on the Kanban board or Scrum tracker. A lot is left to the imagination. As a tester, this can be a good thing. It allows me the ability to open up different aspects, and go in directions that are not specifically scripted. That's the good part.

The bad part is, because there's sparse documentation, we don't necessarily explore all the potential avenues because we just don’t know what they are. Often, I create my own checklists and add ideas of where I looked, and in the past I’ve received replies like “You're putting too much in here, you don't need to do that, this is overkill." I think it's important for us to differentiate between not overthinking and over planning, and making sure that we are giving enough information and providing enough details to be successful. It's never going to be perfect. The idea is that we communicate, we talk, we don't just throw documents at each other.  We have to make sure that we have communicated enough, and that we really do understand what needs to happen.

I'm a fan of the “Three Amigos” model. Early in the story, preferably at the very beginning, three people come together; the product owner, the programmer and the tester. That is where these details can be discussed and hammered out. I do not expect a full spec or implementation at this point, but it is important that everybody that comes to this meeting share their concerns, considerations and questions. There's a good chance we still might miss a number of things, because we didn't take the time here to talk out what could happen. Is it possible to overdo it? Perhaps, if we're getting bogged down in minutia and details, but I don't think it is a bad thing to press for real questions such as “Where is this product going to be used? What are the permutations that we need to consider? What subsystems might this also affect?" If we don't have the answer right then and there, we still have the ability to say “Oh, yeah that's important. Let's make sure that we document that.”

There's no question, I prefer this more nimble and agile method of developing software to yesteryear. I would really rather not go back to what I had to do in the 90s. However, even in our trying to be lean, and in our quest for a minimal viable products, let’s be sure we are also communicating effectively about what our products need to be doing. My guess is, the overall quality of what comes out the other end will be much better for the effort.

How I am Overcoming "Expectational Debt"

A phrase I have personally grown to love, and at times dread, is the one that Merlin Mann and Dan Benjamin coined in 2011 during their Back to Work podcast. That phrase is "expectational debt". Put simply, it's the act of "writing checks your person can't cash" (there's a more colorful metaphor that can be and is often used for this, but I think you understand what I mean ;) ).

Expectational Debt is tricky, because it is very easy to get into, and it is almost entirely emotional in nature. Financial debt is when you have to borrow money to purchase something you want or need, and it invariably involves a financial contract, or in the simplest sense a "personal agreement" where the money owed will be paid back. It's very tangible. Technical debt is what happen in software all the time, when we have to make a shortcut or compromise on making something work in the ideal way so that we can get a product out the door, with the idea that we will "fix it later". Again, it's also tangible, in the sense that we can see the work we need to do. Expectational debt, on the other hand, is almost entirely emotional. It's associated with a promise, a goal, or a desire to do something. Sometimes that desire is public, sometimes it is private. In all cases, it's a commitment of the mind, and a commitment of time and attention.

I know full well how easy it is to get myself into Expectational Debt, and I can do it surprisingly quickly. People often joke that I have a complete inability to say "no". That's not entirely true, but it's close enough to reality that I don't protest. I enjoy learning new things and trying new experiences, so I am often willing to jump in and say "yeah, that's awesome, I can do that!" With just those words, I am creating an expectational debt, a promise to do something in the future that I fully intend to fulfill, but I have not done the necessary footwork or put the time in to fully understand what I am taking on. Human beings, in general, do this all the time. We also frequently underestimate or overestimate how much these expectations matter to other people. Something we've agreed to do could be of great importance to others, or of minor importance. It's also possible that we ourselves are the only ones who consider that expectation to be valuable. Regardless of the "weight" of the expectation, they all take up space in our head, and every one of them puts a drag on our effectiveness.

Before I offer my solution, I need to say that this is very much something I'm currently struggling with. These suggestions are what I am doing now to rein in my expectational debt. It's entirely possible these approaches will be abandoned by yours truly in the future, or determined not to work. As of now, they're helping, so I'm going to share them.

Identify your "Commitments"

Get a stack of note cards, or use an electronic note file, or take a 365 day single day calendar, whatever method you prefer, and sit down and write out every promise you have made to yourself and to others that you have every intention of fulfilling. Don't just do this for things in your professional life, do this for everything you intend to do (family goals, personal goals, exercise, home repairs, car repairs, social obligations, work goals, personal progress initiatives, literally everything you want to accomplish).

Categorize Your "Commitments"

Once you have done this, put them in a priority order. I like to use the four quadrants approach Steven Covey suggests in "Seven Habits of Highly Effective People". Those quadrants are labeled as follows:

I. Urgent and Important

II. Important but Not Urgent

III. Urgent but Not Important

IV. Not Urgent and Not Important

My guess is that, after you have done this, you will have a few items that are in the I category (Urgent and Important), possibly a few in the III category (Urgent but Not Important), and most will fall into Categories II and IV.

Redouble or Abandon Your "Commitments"

These are questions you need to ask yourself for each commitment:

- Why do I think it belongs here?
- Will it be of great benefit to me or others if I accomplish the goal?
- Is it really my responsibility to do this?
- If I were to not do this, what would happen?

This will help you determine very quickly where each of the items fall. Most expectational debt will, again, fall in categories II and IV.

For your sanity, as soon as you identify something that falls into Category IV (Not Urgent and Not Important), tell yourself "I will not be doing this" and make it visible. Yes, make a list of the things you will NOT be doing.

Next is to look at the items that fall into Category III. These are Urgent but Not Important, or perhaps a better way to put this is that they are Urgent to someone else (and likely Important). They may not be important to you, but another person's anxiety about it, and their visible distress, is making it Urgent to you. It's time for a conversation or two. You have to decide now if you are going to commit time and attention to this, and figure out why you should. Is it because you feel obligated? Is it because it will solve a problem for someone else? Is it because you're really the only one who can deal with the situation? All of these need to be spelled out, and in most cases, they should be handled with a mind to train up someone else to do them, so that you can get out of the situation.

The great majority of things you'll want to do, and want to commit to, will fall in Category II. They are Important, but they are not Urgent (if they were Urgent and Important, you'd be doing them... probably RIGHT NOW!!!). Lose weight for the summer. Learn a new programming language. Discover and become proficient with a new tool. Plan a vacation for next year. Read a long anticipated book. Play a much anticipated video game. These are all items that will, in some way, give us satisfaction, help us move forward and progress on something, or otherwise benefit us, but they don't need to be done "right now". Your goal here is to start scoping out the time to do each of these, and give it a quantifiable space in your reality. I believe in scheduling items that I want to make progress on. In some cases, getting a friendly "accountability partner" to check in on me to make sure I'm doing what I need to do is a huge incentive. A common tactic that I am using now is to allocate four hours for any "endeavor space". I also allocate four hours in case I need to "change tracks" and take care of something else. This may seem like overkill (and often, it is), but it's a shorthand I use so I don't over-commit or underestimate how long it will take to do something. Even with this model, I still underestimate a lot of things, but with experience I get a bit better each time.

This of course leaves the last area (Category I), the Urgent and Important. Usually, it's a crisis. It's where everything else ends up getting bagged for a bit. If you ever find yourself in an automobile accident, and you are injured, guess what, your getting treatment and recovery rockets to Category I. In a less dire circumstance, if you are the network operations person for your company and your network goes down, for the duration of that outage getting the network to work is Category I.

I hate making promises I can't keep, but the truth is, I do it all the time. We all do, usually in small ways. Unless we are pathological liars, we don't intend to get into this situation, but sometimes, yes, the expectations we place on ourselves, or the promises we make to others, grow out of proportion to what we can actually accomplish. Take the time to jettison those things that you will not do. Clear them from your mind. Make exit plans for the things you'd really rather not do, if there is a way to do so. Commit to scheduling those items that provide the greatest benefit, and if at all possible, do what you can to not get into crisis situations. Trust me, your overall sanity will be greatly enhanced, and what's more, you'll start to develop the discipline to grow an expectation surplus. I'm working towards that goal, in any event ;).

Experience is Earned, Expertise is Granted

This title is meant to be a little provocative, and some may disagree with it, but I've been thinking about this topic quite a bit recently. First of all, I want to say thank you to Ryan Arsenault and the folks over at uTest for showcasing me in their first "Ask the Expert" blog entry. The questions I was asked centered around career choices for testers and ways that we can succeed, or at least do better than we are now.

I cannot help it, part of me feels very strange using the word "expert" to describe myself at anything. I'm happy to use words like experienced, educated, practiced or even proficient, but "expert" carries a strange weight to it. It's so subjective, and it feels like, once you've been branded one, that there's only one way to go from there, and that's down. Moreover, I don't really believe there is such a thing as an "expert", because that implies that that person has learned all there is to learn and has mastered all there is to master... and that's just fundamentally wrong on so many levels.

I've come to realize that we all own our experiences, and that we all have opportunities to learn from our successes and our mistakes (oh, how much I have learned from my mistakes). This is why I have no problems talking about my experiences or my observations. They are mine, and as such, are certainly open to interpretation, or debate, or scrutiny, or even outright ridicule at times, but they are wholly mine. Expertise, however, is a judgment call. I personally have very little trust in people who proclaim themselves to be "experts" at anything. However, I place a lot of credence on other people who tell me that someone is an expert. Why? because they are witnesses to the skill, acumen and judgment being displayed, and they can then decide if the term "expert" makes sense.

It also often comes down to "expert compared to who?" I have many interests, and things that I spend a lot of time getting into. When I tell people I was a competitive snowboarder for several years, it conjures up an image in their minds; I must be an expert snowboarder. They may even watch me ride, and come to that conclusion because of the technique I can muster and the terrain I can ride on. Yet put me alongside other riders I used to compete with, and any questions of my so called "expert" level goes right out the window. That doesn't take away from what I have learned, the events I've participated in and the medals I won, but to use those hallmarks to say I am an "expert" is, in my mind, misleading. Still, to others who have never raced, or are newcomers to the sport, to them I am an expert, insomuch as I can show or teach them things that they do not know.

Again, I thank uTest for giving me an opportunity to share my experiences, and I am honored to be part of their "Expert" panel. I don't know if I deserve the moniker, but they seem to think so, and so do their readers, and ultimately, I guess that just means it's up to me from here on out to either prove them right, or prove them wrong. Here's hoping my actions and efforts do more to strengthen the belief in the former, rather than proving the latter ;).

In Through the Side Door: Advice from an Unconventional Career

First off, Happy New Year to all of my friends and readers out there. I wish you all a great 2015 with the hope that what you strive to do and accomplish will be met.

About two years ago, I was given the opportunity to do a talk for a conference that would be happening in India called ThinkTest. My friend Smita Mishra extended an invitation to me to participate, and while I could not actually travel to India at that time, we decided to try something unorthodox. Why not video-tape my talk, and we would whittle it down to a presentation length and make it available to those who wanted to view it? Since I found myself in a hotel room near Chicago for an extra day, I decided to turn the room into a makeshift film studio and talk about my career as a software tester, its ups and downs, and other things that helped make it a reality.

Sadly, due to an automobile accident that incapacitated Smita for awhile, the conference had to be canceled. The talk project was, of course, put on hold, and then, over time, other initiatives took center stage, and I forgot about the talk and the recordings... that is, until a couple of months ago. Lalit Bhamare of Tea Time With Testers, asked me if we could use the material for his new project, TV for Testers. I said "sure", and he then proceeded to gather the clips I had recorded and delivered to Smita into the talk that is presented here.

In Through The Side Door

First, I feel it only appropriate to say... this is a long talk! I had originally recorded it with the idea that we would cherry pick the best parts and make a shorter presentation (something around forty minutes) but through correspondence with Lalit, he asked if it would be OK to present the entire talk, in its (mostly) unfiltered form. He felt that there was a lot of insights I offered that would be of value to those who, likewise, came to their careers from peripheral avenues, and the asides and segues, in his opinion, actually added to the value of the talk. So, again, that's what we decided to do. Lalit posted the talk on TV for Testers today, and I am now saying to those who would like to check it out, please do so.

Again, my thanks to Smita for asking me to put this together, and my thanks to Lalit for deciding he wanted to have it be seen. If you take the time to watch it, I also thank you for doing exactly that. To borrow from and paraphrase the recording artist Seal, "I hope you enjoy the presentation; it was the best material I had at the time" :).

Coyote Teaching: Watch How It All Came Together

Harrison Lovell and I decided to try an experiment.

What if a mentoring pair (a person relatively new to the software testing world and a longtime practitioner) were to work together and look at the way that mentoring is performed?

Could we learn something in the process?

What if we tried something novel, and looked at mentoring relationship all over the world, both current and ancient?

What would we find, and could we learn from them in a way that might prove to be useful to us today?


With that, we embarked on a several month voyage (mostly performed over Skype and email) and decided we'd give a try at a method that takes its cues from ancient cultures. Those methods are called "Coyote Teaching", and we opted to be the Coyotes :).

During CAST 2014, which was held this past week at the Helen and Martin Kimmel Center in New York City, we had the chance to present this topic and approach, and Huib Schoots, a friend of ours, was kind enough to record the whole talk. For those who would like to see it, it is here in its entirety:

I want to congratulate Harrison on his first conference talk, and to thank him for his enthusiasm, as well as his hospitality while showing me around mid-town Manhattan during the week (I should also mention that this was the first opportunity we have had to meet face to face).


I am also thankful to those who gave us valuable feedback to make the talk even better than we originally envisioned. My thanks especially to Alessandra Moreira for helping me go over the fine points of the talk and acting as the counter debater to help poke holes in the ideas we were going to present.

With that, please watch "Coyote Teaching: a New (Old?) Take on the Art of Mentorship". If you like what you see, please comment below and let us know what you liked. If you don't like what you see, please comment below and tell us that, too :). Either way, we'd love to hear what you think.

From Mid-Town Manhattan, it's #TestRetreatNYC

In the offices of LiquidNet, a group of intrepid, ambitious testers met and decided to discuss what aspects of testing mattered to us. Test Retreat is an Open Space conference, where the sessions begin when the participants want to have it begin (and end), the people who are there are the people who need to be there, and the law of two feet rules. We took some time to discuss topics, pull together similar topics and threads, and then head into our places to talk about the stuff that is burning us up inside.

---

The first session I attended was based around developing a testing community within a city or region. As many of us were part of different communities around the world, there were a variety of experiences, ranging from very small markets with perhaps a hundred testers total, to large regions with hundreds of thousands of testers, but little in the way of community engagement. 

Rich Robinson led the discussion and shared his own experiences with growing and scaling the community in Sydney, Australia. Rich shared that there were three areas that were consistently asked for and looked at as the goals of the attendees: looking for work, finding out the latest trends, and honing and sharpening skills. Rather than try to be all things to all people, they developed a committee and separate initiatives, with committee members focusing on the initiatives that mattered to them. For the group that wanted to get work, they made an initiative called “opportunity seekers”, and focused energy on those who had that as their biggest objective. For those who want to focus on latest trends, they have an avenue for that as well. 

Different regions have unique challenges. In the Bay Area, we have an overabundance of meetups for technical topics, of which a handful of them relate to software testing. As a founder of Bay Area Software Testers (BAST), Curtis Stuehrenberger, Josh Meier and I have chosen to try to focus on areas that are not as often discussed (we tend to steer clear of automation tools and techniques, since there are dozens of other meetup groups that cover those topics). Another challenge is frequency. In some cases, regular and frequent meetings are key. In others, having them less frequently works, but the key is that they meet regularly (monthly, every six weeks, or quarterly seem to be the most common models).

Rich also shared that their initiatives branch away from the formal meetup sessions, and have other opportunities that they initiate that occur outside of the formal meetup times. By having each initiative have people committed to it and resources to help drive those initiatives, buzz gets generated and more people get involved. One of the key things that Rich emphasized was getting people involved and engaged for these initiatives. The Sydney tester group has a committee of ten members that helps make sure that these initiatives are staffed and supported.

Another challenge is the local regions. Some cities have sprawl, others are difficult to get to in a timely manner due to traffic and population density. For example, the San Francisco Bay Area has four general regions: San Francisco (and the upper San Francisco Peninsula, Silicon Valley (and the lower San Francisco Peninsula), the East Bay, and the North Bay. With a few exceptions, people who participate in one generally do not regularly participate in the others. To reach out to a broader community in these sub-regions, it may require using technology and remote-access options for people to participate. 

Ultimately, growing a community takes time, it takes dedicated people, it takes a range of topics that matter to the attendees (including making sure that food and drink is there ;) ). To get those people you want to be involved, it helps to be very specific about what is needed. Saying “I need help with this” is less effective than saying “I need this specific thing to be done at this time for this purpose”. Specificity helps a lot when recruiting helpers.

—

The next session was “Sleep No More”, presented by Claire Moss, and focused on the model of the performance/play called Sleep No More (which is, in some ways, described as “an immersive performance of Macbeth”). It’s a darkened environment, all participants wear masks, no photography, no talking, just experience as the person sees it. Exploratory Testing, in many ways, has similarities to this particular experience. Claire used a number of cards to help display the ideas, and one of the first ideas she shared was “fortune favors the bold”. Curiosity and a willingness to go in without fear and deal with a substantial amount of “vague” is a huge plus. If you already have that, you have a strong advantage. If this is not natural for you, it can be developed.

Each room in the Sleep No More experience was part of the performance, and at any time, rooms could be empty or have people filter in during the performance. There are “minders” in the event that help to make sure that people don’t completely lose track of where they are. At times, there are very personal experiences that take place based on your tracks and where you go. Claire described a very intense experience of the performance based on where she went and what she observed and chose to follow up on. She also said that, up to this point, no one that she knew had anything like the experience she had.

The experience of Sleep No More was bizarre, creepy, full of strange triggers, and the potential to go into wildly unexpected direction. Software testing in many ways mirrors this experience. While there may be familiar areas and ideas, very often, our choices and angles may take us into very unexpected places. To give an example of the scope of the space, this was in a six story building, in an area that used to be a hotel (and whole areas of the building were gutted, in some spaces multiple floors were open to the air and visible). 

Claire described a feeling of “amazement fatigue”, where the level of stimulus is so high that there is no way to take it all in. The participants have to make conscious choices as to where they will go, and many of the participants will have wildly different experiences. Sometimes, they would follow a character, only to watch them go through a door and close and lock it, so that they couldn’t be followed any longer. This reminds me of following threads of a feature, and being brought to a dead end. People will observe different things, and they will also observe what other people do, and what they focus on. This can give us clues as to areas we want to explore next. 

This experience sounds amazing, and I am definitely interested in going and doing it myself, if time and commitments permit me to do so. Looks like I will be attending the August 10 performance :).

—

The next session was based on “Leadership”, and Natalie Bennett led the session with the idea that she wanted to see where individuals felt their experiences or needs for leadership were, as opposed to her telling us what she felt about Leadership and how to do it. Questions that Natalie wanted to discuss were:

- What is the purpose of a test team lead?
- What is it for?
What makes it different than being a test manager?

The discussion shifted from there into ways that test team leads and test managers were similar and where they differed. Some of the participants talked about how they led by example, and that they divvied up the work among the group based on the people involved and what they were expected to do. Team leads in general do not have hiring/firing authority, and they typically do not write reviews or have salary decision input. In other environments, the team manager and team lead are one in the same. There are some who are cynical about the effectiveness of this arrangement, while some feel that it is possible to be both a team lead and a team manager.   One attendee who is a Director of Q.A. for her company said that she was “the face of Q.A.” to the organization, and as such, she was setting the direction and expectations for the organization, as well as for her own direct reports.

Team leads are expected to teach and coach the members of their group, as well as be the point of contact for the group. It’s seen as important that they be able to focus on and develop their own role and make it responsive to their own environment. The team lead stands up for the group, and defends them from encroachment of issues and initiatives that are counter-productive to their success. Responsibility and authority tends to be on a sliding scale. Different companies allow for a different level of authority for the leads. Some give a level of authority that is just short of being an actual manager. In others, the leads is considered a “first contact” among equals.

One of the bigger challenges is to deal effectively when team members are failing. Failing in and of itself is not bad. It’s important to learn, and failing is how you learn, but when the failing is chronic or insurmountable, there needs to be a different level of interaction. Lean Coffee, direct mentoring, or even a serious re-consideration of experiences and goals can be hugely beneficial, both for the individual and the team as a whole.

—

Matt Heusser led a session about “Teaching Testing”, and some of the challenges that we face when we teach software testing to others. When we have an engaged and focused person, this usually isn’t a problem. When the person in question isn’t engaged, or is just going through the motions, then it’s a little more difficult.  The question we focused on at first was “what methods of teaching have worked for you?” Testing is a tactile experience, rather than looking at an abstract questions. We are familiar with questions like “how do you test a stapler?” or “how can you test a Rubik’s Cube?”. The presentation of this challenge may be the most important aspect. For some, they might look at “how do you test a stapler?” as demeaning. They are professionals, what is this going to teach me?

In my experience, one of the things I found to be helpful is to actually spell out how challenging the exercise could be. Rather than ask “How do you test a stapler?”, I might instead say “Tell me the 120 ways that you can test a stapler to confirm it’s fit for use?” This sets a very different expectation. Instead of saying “oh, this is trivial”, by seeding a high number, they may want to try to see how they might be able to meet or exceed that number. They become engaged.

To borrow a bit from Seth Godin, there are two primary goals for everyone. It’s the important aspects that we need to learn, regardless of the discipline. The first is to focus on authentic problems. The second is to be able to lead. Domain knowledge is a huge factor in helping to identify authentic problems. It’s not the only means, but getting to really know the domain can help inform the testing ability. Another important aspect is to understand how people learn, Everyone goes about learning a bit differently. Helping each person learn how they learn can be a huge step in helping to teach them. Sometimes the most ripe area of learning is to wade into an area where people disagree, or where there might be a number of people or groups where there might be dysfunction, where team members don’t talk to each other, or there’s simmering hostility between people. If there’s hostility between two programmers, and they write software that interacts with each other, it’s a good bet that there might be a goldmine of issues between their interaction points (I think this is a very interesting idea, btw :) ) .

Key to teaching testing is the ability to reflect and confirm what has been taught and learned, and for me, I think that Weekend Testing does this very well. The benefit of Weekend Testing, beyond just doing the exercise, is that we can see lightbulbs turning on, and there’s a record of it that others can see and learn from. Creating HowTo’s can also be a helpful mechanism for this. 

—

This section is the talk that Smita Mishra and I gave about “Hiring Testers and Keeping them Engaged Once We’ve Hired Them”. I recorded this session, and I will transcribe it later ;).

—

Claire Moss led a session on “Communicating to Management” and we went through and considered a list of questions that are important to frame the conversation(s):

What does quality like to our organization?

Why spend money on testing?

What does testing do?

What value are we getting out of testing?

I read this about QA, and it says we should do this… why aren’t we doing this?” 

These are all questions that we need to be prepared to answer. The question is, how do we do that?

There are several methods we can use, but first and foremost, we need to determine what we need to speak with management about, and if possible, use the opportunities to help educate them about what it is we can do, and at the same time, get a clear understanding about what their view of the world is.

Looking to standards and practices that are helpful can give us guidance, but it doesn’t always represent our reality. Information needs to be specific to explaining where we stand at the given time. Testing is primarily focused on giving quality information to the executives so that they can make qualified decisions. That is first and foremost our mission. Information that we can effectively provide is: 

- Framing of the ecosystem on a global scale (browser standards, trends, data usage histories)

- Impact on customers (client feedback, analytics data)

- Clarify issues and questions (heading off the executive freakout)

- Managing expectations (especially when dealing with something new)

- Explaining how likely issues brought to their attention really are problems worth investing in

- Explaining risk factors and methods to mitigate those risks

—-

At the end of the day we had a lot of new idea, feedback for some new initiatives, an emphasis on better communication, more focused due diligence, and the fact that so many participants had a lot they felt they could contribute. This was a fun and active day, and a lot of learning and connecting. One of the key things I am always impressed about when it comes to these events is that we really have a lot of solid people in the testing community, but we need even more.

I encourage every tester that admires craftsmanship, skill, and thinking make it a point to come to these now annual events (this is the third of these, so I think it’s safe to say that it’s a thing now ;) ). Once again, thanks Matt (Heusser) and Matt (Barcomb) for organizing what has becoming my favorite Open Space event. May there be many more.

Going "Coyote": Overcoming Fear and Uncertainty with "The Craddick Effect"

For those who have been following my comments about mine and Harrison Lovell’s CAST 2014 talk ("Coyote Teaching: A new take on the art of mentorship") this fits very nicely into the ideas we will be discussing. We’ve been looking back at interactions that we have had over the years where mentorship played an important role in skill development. During one of our late night Skype calls, we were talking about skateboard and snowboard skills, and how we were able to get from one skill level to another.

One aspect that we both agreed was a common challenge was “the fear factor” that we all face. In a broader sense, we both appreciate that snowboarding and skateboarding are inherently dangerous. Push the envelope on either and the risk of injury, and even death, is definitely possible. Human beings tend to work very hard at at unconscious level to keep ourselves alive. The amygdala is the most ancient part of our brain development. It deals with emotions, and it also deals with fear and aggression. It’s our “fight or flight” instinct. One one level, it’s perfectly rational to listen to it in many circumstances, but if we want to develop a technical skill like jumping or riding at speed, we have to overcome it.

About fifteen years ago, I first met Sean Craddick, a fellow snowboarder who was my age and was, to put it simply, amazingly talented. I used to joke whenever I saw Sean at a competition that I would say “oh well, there goes my shot at a Gold Medal!” He humored me the first couple of times, but the third time I said it, he surprised me. He answered “Dude, don’t say that. Don’t ever say that! I could try to throw some trick and land it badly, and scrub my entire run. I could miss my groove entirely, or miss a gate on a turn, or I could catch an edge and bomb the whole thing. Every event is up in the air, and every event has the potential of having an outcome we’d least expect. Don’t say you don’t have a chance, you always have a chance, but you’ll never get the chance if you don’t believe you have it.”

Because we were both the same age and had fairly similar life experiences, I’d hang out with Sean at many of these events, and sometimes run into him on off days when I was just up at the mountain practicing. One time, he noticed that I kept going by a tall rail and at the last moment, I’d veer off or turn and ride past it. After a few times of seeing this, when he saw me about to veer off again he yelled “Hey Michael! The next time you veer of, stop dead in your tracks, unbuckle your board and walk back up here. I want to talk to you about something.” Sure enough, I went down, veered off course, and slammed to a stop. I took off my board, and then I walked up the hill. Sean looked at me and said:

“Take it straight on, and line your nose with the lip and where the beginning of the rail is.”

I nodded, buckled in, and then went down to the rail transition. I veered off. I stopped. I walked back up the hill.

“Lean  back on your rear heel just a bit. It will give you a more comfortable balance when you first get on the rail.”

I nodded, bucked back in, went down again, and again I veered off. I stopped, unbuckled, and walked back to the top of the hill again. By this point I was winded, my calves were aching, my heart was pounding, and I was getting rather frustrated.

“One final thing. Do an ollie at the end of the rail.”

What? I hadn’t even gotten on the rail, why is he telling me what to do when I get off of it? I shrugged, buckled in, went for the hit, and this time, I went straight, I lined the nose up, I set my weight back just a little bit, I slid down the rail, and I did a passably adequate ollie off the end of the rail, and landed the trick. When I did,  Sean whooped and hollered, then came down after me and hit the same rail.

“Awesome, lets go hi the chairlift!”

As we did, Sean looked at me and said:

 “You can understand all the mechanics in the world, but if your brain tells you 'you can’t do it, it’s too dangerous, it’s too risky', you need to get your body to shut your brain up! That’s what I had you do. I knew why you were sketching the last few feet. You were afraid. It felt beyond you. You might crash. It might hurt real bad if you do. The brain understands all that. It wants to keep you safe. Safe, however, doesn’t help you get better. Whenever I find myself giving in to the fear, I stop what I’m doing, right there, and I walk up the hill, and I try it again. If I pull back again, I walk the hill again, and again, and again. What happens is the body gets so fatigued that every fiber of your being starts screaming to your brain ‘just shut up already and let me do this!' Exertion and exhaustion can often help you overcome any fear, and then you can put your mechanics to good use.”

Yeah, I paraphrased a lot of that, but that’s the gist of what Sean was trying to get across to me. Our biggest enemy is not that we can’t do something, but that we are afraid that we can’t do something. That fear is powerful, it’s ancient, and it can be paralyzing. That ultra primitive brain can’t be reasoned with very well, unless we give it another pain to focus on. At some point the physical pain of exertion and exhaustion will out shout the feelings of fear, and then we can do what we need to do.

In a nutshell, that’s “The Craddick Effect”. There may be a much fancier name for it, but that’s how I’ve always approached mentorship where I have to overcome fear and doubt in a person. When some one is afraid, it’s easy to retreat. As a mentor, we have to recognize when that fear is present, and somehow work with it.

You may not do something as extreme as what Sean did with me, but you may well find other, more subtle ways to accomplish the same thing. Imagine having to take on a new testing tool where there’s a lot that needs to be learned up front. We could just let them go on their own and let them poke around. We can take their word that they are getting and understanding what they need to, or we can prod and test them to see what’s really happening. If we see that  they don’t understand enough, or maybe even very little, don’t assume lack of aptitude or drive, look for fear. If you can spot fear, try to coax them in a way that they can put their energy somewhere else for a time so that they can get to a point to shout down the fear. It may be having them do a variety of simpler tasks, still fruitful, but somewhat repetitive and tedious. After awhile, they will get a bit irritated, and then give them a slight push to move farther forward. Repeat as necessary. Over time, you may well see that they have slid past the pain and frustration point, and they just “get” what they are working with. It just clicks.

As a mentor, look to help foster that interaction. As a person receiving mentoring, know that this may very well be exactly what your mentor is trying to do. Allow yourself to go with it. In the end, both of you may learn a lot more about yourselves and your potential than you thought possible. It’s pretty cool when that happens ;).

The State of Software Testing: A Follow-up and My Commentary

For those who may remember, back in December 2013, I encouraged as many testers as possible take part in the "State of Testing" survey being sponsored by Tea Time With Testers, and being collated and curated by Joel Montvelisky. Well, that survey has been completed, and for those interested in seeing all of the results, you can download it from here.

This is, of course, a self selecting group, so the views expressed may or may not be indicative of the broader software testing world, but it does represent the views of those who responded, including me (ETA: or at least intends to; see James comment below). Now that the survey is public, I'm going to share my answers (with some qualifying statements where relevant) and examine how my answers map to the overall report.

First, some caveats. Any survey that attempts to boil things down into data points will "lose something in the rinse cycle". There were a lot of questions where "well, sometimes" and "hmmm, not so often, but yes, I do that from time to time" colored the answers. My clear takeaway from all of this is that I realized I am not "just a software tester". I do a lot of additional things as well. I program (for some definition of programming). I write. I lead. I maintain and build infrastructure. I talk with and advise customers. I build software. I deploy releases. I hack. I do a little marketing here and there. I sell, sometimes. I play detective, journalist, and anthropologist. Much of this will not show up in this survey, but my guess is, a lot of you who answered probably do much the same, and some of that may not be reflected in this survey, either.

First of all, where do I rate in the hierarchy? For years, I was a lone gun, so had you asked me in 2012, I would have said Tester, Test Manager and Test Architect all in one. Today, I am part of a team of testers (most of us with two and three decade long track records). I'm definitely a senior, but I'm at peer level with just about everyone on my team. From time to time we bring in interns and junior team members where I get to mentor them, but much of the time, it's just us. While we have our different approaches and attitudes, I'm confident to say we balance each other well. Sometimes I'm the lead, sometimes I'm led. For us, it works.

Our test team, at this moment, has five people. One is our Test Director, three are Senior level Software Testers (me included), and one is a contractor whose sole responsibility is writing test automation. Our Test Director's title is mostly ceremonial; the four of us all work together to divvy up stories and utilize our expertise, as well as share that expertise with others to broaden our abilities. We do have "personal preference" silos. Our director likes doing a lot of the automation and rapid response stuff. One of our testers has a special knack for mobile testing. Another tester has a great feel for the security side of things. I tend to be the first in line for the architectural and back end stories. During crunch time, it's not uncommon to see the story queue aligning with our personal preference silos; hey, we know what we are good at ;). However, we do take the time to cross train, and all of us are capable, and becoming more so each day, to venture into other avenues.

Our Engineering team, including us testers, at this moment, is fourteen people. That puts a balance of roughly two testers to one programmer, the smallest ratio I've had to date in any organization I've worked at. Of course, for several years, I was the only tester, in organizations with ten to fifteen programmers. This has helped us considerably in that, at any given time, each software tester typically has two stories in play at any given time, possibly three if we count self-directed spikes for learning or infrastructure improvements.

Like most of the respondents, we have an Agile-like team (we bend the "rules" a little here and there, but as far as the core principles of the Agile Manifesto, I think we do pretty well). We have both a co-located and a distributed presence, so being able to communicate quickly is an imperative. We do a lot with shared screens, soft phones in our computers, and a set of IRC channels that sees a lot of traffic. We use our own product as our primary platform for doing as much of our business as possible. If it can't be done in Socialtext, we either find a way to do it there, or seriously consider not doing it at all. Our IRC server is the key exception. That's so we have a means to communicate and stay productive if the worst case scenario happens, and we lose our work environment (hey, it pays to be paranoid ;) ).

Each of us on the team wears different hats when we approach our software testing jobs. We are involved very early with requirements gathering (we practice the Three Amigos approach to story design and development). We all take turns along with the rest of the engineering team with core company functions. Each tester takes a week where they are build master and deployment specialist for our operations environment. Each of us manages a pool of development servers. Each of us is versed in the inner working of Jenkins, our Continuous Integration server, and each of, to varying degrees, writes or enhances test automation, utilize testing tools from a variety of initiatives, and do our best to be "jacks of all trades" while still holding on to our own "personal preference" silos.

We use a broad variety of testing techniques in our team. Exploratory Testing is championed and supported. Our developers use TDD in their design approach. They occasionally perform pair programming, though not exclusively. I actively encourage pair testing, and frequently coordinate with the programmers to work alongside them. Usually this is during the active testing phase, but at times during the programming stage, where I act as navigator and ask a lot of "what if" questions. In short, we are encouraged to use our faculties to the best of our abilities, and to provide essential artifacts, but not become slaves to the process, which I greatly appreciate.

We do two stand-up meetings each day. The first is the Engineering team stand-up, and then we have a dedicated Q.A. team stand-up, led by our Test Director, or one of us if the Test Director is not available. In these meetings, we gauge our own progress as a QA organization, and we look for ways we can improve and up our collective game. Oftentimes that means cross-training, and also working as a team on individual time-sensitive and critical stories.

Out test documentation lives inside of the stories we create. Each of the acceptance criteria is spelled out in the story, our programmers check off when they have finished coding to the acceptance criteria , we check off when we have finished testing for each piece of acceptance criteria, and we use a Notes field for each item of acceptance criteria to describe findings or add additional details. The goal is to have the ability to show what we completed, communicate our findings, and be able to (in as few steps as possible) provide the insight and context necessary for the programmers to fix issues.

We have a vigorous and active automation suite. It's in many ways a home-brewed process. These automation tests run the gamut from unit tests, to full workflow functional tests, and everything in between. Our product is actually used to write our automation, store our automation, and is called by our testing framework to run our automation. We get very meta in our automated tests, and it's been that way for many years. We don't expect every tester be a programmer, but it certainly helps. At this point in time, all of our testers do some level of automation test creation and maintenance. As to the level of our automation, we have a mantra that a story is not finished unless it has both unit tests to cover the defined functionality and QA based automated tests to exercise the workflow. I will not say we have 100% automated coverage, but we have a high percentage of all of our workflows and features automated. 85-90% would be a reasonable guess.

Again, we have one contractor whose sole responsibility is to create automated tests, and the rest of us augment those efforts. Most of our automation is aimed towards a large regression test suite, and our automated tests are treated like source code, just as much as the actual program code. If Jenkins fails on an automated test QA has written, then the build fails, and the programmers need to fix the reason for the failure. If the test is seen as flaky, it's our responsibility as testers (and creators of the automated tests) to fix that flaky test. In addition, we also have a broad suite of tests that we use to help us with exploratory testing as well. Their purpose is tobring us into interesting areas of the code after performing a variety of state changes, and letting us, as active testers, hop off and see what we can find. We often refer to these tests as our "QA Taxi Service".

Our process of managing stories, bugs, feature requests, etc. is again unique to Socialtext. All of our reporting is performed within our product. We have created a custom Kanban board to run inside of Socialtext, and all artifacts for stories reside inside the Kanban. Actually, they reside inside of Socialtext. We have engineered it so that our stories can reference individual pages, charts, SOCIALCALC sheets (our own spreadsheet program that resides in Socialtext), pictures, videos, etc. We make the information available to all as quickly and efficiently as possible. We take what we learn and create how-to guides for everyone to use and share. These guides get updated regularly. Everyone on the team has a responsibility to "green" the how-to guides, and make sure that everyone knows what has changed, what has been learned, and how to use that information to program better and test better.

So that's how my team looks compared to the survey. How about me?

I'm on the high end for experience as far as the survey participants goes, but I'm middle of the road as far as my immediate team is concerned. Our Test Director has been a tester for three decades plus. Our core in-office team of testers are all roughly the same age, and have the same relative years of experience (two decades being the average among us, with just a few years up or down either direction individually). Our test automation contractor has roughly a decade of experience. Though we occasionally get interns and other junior staff, for the most part, we're a pretty seasoned team, and that's rather cool.

As to continuous learning, I use a variety of approaches to learn. Testing blogs, newsgroups, Twitter, various "social" groups that are formed with other people (Miagi-do, Weekend Testing, Meet-ups, etc.) all play into my approach, as well as active blogging of what I learn. My attitude is to learn by whatever means is available.

Looking into the future, I see that there are a lot of areas that I personally want to focus on. I want to get more involved in testing for security. Specifically, I want to get a better practical, nuts and bolts understanding of what that entails. I see a need to boost my performance chops. That means going beyond running a tool that simulates load. My guess is that I'll be going back and doing a lot of re-listening to PerfBytes in the coming weeks and months ;). Automation is perpetually "there", and while every year I say I'm going to get more involved, I finally have a team, and a scope of projects, where that's more than just wishful thinking. More than anything else, I want to see what I can do to find the bottlenecks in what I personally do, and figure out how to minimize them, if not completely eliminate them. I also want to explore ways that I can eliminate waste from the processes I already do, even if they are processes and methods that work pretty well.

As to job security, tomorrow is always subject to change (that whole "past performance is not an indicator of future results"), but I finally feel I'm at a place, and a level of involvement in the testing community, where my potential to find future jobs (should such a thing be necessary) is looking better now than it has at any time in my career history.

So there you go, the TESTHEAD "State of the Software Tester" for January 2014. Have a look at the report (posted here again for convenience ;) ) and ask yourself "where do I stand?". More important, ask yourself how you can strengthen your own "state", and after you figure that out, work on it. Then reach out and help someone else (or a lot of someone elses) get even better and go even farther than they dreamed possible.

Retro Book Review: Tribes

There’s nothing quite like a cross country flight to allow one to tune everything else out, calmly sit down, turn off the cares and distractions of the world, and plow through a much needed batch of learning and focus. Sure the Internet is wonderful. It’s always on (well, almost always). It's 100% available (again, almost always). It’s filled with every tantalizing distraction imaginable, and (almost) always there to keep you busy (for some definition of busy). I asked myself “what could I do if I deliberately avoided al of that? What would I focus on? What could I focus on?" The answer is reading. A lot of reading. My blog readers, for better or worse, are going to get a rather large deliverable from that this week, in that I have book reviews to represent. Some of these books are older, some are from unusual places and interests, and one of them was literally handed to me by a friend with the comment “I think you need this”… and to which I would say “that friend was absolutely right”, but more on that in another post ;).

First out of the gate is  Seth Godin’s “Tribes”.  The subtitle of the book handily describes the purpose and point of this title: "We Need You To Lead Us". For those who are fans of Godin, you already know what to expect, so I’ll make a quick, terse summary that seems to come up with every Godin book. It’s quick, it’s rambling, it’s all over the map, it’s passionate, and it is bedevilingly void of specifics (and yes, I realize that I just totally made up a word there, but work with me here).

Now, with the most obvious of details out of the way, let’s get into what makes this fast read really valuable. Seth is drawing a line in the sand and asking us, all of us, to take up the mantle of leadership. Don’t wait to have it bestowed, steal the throne for yourself. How? Create your own tribe, and have others follow you. That’s it. In a nutshell, that’s the very simple message of the book. Of course, simple should never be equated automatically with easy, and in this case, being a genuine leader and creating a meaningful and devoted tribe, while simple, is definitely not easy. It takes time, commitment, passion, determination, expertise, skill, desire, devotion and most important of all, faith. 

Tribes shares many vignettes of individuals that bucked the trend and changed the world. Some of the trend buckers are famous (Jobs, 37 Signals, Nike) and many of them are people that most of us have never heard of. Their stories are still poignant, and the essence of who they are and what they do rings clear to the primary message of the book. Take an idea, work with it, believe in it, and seek others to help champion it. So simple, and so direct. Yet amazingly, so few people ever actually follow through with it, because there is risk, there is a chance of criticism, and frankly, it takes sustained passion and belief that you will prevail where others have not. It’s a risky doctrine… but it’s also an extremely fun doctrine!

The key takeaway (and one that Set puts into other books, and I think is the central theme of his overall message) is that the “tried and true” of olden days is getting pummeled in a world where large established factories and processes are quickly becoming disrupted and obsoleted. Ten years ago, to publish a book, you needed a publisher willing to take a risk on your book. Today, Leanpub and Lulu (and other organizations) make it possible for anyone to write or publish). In that kind of a word, what sustains and grows is not the tried and true, just for the virtue of it being tried and true, but the remarkable, the unique, the interesting, and the desirable. Is everyone going to come up with the “next great idea”? Probably not, but all of us have good ideas, and many of those ideas do not require a major investment or system to enact. Leadership isn’t necessarily creating a startup and becoming rich (though that is certainly fun and awesome when it happens). Leadership can be based in your own group, and being willing to try a new technique or approach, or even trimming away wasteful processes that are slowing a team down. It could be a blogger who writes about an industry that they are passionate about, and how they hope to make changes in that industry.

What stands in the way? Mostly fear. Fear of being branded a heretic. Fear of upsetting the status quo. Fear of being criticized, or laughed at, or mocked. They could possibly be fired, or ostracized, or “burned at the stake” (hopefully metaphorically, though yes, there was a time when that was a real fate for “heretics”). Those fears are all real. They could happen. Seth makes a compelling point that they likely will not, and that the simple fact is that we are being surrounded by heretics, because the cost of being one is going way down in our modern world. With that in mind, why not be a heretic? Be a leader, exhibit some faith, and take that leap. Not only will you likely not suffer slings and arrows, you may just inspire many others to follow your lead, and you may encourage them to do likewise.

Bottom Line: 

This isn’t a long book. It’s not a thorough book. It doesn’t have a lot of specifics. It doesn’t have a lot of examples. It makes the maddening point that there is no map to follow, but if you have some passion, some drive, an idea or two, and a belief that they will come to fruition, the odds of you finding people willing to help you push that idea forward, by forming a tribe around that idea, is pretty high. It’s also likely to be small at first. It may may always remain small, and that is totally OK. In fact, most of us belong to hundreds, if not thousands, of tribes at any given time. In many of those tribes, we are followers. In many of them, we are leaders. The most likely thing is that those of us who are leaders of tribes don’t realize it. Seth gives us some motivation to help figure that out, and then do something with it. For that, I think Tribes succeeds.

Let's Stop Faking It: My "Other" Talk from Øredev 2013

I realized this morning, as I went back to the Øredev 2013 site, that my video for my 2nd talk had been posted. My talk about Balancing ATDD, GUI Automation and Exploratory Testing has been getting most of the press, as well as repeat performances for the Bay Area Software Testers and Silicon Valley Software Quality Association meetups. Still, I want to talk about this one, as it really draws on a lot of things I've been thinking about, as well as a moment of embarrassment and realization during the Q&A.

This talk was all about expertise, and how we all deal with it and represent ourselves around it. I draw a lot on my own experiences and how I like to deal with ways to get beyond faking what I know and moving forward into real knowledge and skill. For those who want to see the actual Prezi presentation up close and personal, it's here.

The embarrassing moment? In the Q&A, I was asked how I felt about "Impostor Syndrome". I totally botch the definition, and I give an answer that is 100% opposite as to what Impostor Syndome actually is. Maybe it was a combination of lack of sleep or adrenaline rushing through me, but I worked through the answer, moved on to other participants, but as I would look back at the person who asked about Impostor Syndrome, I could tell by the look on their face that I didn't answer their question. 

Fortunately, one of the participants clarified for me what I had messed up. Impostor Syndrome is where you are competent but believe you are not. I felt tremendously relieved to hear this, as it gave me a chance to re-consider, re-frame and add to my understanding. Of course, some are going to ask "How could you give a talk about faking it and not have had a good grasp of "Impostor Syndrome"? It's a fair question. I didn't prepare my talk from a perspective of psychological reasons why people fake it, I approached it from my own memories and working with other people I directly knew. "Impostor Syndrome" was a term that, until that very moment, I'd never actually heard. I mentally walked through what I figured it would be, and answered. Were I perhaps better rested and less amped at that immediate moment, I might have said "what do you consider good examples of Impostor Syndrome?" so I could see their context, and then get an understanding for what they mean by the term. It's what I should have done, but didn't.

So why was that great? It gave me a very public opportunity to come clean, to not be evasive, to actually address head on something I didn't know, but "pretended" to (ironic considering the topic, huh ;) ?). It let me live my creed, and allowed that to be the lingering memory, rather than having no one call me on it, but then have several people walking around afterwards saying "wow, what a hypocrite, he just totally faked his way through that answer!"

It was a terrific reminder, and one I won't soon forget.

That's Great, But How is This Helping Your Testing?

When I went to Øredev last week, I had a whirlwind of emotions, experiences, learning and changes of perspective. While I enjoyed many of the sessions I attended, and certainly enjoyed giving the two talks that I did, I think it's safe to say that one of the most valuable lessons from this trip happened between sessions I attended, at a table in the lounge area, during a conversation I was having with James Bach.

James and I have had a number of chances to talk in the past, but usually they have been in group settings. I think this may have been the first time that James and I had an extended conversation that was just the two of us. He was commenting on the fact that I had been writing a great deal recently, and that I'd been reading a lot and talking about what I'd been reading in my blog.

During the course of the conversation, we were discussing a number of the books and ideas I'd been writing about, and James homed in on a particular question: "Can you tell me which of these books you have been reading have had a definite impact on your approach to testing, and if so, what is it?" I talked about a variety of books, including my beloved James Burke's "The Day the Universe Changed", and its focus on the interconnected nature of events and discoveries, and how I strive to look for those interconnection points. I gave several examples, and he said "That's great, but how is this helping your testing?" I had to think about it, and I tried explaining the nature of understanding what I know and why I think I know it, and referenced several other books in the process, including "Good Math" by Marc C. Chu-Carroll and how understanding and articulating logic has helped me be more focused and attentive to my assumptions. Again, the same question was asked: "That's great... but how is that helping your testing?"

Through this conversation, I came to a realization... I enjoy reading, writing, and applying ideas to how I test, but I struggle with making clear connections in my own narrative and how I work to actually bring home that point. Sure, I read a lot, and I get ideas, and I can focus on key principles that are interesting, informative, and certainly applicable, but if I cannot readily explain why what I am reading is applicable, or how I am personally applying it, then my effectiveness as a tester is not going to reach its full potential. James emphasized that there are many things that we do as individuals that we struggle to explain. He said he realized he was at a similar point several years ago, and decided that he wanted to make sure he could ground his ideas very clearly, and with unambiguous language, wherever possible. He said he wanted to not just explain what he was doing, or how he was doing it, but why he was doing it. Not just for himself, but so that he could readily articulate it to others and be sure that they understood it.

At the end of the conversation, James handed me a book and asked that I give it a good read and ponder its message. That book is "Rethinking Expertise", by Harry Collins and Robert Evans. It emphasizes a different perspective on how we look at "tacit knowledge", which is knowledge that we have, and skills that we use, but that we have difficulty explaining. James made the point that, as he saw it, I had developed a broad body of tacit knowledge related to testing, and that I was trying to explain it in my writing, but that I had difficulty articulating exactly how I was applying the knowledge I had gained. He suggested that might be something I work on going forward.

I am happy to accept the challenge. My plan is to do exactly that. In future posts, if I am reviewing a book, discussing a technique, or considering a controversy, I will make every effort to try to explain, either in the narrative or in its own side bar, exactly what I feel this topic, book, tool, or skill is bringing to my testing. I'm also willing to bet it will be a much harder challenge than I am currently anticipating it will be. Either way, this fits into my talk and personal philosophy about "not faking it", and I welcome the opportunity to make good on that promise :).