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