The Humans We Want in the Building

An affirming, cheerleader post about keeping QA around:

Perhaps our collective ability to not only rapidly detect, but also fix issues within our products, has made us less dependent on relying on an independent QA function? 

My concern is that the absence of QA is the absence of a champion for aspects of software development that everyone agrees are important, but often no one is willing to own. Unit tests, automation, test plans, bug tracking, and quality metrics. The results of which give QA a unique perspective. Traditionally, they are known as the folks who break things, who find bugs, but QA’s role is far more important. It’s not that QA can discover what is wrong, they intimately understand what is right and they unfailingly strive to push the product in that direction. 

I believe these are humans you want in the building

Full post: The QA Mindset - Rands in Repose 

A Good Day at Work

Aspects of good days at work for me:

• Learned something.  
• Struggled a little.  Felt a little stupid.  Got over a hurdle and felt a little awesome. 
• Taught something. 
• Finished something.  
• Laughed. 
• Made someone else laugh.  
• Appreciated someone. 
• Helped someone. 
• Talked with someone else about what they're working on 
• Spoke up 
• Shaped the conversation 
• Left projects and people better than I found them
• Felt appreciated and "heard"
• Felt deeply in-the-moment for minutes or hours at a time, when I have something so interesting to work on I have to stay at my desk to see what happens next.  
• Random bagels or donuts showing up in my path
• Left my desk with a clear vision of what I want to do tomorrow

(Almost) young, scrappy, and hungry

Once again, I draw inspiration from Hamilton lyrics.

Just like Hamilton (and his country, by the transitive property), I'm scrappy and hungry or at least I aim to be.  

By scrappy, I envision doing whatever it takes to get the job done.  This means knowing about all of the tools at my disposal and how and when to use them.  I want code and answers to fly across the screen like in an episode of CSI. 

By hungry, I want to always want more.  Yesterday's tools might not be today's tools.  Stay on top of things, uncover new ways of thinking, be able to contribute meaningfully to a product conversation. 

These are great thoughts, and they do get me out of bed most days (my excitable dog gets me out on the other days), but I don't always know how to channel my enthusiasm other than thinking great thoughts until I get frustrated by not amazing myself yet.  

I want to call myself a programmer with a passion for code & software quality, quality being anything from user experience to code maintainability.  I want to troubleshoot problems anywhere along this spectrum and prevent future problems.  If my team needs me to write production code, I want to step up with whatever skills are needed.  Scrappily and hungrily.  

To be able to be as versatile as my "where I want to be X years from now" vision, I need to make the leap between "hello world, loops, and lists" and "being a real programmer".  Like Pinocchio wanted to be a real boy and Number Five wanted to be alive.  Getting involved in open source seems like the next step.  I've been sitting on the sidelines of github for a few years, not sure what to do next after creating an account. I found and worked through part of the GitHub for Beginners tutorial that goes a bit further than some basics I've seen, and is more step-by-step than some of the more advanced stuff supposedly for beginners that still contain too many nouns and verbs I'm unfamiliar with in the github context.  

Nobody can make me do this except me.  Though drawing inspiration from wherever or whomever it may be found certainly does help.  

Testing Haiku

I will work through lunch
Stay late, tracking down a bug
Just to hear "good catch"

Addition, because I got preemptively defensive about this point->
Tracking down bugs or any kind of problem solving is of course an inherent reward.  But right or wrong I'm a junkie for "gold stars"

"Know Your Ground", posted by Maaret Pyhäjärvi

As a tester, I'm supposed to know how I do good testing. If something asked of me takes me away from that or makes me partially  go away from that, I shouldn't stand down without a good discussion.

I know my ground. I stand my ground. I negotiate and experiment, and move. But the starting point is that I know where I'm coming from and where I'm going. I believe this is a big part of why I love my work as much as I do. I'm not a victim, I'm an active player.

Know Your Ground -  Maaret Pyhäjärvi

In Defense of Roadblocks

Image Credit: Matthew Deery

Rather depressing post from Joe Colantonio based on his interview with Andy Tinkham.

QA is a roadblock while every other part of the organization is trying to move at a faster pace.

The more we're able to automate in the interest of being more productive, the easier testing looks and the more it seems as if anyone off the street can do it.

Andy provides some suggestions for reversing or mitigating the negative perceptions that others have of us, such as playing up the value we provide as skilled humans.  We're able to do things like have our years of tacit knowledge give us an uneasy feeling in the pit of our stomachs that something is wrong.  And we can use that feeling like a metal detector on the beach to guide us where to dig deeper for bugs.  Computers don't have uneasy feelings and can't deviate from the programmed path.

We can be open to revising our methodology to be less rigid, as long as we still provide to the customers what we say we will deliver in terms of testing artifacts and exploration of risk.

We can get better at articulating outside our departments the value we provide instead of speaking in terms of arcane metrics.

But I hope we don't get too caught up in the idea of not being a roadblock.  We testers are definitely part of the same team as development in that we want to release a good product to the market that pays for all of our salaries. However we're serving an opposing interest in many important respects.  We're the lifeguards in the swimming pool, keeping our eyes open for problematic situations that arise in the midst of all the fun.

Roadblocks serve a purpose.  When the road ahead is flooded or the bridge is under construction, most people would think that a sign or physical barrier is helpful.   They protect us from risk. We've grown to expect them to be there when they're needed.

Roadblocks don't (or shouldn't) get joy from blocking the road.  They get angry looks as people are forced to turn around or take a different route or temporarily stop.  We shouldn't remain in the road any longer than necessary so that the road/bridge can provide the value that it was intended to provide.

But we shouldn't remove ourselves prematurely either.  We exist for a reason and we should take pride in the fact that we're doing our best to keep the community safe from paths that are not yet ready to travel.

Useful graphics about "Change" via Helena Jeret-Mäe

Photo Credit: The Original Muddog

How do you do, Head of Testing? vol. 3

The section about "Managing Complex Change" seems particularly useful in making sure all of the ingredients are present for a successful transition.