Self-Hacking

I've been lucky enough to have a nice chunk of vacation time at the end of 2016. 

I had a big list of to-do's piling up -- things that I want to do when I have time. And now that I "have time" they're still not done. 

Because even on vacation, I still feel pulled to do things that don't help me learn new skills or provide service to others.  I do things that are important (take walks with my kid, spend time with friends and family) and those that provide more instant visual indication of progress like cleaning out the junk drawer or a closet.

Hack 1: I need to make seemingly insurmountable things like "remain employable" and "advocate for important causes" more tangible. Something I can look at and admire, like an organized drawer.  So a certificate for a completed online class.  Or keeping a list or log of phone calls I have made or postcards I have sent.

Hack 2: I need commitment or I will find something "more important" to do.  "More important" probably meaning spending time with my kid even though she probably doesn't need as much time as I give her....Or forfeiting my allotted professional development time at work because I'm too busy doing my work tasks. But if I have a friend counting on me being at a meeting or the threat of making a bad grade in an online class, I am much more likely to do what I *say* I want to do in the first place.

In short, time is not what I need.  I need to build a schedule that commits me to doing the things I care about, with adequate slack time so that I can do the important things like cuddle with the dogs.

Theme for 2016: The Power of Story

I begin writing this post as an "assignment" I've taken on as part of a Toastmasters-like public speaking club a good friend of mine has organized. 

In less than three weeks, I need to give a 4-6 minute speech on any topic I want, as long as it is organized clearly.  It is Speech 2, for those of you familiar with the Toastmasters curriculum.

Anything I want, eyyyy?

What do I have to say, and why would anyone listen?

I need a story.

A memorable talk I saw (virtually) this year was Dorothy Graham's presentation at STAREast.  It was geared toward software testers but really, it was for anyone who provides information for a living.  You need to make the information relevant to them - suck them in and don't let go until they understand and are prepared to act.  You can't inform them if they're bored.  And if you don't inform them, then you're not providing value.  And if your job starts looking like a cost without benefit, it starts sticking out as low hanging fruit for workforce reduction.  While you won't be killed for failure to entertain, I see myself every day as Scheherazade in Dorothy Graham's relaying of The Arabian Nights.  Give people a reason to keep you around and they will. 

A colleague of mine continually reinforces the importance of storytelling to me.  Why would a customer care about a new feature in our software?  What tangible takeaways can we use to inspire customers enough to write a purchase order?  Or to inspire staff to go the extra mile in supporting or delighting customers?

I've even started evangelizing storytelling to others.  I was speaking with a bright eighth grader who was putting together a display for a science project, and I was advocating the importance of easy-to-read headers and blank space between thoughts rather than a Wall of Text.  I said that adults have a very short attention span.  You need to instantly tell us why we should care and provide enough incentive to read the full paper.  She worried that she wouldn't sound smart if she "dumbed down" her display.  And I said they wouldn't know anything about how smart she was if they were too bored or intimidated by her display to want to know more.  Just like that, I became a storytelling advocate. 

I started to feel like I was an agent in further reducing the attention span and appreciation for nuance.  So I'll add further that stories need to be factual and appeal to the best in us.  They need to entice you want to know more about the subject matter and inspire curiosity rather than falsely imply that everything is simple.  We need to be astute consumers of stories as the trend of storytelling spreads.

• What is the storyteller's motive? Are they selling something? Asking for a vote?  To legitimately inform?
• Remember that YOU are part of the story.  And you have a brain.  Ask questions. 
• Is the story complete?  Is it true but misleading?  Does the storyteller have a good reputation for accuracy?   Inventory the emotions that the story evokes in you - Are they emotions you are proud of or are they more lizard-brain emotions you'd prefer to evolve past? 

Apparently my speech needs a closing.  I don't think I'll be able to use this as a speech, but it was fun to take a run at putting some thoughts down. 

Ethics and persuasion

The more software continues to take over every aspect of our lives, the more important it will be for us to take a stand and ensure that our ethics are ever-present in our code.

- Bill Sourour: The code I'm still ashamed of 

I'm not asking for advice, just a hypothetical thought exercise....How do professionals take a stand?  A CYA letter to your immediate supervisor?  Voice displeasure all the way up to the CEO if necessary? Quitting? Blog about it and name names?

I'm fascinated by the process of steering my surroundings in the direction I want them to go.  Not meaning I always get my way, just that my input is included in the vector of where things end up.  Most of the time.  Sometimes there should be no compromise.  Probably. See, lots of interesting questions that play out any time a decision is made at work, at home, school, church, at a four-way stop sign, in public policy at all levels of government.

Learning how to be effective at this is difficult.  You have to win allies without alienating people.  Get people to listen and take action without making them feel scolded.  Spread information without sounding like an elitist know-it-all.  Speak with enough confidence that people know you know what you're talking about.  Read the situation to know where ground can be gained. Know how to get attention without sounding whiny.  Strike a balance between appealing to brain and heart.

Know if it's one of the rare times when just completely losing it (whatever that looks like to you) is the way to go in order to make your point.

Statistica, no longer part of Dell

As I mentioned in June, Dell has sold most of its software division, and now as of October 31, 2016 we old timers of StatSoft are part of Quest.  Though most of the time we'll be known as Statistica for branding purposes.

This has been quite a year.  Kind of like Saved By the Bell: The College Years...some familiar faces...some new ones...some that are noticeably absent now. Lots of change, lots the same...some of the sameness is comfortable, some of it is weird.  Some of the change is exciting, some we're still navigating through. New dynamics to learn, new energy.  Trying to transition from what we were into what we'll be a little more gracefully than Screech did. 

We are smart people.  We have a good product that we want to make even better.  We want to build features that make sense to build and to help customers solve problems. We have fun at work.  We care about each other.  We disagree sometimes about specifics but we all come to the table to work out solutions. We're curious and quirky and committed and giving.  We keep showing up with passion and integrity, and this won't change.  

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.

 

The real "A Tale of Two Testers"

Lanette commented on my last post with a link to her original post. 

I guess I subconsciously swiped the title -- I thought the title came to me a few seconds sooner than most titles for my posts, so I googled the title plus either Lanette's name or username just in case that was the actual title of the original post but nothing appeared in the search results.  I was satisfied that I was just stealing the title from Dickens and hit the Publish button. 

I was glad to read the original again; it was posted just over six years ago and it has affected so many interactions with my coworkers. 

New Title! Now without subconscious plagiarism!

UPDATE:  Lanette shared a link to the original blog post! 

It was at least five years ago.  I read a post by blogger and all-around testing guru Lanette Creamer.  It has stuck with me.  I don't remember enough keywords to track it down but the gist of it was to imagine two testers, with let's say, way more work than they can reasonably do by a deadline.

One gets overwhelmed, frazzled, and angry. He works late hours and weekends, sighing about it the whole time, not helping out others with their questions, sleepily and grumpily doing the work he perceives is expected of him.

The other is calmer and remembers he's a member of a team.  He does solid work and puts in some extra hours but not so many that he loses passion and focus. He is available to help a new tester become better.  He gives updates on what he has done, and what concerns about risk remain.

And it had a "which one would you rather work with?" type of question posed at the end.

Whenever I get an extra task on top of my already-packed task list and my first instinct is to burn myself out to the point that I snap at people who dare stop by my desk with a question, I remind myself that I'd prefer to be the second tester.

Lean In....To Your Confusion

Today, I sent an email containing a list of all the things I'm unsure about.

Well, the things I'm unsure about for one particular work project anyway.

It's my job to ask potentially stupid questions. To expose myself as a fraud who has no business touching a computer.

I ask them anyway.

Because I've learned that sometimes when you ask a "stupid" question, you get two different answers, which surfaces some assumptions that hadn't yet been verbalized.

Sometimes you spark a conversation because they hadn't yet thought through the scenario you asked about. 

 (Image Credit: Charles Hutchins)

Sometimes you get an answer that's over your head but you can make a list of things to Google later so that you have a deeper understanding from which to ask future questions.

My understanding of a project builds itself like an imaginary house, and over the years I've built many imaginary houses.  My comfort level is high once I start seeing walls and a roof.  But sometimes I feel a tickle in my brain that's something like "Hmm, I didn't see a bathroom in this house yet.  I need to verify that we have a toilet.  Because that's kind of a big deal"

Trust the tickle in your brain.  It could be intuition taking the form of confusion.  And if it's not, your temporary feelings of embarrassment will help fertilize the ground from which your intuition grows.

(PS - I recall James Bach saying ideas of this sort in a YouTube video but I don't recall which one; hopefully my thoughts are more "inspired by" than "stolen from")

James Bach on providing meaningful, honest time estimates

Truthful Estimations by James Bach, ThinkTest 2015.  I couldn't believe this video only had 142 views!

Takeaway nuggets: 

• Testing closes the gap between what we know about the product and what we NEED to know about the product.  The riskier the product, the more we need to know.   Testing is like using headlights when driving at night.
• To be useful, estimates must be accurate and precise.  Don't lie, just give updates as more is known.  If you have to give an estimate, give three estimates to give customer an idea of the trade-offs involved.
• Low end, happy path, customer ends up assuming a lot of risk
• Conservative, test usability and all permutations of risk such as security
• Middle ground
• To the estimates, you need to add a public buffer that attempts to account for unpredictability.  The buffer can be estimated by looking at similar past projects and knowing what unexpected things happened so that you can do a better job of expecting them this time.  This requires an honest look at how we actually spend our days as opposed to how we ideally spend our days under perfect conditions.
• Reasons for unpredictability: 
• "Blocking unknowns" -- If there's a dependency of unknown length or complexity, you cannot estimate an end date for your work. Examples include setup of test environments or finalizing what the product is going to be.
• Finding bugs -- Estimates can be skewed by assuming everything will go smoothly.  In reality, there is a lot of time investigating, diagnosing, explaining, waiting, and retesting.
• Overestimation of time spent working on testing-related tasks.  One example is "team self-care", which on the surface look like people standing around talking about pleasantries but is a long term builder of trust and productivity. 

"You Can't Build a Reputation on What You're Going to Do" - Henry Ford

My previous post annoys me now, because in two places I mention plans. 

The first one - bullet point Weinberg's Perfect Software and Other Illusions About Testing, I'm not going to do.  Why?  Because anyone who is interested in the subject matter should just read it. What I actually did was take an excerpt outlining reasons to involve testers in technical meetings and shared it on an internal Confluence page at work.  This was the most useful passage to me as we move toward more agility in our development process, and it was nice to have an external authority to back up what I could only express before as intuition.

The second one - prepping a talk to submit for next year's Tulsa Tech Fest or wherever else it might be useful - it's on my perpetual to-do list now. 

Perpetual to-do list? It's my variation of structured procrastination.

Summary:

• I have a list of tasks in Google tasks, all with deadlines.  
• Some are one-time tasks, like "Call somebody to remove the ugly, buggy, weed-like tree in front yard"
• Some are weekly or monthly or every six months, like giving the dogs their pills or paying auto insurance bills
• Some are just big ongoing tasks, like "Clean the garage".  These have "deadlines" but if I don't accomplish anything by the deadline, I just move the deadline back. 

So as an example, I'm looking at my unfinished list from yesterday.  The first one is "write a blog" -- It looked to be the most interesting thing near the top of my list, far above "Cleaning floor in hall bathroom", so here we are.  I pushed that task to next week.  If cleaning the floor were more urgent, like if my mom were visiting this weekend, I'd feel more inclined to do it now instead of pushing it back.

So back to my talk -- It's there on my list now.  It's not that I'll sit down and prep a talk in one session.  I'll just make some kind of measurable progress when the mood strikes.  Which will likely be when I've just read some interesting material I want to add, and my other choices are "Clean the garage" and "change the unreachable light bulb"

It does require discipline to actually *work* on the to-do list. It's not going to solve the "I can't get anything done because I'm binge-watching Netflix" problems.  But I've found that actually having a system instead of being overwhelmed at the million things I haven't done is helpful to getting a thousand meaningful things done instead of zero.

Goodbye July: 30 Days of Testing Challenge over :-(

Even though I didn't complete every day of the 30 Day Testing Challenge, it was still enjoyable and thought-provoking. I loved seeing so much passion, creativity, and humor in my blog feed every day.  Keep it up!  Thanks to Rosie Sherry and the Ministry of Testing for bringing all of us software testers together.

I finished Perfect Software: And Other Illusions about Testing by Gerry Weinberg right before falling asleep last night.  I gave it five stars (out of five) on Goodreads. I'll go through it one more time to take down some of my favorite bullet points for discussion.

This Friday is Tulsa TechFest.  There are two empty slots for QA/Testing.  The empty slots have been in the back of my mind, haunting me, beckoning to me.  Getting a talk ready by Friday would probably raise my blood pressure to an explosive level....but it has prompted me to put together a Google doc where I can compile and cite material to have ready to go for opportunities like this in the future.  This is more exciting to me than scary, so I have apparently flipped a confidence switch in the past month or two. Yay personal and professional growth!


 

Dead Salmon Testing

Earlier this month, there was chatter about the validity of fMRI results that referenced a 2009 study where brain activity was found in a dead salmon. When looking at functionality, it can be tempting to stop at demonstrating that it works.

Image Credit: Jeremy Keith
https://www.flickr.com/photos/adactio/11685017/

But does it fail when it's supposed to fail?

Are you getting expected results only due to coincidence?

What happens when you give your program the equivalent of a dead salmon?

These are the questions that make the testing process take longer that it would seem on the surface.  Showing that "it works" is only a small part of the story.

Testers (and those who work with them): Watch this webinar!

"10+ Testing Pitfalls and How to Avoid Them", presented July 27, 2016 by Joel Montvelisky.  The meat of the webinar starts at about 7:20.  

I found it very soothing and common sense.

Developer/Tester Goodwill

I used a phrase in an email last week - "I don't want to burn my goodwill with the developers needlessly"

It just flowed from my fingers to the computer screen, so apparently it had been bouncing around in my brain for a bit.

Breaking this down:

1. I currently have goodwill with developers!  I approach them with the attitude that we are a team, that this is our garden that we're planting and watering and weeding together.  I value their hard work and appreciate the skills they have that I don't. My communications with them are not confined to bug reports.  I ask questions rather than accuse.  In return, they are honest with me and take time to explain details & to actually listen to my feedback instead of shooing me away like an annoying little sister.

2. Goodwill can be depleted More or less like a bank account.  I try to have a high signal to noise ratio, so that when I submit a report or say something in a meeting, it's because I've thought about it enough that I'm fairly confident my words belong outside my head instead of just inside. I google before asking questions that pull them away from their work. I don't preemptively criticize or barrage them with issue reports on a brand new feature.

3. There is sometimes a need to "burn" goodwill If it is important to product quality, and I'm having a disagreement or miscommunication with a developer on a point, I will pull in a third party to either weigh in or act as a referee.  I'll be increasingly blunt or say things in numerous different ways so that I'm satisfied all relevant parties understand my point.

And now, a song:

30 Day Testing Challenge - Day 16 - "Go to a Non-Testing Event"

I hope a wedding counts.  Because I'm going to a wedding! The oldest of my younger set of cousins....I was 10 when she was born, the perfect age for me to want to play with her and be responsible for her but to have no idea what I was actually doing.  She's a brilliant young woman and I'm looking forward to hanging out with my nerdy, awkward, funny family.

Not much progress on the other testing challenge days.  Does anyone else find creating mind-maps awkward?  Maybe my mind is just awkwardly shaped.

I registered for some webinars -- One about performance testing this week and 10 Testing Pitfalls and How to Avoid Them on July 27. 

I downloaded an app in which to find bugs: Swipe Four.  Ended up getting addicted to the game after one session and cannot return, lest I see words in my sleep or when I'm driving.  That's probably not a bug in the game, but in my awkwardly-shaped mind.

I didn't take a picture of my team or doodle a problem.  I'm always finding and complaining about user-experience problems in the world.  The process of ordering checks from my bank allows you to finalize and place an order, at which point it errors out and tells me to use their phone system to reorder.  I did this twice within a few days, just to be sure, since apparently I'd rather waste time going through an online check reordering process that I'm pretty sure will fail than have to make a phone call.   Oh that experience covers the E-Commerce site item also. 

Stepping out of my comfort zone: I haven't strayed *too* far, but I'm testing the waters every now and then.  I've been more assertive than usual in trying to solve process challenges that are leading to roadblocks/bottlenecks.  It's been both euphorically empowering and "OH NO THEY THINK I'M OVERBEARING"

Another comfort-zone item is perfection in my writing.  I have consciously tried to not rewrite sentences or delete entire paragraphs.  Extending my post from yesterday, one way I can make more time for writing is to have my writing take less time (whoa).  Stop dwelling over how everything sounds, whether it makes me sound timid or too enthusiastic, or too cliche. I'm not even re-reading this before I publish.  My comfort zone is far, far in the distance.

"How do you write like tomorrow won't arrive?"

How do you write like you need it to survive?
How do you write ev’ry second you’re alive? 

(source: http://genius.com/Lin-manuel-miranda-non-stop-lyrics)

I enjoy writing.  Since I'm a delay-of-gratification kind of person, I push my writing until after I'm done with my day-to-day chores like loading the dishwasher and getting a haircut so that I don't look so scruffy for my cousin's wedding this weekend.

But then I run out of time.  And my posts move from daily to weekly, then once a month is lucky.

I have to learn to be more selfish.

The lyrics above are from Hamilton the Musical.  I have been inspired by the song Non-Stop.  Specifically Hamilton's drive to put everything else aside except his learning and writing.  Writing is as important as food and water.

Learning new professional skills and approaches and then synthesizing them through writing is important to me.  It is more important to me than getting enough sleep every single night, getting to work on time every single day, being caught up on laundry.  So my allocation of time needs to reflect learning & writing as a priority, as a basic need like breathing.   I have to have faith that feeding this passion will reflect in my work and in all my other responsibilities. 

30-Day Testing Challenge, Days 4-7

Day 4: I did not share a testing blog post with a non-tester. It was a holiday in the US so I had plenty of time to read plenty of quality stuff (ooh, unintentional pun), but nothing seemed of general interest enough to rise to the level of sharing with friends who seemed more concerned with Kevin Durant leaving the OKC Thunder, parades, and fireworks. 

Day 5: Despite reading lots and lots of posts, I didn't comment on any of them.  Which stinks because that makes me a passive consumer instead of part of a conversation.  I commented a few days before that on The Testophiliac's Day 2 post

Day 6: The whole day was crazy...And it involved testing, so I guess that counts.  I spent the day at work deep-diving into Citrix, which is one of my favorite problem solving wins of my career. Lots of googling error messages, investigating network behaviors that turned out to be dead-ends, striking gold by finding clues in event logs, not finding the tool I needed to solve the problem uncovered in event logs due to a quirky permissions issue, and once the IT guy worked through that issue, it was smooth sailing.

And Day 7: Accessibility bug?  Sadly, I don't often think about it in the context of my work. I found a good resource here that describes the different approaches to testing and the different personas we can think about in our work.  Just knowing this exists will help me keep it in mind.

Other projects: Still reading Jerry Weinberg's Perfect Software book, did a tutorial on github the other night, played with CodeWars.com, and listened to the latest episode of the Testing Show, which is *almost* as addictive to me as The West Wing Weekly.

30 Day Testing Challenge - Day 3 - "Listen to a Testing Podcast"

I had to go back to May 11 to find a testing podcast in my subscription list that I hadn't listened to already: The lucky podcast is The Testing Show: Testing in the Broader Picture. 

It's 30 minutes of discussion on the role of testing.  The discussion meandered into many different areas...shifting left, the history of testing as a separate role in an organization, and being "in the room".   A lot of times we're viewed as the killjoy in the room if we're invited to high level strategy meetings...we burst the bubbles of those who want to do something and in a specific way.  Despite saving companies millions in time and infrastructure costs of pursuing a project we see heading for failure, we can be seen as mean, which makes us less likely to be invited to future meetings.  So choose your words carefully and offer alternatives rather than something along the lines of  "this idea is stupid and you're stupid".

Fits in nicely with a blog post I read this morning about using our words carefully and powerfully: Verbal Aikido for Product Managers.  The post includes the Winston Churchill quote "Diplomacy is the art of telling people to go to hell in such a way that they ask for directions".  Diplomatically steering people away from bad decisions and toward good ones is an important software testing skill.



 

30 Day Testing Challenge, Days 1 & 2

Day One of the 30-Day Testing Challenge is "Buy One Testing-Related Book and Read it by Day 30"

So yesterday I bought Perfect Software: and Other Illusions about Testing by Jerry Weinberg and am reading it on my Kindle app.

So far it's an easy, fun, interesting read.

Day Two is "Take a Photo of Something You're Doing at Work"...Well, I'm not *at* work, and I'm not really sure I can share anything directly related to my work anyway without violating tons of ethics standards (see, those training videos do work).

But I saw this on Facebook and thought it was a good photo and one that I intend to print and post at work.


Image Source:  https://www.facebook.com/InspirationalTardigrade/photos/a.486876521498909.1073741828.486875808165647/532044550315439/?type=3&theater

30-Day Testing Challenge -> I'm in!

I'm a sucker for challenges.  So far this year, I've used social pressure to drink more water, to organize my home, and read more.  I'm always participating in either the Workweek Hustle or Weekend Warrior challenges using Fitbit with my friends....I hate losing competitions even more than I hate walking, so it's been a benefit for me.  But beyond the competition, I know that we all care about one another's health and it's nice to have friends along commiserating with our struggles and offering mutual encouragement.

So I've signed up for the 30-Day Testing Challenge.  I don't think I'll participate every day; I'm pretty sure my team would check me in for psychiatric evaluation if I asked to get a photo with them...But the other days it'll be good to have a goal either to focus on or to have running in the back of my mind as I work. I anticipate a lot of conversation about this in the testing community in the coming weeks, and I want to be involved instead of on the sidelines.

First step is to find a testing book I haven't read yet!

Interesting Days Ahead!

On Monday, it was announced that the Dell Software Group is going to be acquired. The sale isn't final until a shareholder vote next month, so we have at least a few more months as Dell employees. After that, we don't have a lot of answers yet! The future is uncertain.

But that's true of every single day of our lives.

Most days are "normal" -- we go to work, we run errands, we love our families and friends.

Then there are those life-changing, incredibly un-normal days. A surgery, a diagnosis, a natural disaster, any day we get one of those unexpected phone calls.

We don't know when these days will happen or if they will happen at all.

Uncertainty is very much a part of our lives - we can approach this with fear or we can approach it with preparedness and a sense of adventure.

When Dell acquired us (StatSoft) in 2014, it was a great team-building exercise for my coworkers and me. We weren't sure what was going to happen, but we were going through it together. We have this shared experience and we still have conversations about those early days of transitioning to Dell. This experience made memories for all of us.

So through this uncertainty, I will do the things that we always should be doing, even on "normal" days.

Learn: Grow some new neural pathways. Get better at programming. Keep reading what is going on in the testing community and building some relationships with people I can learn from and some I can teach. Explore new testing frameworks.

Self-Care: We can't be employed ANYWHERE if we die from a heart attack. Get exercise, do the things that minimize stress. Build a community of family and friends who you can help when you're feeling strong and can draw strength from if you're down.

Stay Positive: Be a person you'd want to work with. Software testers definitely need to spend time looking at the *software* through a negative lens...but we can still actively search for good things and be vocal about them as well. Be a subtle cheerleader when your team needs it.

A Tester's Code

"When devising a strategy, she needs to take into account how well the developers test their code so she can concentrate on covering the less tested parts. She consistently checks the feedback cycle to see where it can be reduced. She looks at the length of the automated test runs and thinks of ways to reduce it; where to invest in integration tests, which give better confidence but are more costly to set up and debug; and how much manual testing is needed based on the number of automated tests."

-Gil Zilberfeld, Testing Economics, Stickyminds

Basically, be awesome.  Quick and stealthy like a ninja.  Anticipate needs and risk. Always know what your top priorities are and proactively ask the next person above you in the food chain if it's not clear. Make the product better.  Make the lives of everyone around you easier.  Be honest.  Be brave.  Be kind. 

Active Thread on the "The Abysmal State of Testing"

The abysmal state of ‘testing’ in 2016 - and what can we do about it? published by Rosie Sherry of the Software Testing Club. 

This thread has gotten a number of responses - Generally my takeaway is that we need to match our discussion with action and figure out a way to evangelize the benefits of a strong testing team.  I know there is a lot of activity in this area, but each of us testers needs a succinct, inspiring summary about what we do and why development and customers should care.

Reminds me of the excellent talk "Telling our Testing Stories" by Isabel Evans that I had the pleasure of watching on the STAREAST 2016 live stream.

It's up to us to prove our value. And to be our best (alert, curious, educated, assertive, team-player) selves so that we actually *are* of value. 

Ten Year Plaque!

Like most major milestones of my life, it's a time of reflection.

I was hired by StatSoft in April, 2006. I was so nervous for the interview and so thrilled to get the call late on a Friday afternoon that I had been offered a position.  Statistics + software + getting paid = My dream job.  It has been challenging, fun, and almost never boring.

Dell acquired StatSoft in 2014, and happily they credited us with our years of service from StatSoft for purposes of vacation time and apparently nifty plaques.

In the words of President Bartlet, "What's next?" Well, I'm glad you asked.

• Stay up to date with current trends and conversations in the software industry
• Advocate within the organization and to anyone else who will listen about software quality and strategies for achieving and maintaining quality. 
• Become proficient in Python 
• Read, read, read.  Become knowledgeable enough to have opinions and to back them up with data or examples. 
• Be proactive.  Speak up to make sure stakeholders know the relevant bits of information and my overall assessment of the status of product.  When important conversations about the product are being held, making sure I'm in the room so that I have all the information I need to make good decisions about where to focus my time. 
• Attend a software testing conference.  It will never be convenient to miss work or to be out of town, but short-term sacrifices are sometimes needed for long-term growth. 

Tulsa Agile Practitioners Meetup

Last week, I made it a priority to attend a meetup group that I had been wanting to visit for a while: 
Tulsa Agile Practitioners (TAP)

It was conducted in an Open Space format - with several topics on the wall with a person willing to lead a discussion.  Pick a topic, find a chair, sit down, listen, and talk.

The conversation could have lasted hours or days, however long the donated Chick-Fil-A supply sustained us. 

My group didn't talk directly about Agile.  We talked about software quality, approaches to advocate for the craft of constructing software, approaches to adding value that can't be automated or easily outsourced...It was nice to find a group of folks in town where Uncle Bob is mentioned casually like he's an actual relative, you overhear things like "Clean Code changed my life", and people crack wise about using Agile principles to put the meeting room tables and chairs back together to their original state. 

A+, will attend again.

UX checklist for desktop applications - Microsoft MSDN

Found this to be a fun, if perhaps overly nit-picky read.  I will cite it in the future if I need to justify a preference I have about a dialog or other UX element. 

UX checklist for desktop applications

I won!

I'm a frequent attendee of RBCS webinars.  There was a presentation on Monday titled "Why Does Software Quality Still Suck" which I listened in on (video here).  Rex Black fired another shot in the testing standards war, which I'm looking forward to hearing some context-driven responses on.
For each of Rex's webinars, an attendee is chosen by drawing to receive a free e-learning course. I won!! That's two exclamation points, indeed. So for the next three months, I'm going to immerse myself in the ISTQB Certified Tester Advanced Technical Test Analyst E-Learning training course.  

Testing and Testing-Related Books

Ten Must Read Books You Didn't Know Were About Software Testing

I've read several of the testing books but none of the other list of recommended books.  I've seen Thinking Fast & Slow recommended on almost every similar list so I really need to make that my next read.

I'm a huge fan of Pragmatic Thinking & Learning and Mindset so I always mention them when the discussion turns to recommended reading. I've applied both in the context of my job.

New habits

Once you've achieved competence and a reasonable tenure at your job, it's easy to rest.  You have valuable institutional knowledge that newer workers don't have, so it's easy to feel "smart enough".  Furthermore, feeling "smart" is awesome. 

But what's next?

Stagnation, unless you intentionally plan otherwise. 

I've been tinkering with scripting for years.  It's a great rush when something works correctly.  But when it doesn't...and when Google searches turn up nothing, it's easy to be content with what you have.  That was probably too ambitious for me to try that in the script.  Manual testing is just fine for this.  I don't want to waste someone's time by asking them -- they have better things to do, and what if they think I'm stupid?

1) Ask the stupid question. 

I'd suggest email, so you don't interrupt someone "in the flow" -- and a preface of "this is not a high priority, but I'm curious if you know how to do X, or if you've ever encountered problems with X and could share any tricks"  Add what you've already tried, so that it's not something they sigh about under their breath and wonder why you didn't just google it. 

They might think you're stupid, sure.  But probably, that is in your own head.  And they'll be flattered that you ask them.  And they might learn something from you that will make them better teachers in the future.  

And, most importantly from my perspective, you could learn something from them that makes you more valuable.  They could show you a technique that opens up all kinds of possibilities for problem-solving in the future. You solve more problems and faster, and now are a vector for spreading this knowledge if someone else has the same problem in the future. 

2) Ask for feedback. 

Show people your code/your work.  People who know more than you do.  If you're a fixed-mindset (by default), people-pleasing person like I am, this will make you want to throw up.  But, it will make you better.  It's like having a personal trainer available to tell you "You know, you are doing that exercise all wrong.  People are probably laughing at you behind your back, and worst-case, you could snap your spinal cord".  Except with code.  It can break you of bad habits and learn to do better work more efficiently. Even if what you're doing *feels* like exercise and the end result seems the same, it could be working by coincidence or doing something unintentional and awful very quietly.  

Professional Miracles

Today marks the 7th Anniversary of the "Miracle on the Hudson".

This story inspires me every time I think of it.  I want to totally rock my job like Sullenberger rocked his job that day.

There are three takeaways from that day for me.

1) Learn different strategies for problem-solving.  Know when to use them and how to pick the best one.

2) Practice.  Get really good at applying what you've learned so that it becomes automatic when it needs to be.

3) Seek out opportunities to be useful.  If Sullenberger hadn't shown up for work that day, maybe Flight 1549 would have had a different fate.

My Story

I grew up with no particular career in mind. I did well in school but I never saw a vision of myself as an adult.  I remember being asked in the second grade and I replied real estate agent (because my parents were) or a teacher (because I like school).

Later on I wanted to be a meteorologist because the tour I went on at OU was cool.

In high school I replied Economist, even though I'd never really had any economics classes.  I did well in math and chemistry. For some reason I never considered math as a career path and if I had just asked the question or been given a nudge in this direction I may have gone down that road. 

I took some chemistry in college but I imagined that thinking about molecular structures and being in a lab all day would be boring. 

Psychology and psychiatry were options, mainly because I'd had my own experience with mental illness that I hadn't quite worked through yet.  Going to medical school scared me, since I felt like I would always be second-guessing myself and berating myself over any mistake and agonizing over each patient 24 hours a day (see my mention of mental illness in previous sentence).

Psychology research seemed fun.  I took Statistics, Experimental Design, Intro to Personality, Abnormal Psych, and worked in a Psych Lab for a year.

I enjoyed making web pages but for some reason didn't consider that I could do that as a full time job and not just as a hobby.  

Political Science seemed fun.  I worked in Washington DC for a summer and got a little jaded with that.

The next summer I worked as an intern for a state-wide housing study.  I enjoyed traveling to small-town Oklahoma and hearing the stories of what was going on there.  There were cities that had a lot of hope and were working to bring businesses there; there were cities that had given up and were just waiting for their old people to die.


I did take lots of Economics, which ended up being my major as I predicted as a clueless high school student.  I ended up with minors in Psychology and Political Science.

I graduated without a clue as to what I wanted to do.  I liked Economic Development but it seemed like it required more of a Sales personality than what I have. I was extremely burned out on school due to my perfectionism.  I was terrified of making the wrong choice for a Masters program so I made no choice.

I moved to Tulsa from Norman to work with one of the companies that was involved with the state-wide housing study I worked on the summer before.  I was a commercial real estate appraiser and market analyst.  It was data-heavy which was fun. There were aspects of real estate appraisal that were not me, however.  I was Not Happy.

So I remembered that I liked web pages and started thinking of that more broadly.  I took some programming classes at TCC in the evenings so that I could use that part of my brain and maybe make an escape plan.

I eventually found my first IT job, which later let me jump to my current position of testing software at StatSoft/Dell.  StatSoft was acquired by Dell in 2014.  I call it my dream job.  It combines my natural OCD + analytical personality tendencies with the Math I loved but didn't know I could do anything with with the Statistics I loved but didn't know I could do anything with with the computer programming I had failed to consider as a possibility.

As I plan for the future growth of my career, I try to keep aware of the latest trends in each of these fields.  I know a little something about many things but deepen my understanding as much as I need to depending on the project I'm working on.

I *still* don't know what I want to be when I grow up, but I'm beyond happy right now with a career that lets me get immersed in both the technology and the subject matter.