Applying clichés to challenges…

Over the past couple of weeks I have come across a few challenges… some in work, some in personal life…

• How I respond
• How I react

Dad always said, “respond, don’t react”…  This is good advice, but, in keeping with The Gambler...  you gotta know when to do either…

 

I got to thinking about this advice in light of the few challenges that came my way… I know enough about myself to know that I gotta keep my “over-thinking” in balance...  and I know enough about myself to know I have the tools to figure it out...  or who to ask for help when I need to…

 I think I really like challenges...  even if sometimes my fight or flight is really a hide-my-eyes and hope it isn’t a really there situation...  I like these challenges because they force me to grow.  They force me to look inside and outside myself for a solution.  They force me to learn more about what I do and why I do it.

A couple of these challenges had some common denominators in my mind:  a couple of my old, favorite clichés… How do you eat an elephant?... and KISS.

 I got to thinking about both of these at the same time… How do I keep it simple if I am trying to “eat an elephant”… are you kidding!?!?

As I began to “eat the elephant”, and think of how to keep it simple, I came across a couple things I would add to the “eat the elephant” thought…

What don’t I even need to consider “eating”? 

*Note:  I would never really eat an elephant… so please do not even consider it an option… this is all just philosophical... Side Note... elephants are one of my favorite creatures on the planet :)  If you have no understanding of elephants... please read about them... they are awesome creatures!

I do not need to consider eating the bones.

I do not need to consider eating the contents one removes prior to cooking.

I do not need to consider eating the parts that are in-edible.

So, all I really must consider is what is left after removing these things.  It certainly takes the size of the task in question down to a more do-able size… a size I can now bring under the KISS Principle… And, if necessary, I can now host a banquet to invite my friends (stakeholders, peers, fellows, etc.) to assist in the eating of the elephant.

I guess I have learned that sometimes it is not just the BIG PICTURE that I come up with that matters… and the WHAT DO I NEED… but sometimes the pattern of thought for a big challenge should be WHAT DON’T I NEED… sometimes that will keep the focus on finding solutions that meet the need, whether it is project or personal… What doesn’t matter enough to put added weight to the equation? 

Sometimes, when something seems to big, it is better to begin to consider what doesn’t matter before determining what does matter... 

“How Google Tests Software”… my thoughts…

I have managed to find the time, between all the “hats” I wear, to read 90% of How Google Tests Software.   When I say between all the “hats”, I mean between being a tester, being a mom, being lots of the things that I am and do…   When I say managed to find the time… I gotta admit…  James Whittaker writes well… I realize he did not write the whole book, but his writing keeps me listening to what he is saying… he is really a good story teller to me… he makes me think… he keeps me as an engaged audience member…

I finished the majority of the book today while I was getting my snow tires changed over to summer tires at a local shop…  Most of which I started while waiting for other things… Sometimes you gotta use your “wait time” for things you want/need to catch up on…

Since this book was about Google, I admit I critiqued everything I came in contact with… From the cover design… to what I think were overlooked editing mishaps… I could get into things I found with these, but I won’t…  I found too much to think about…

One thing I have been thinking about, and will continue to think about for some time forward is Attributes>Components>Capabilities… you will have to read the book to find out more… or find a “cheat sheet” elsewhere…

A warning to some things… some of the book points out Google tools, and the fact that they will be available to the masses at some point.  However, I had to look past this and into what there was for me to contemplate -  in my own position… but, maybe these tools are what you might have on your own shopping list in the near future…  so maybe you should read more about them.

I recommend reading this book, thinking about what is being said, and coming to your own conclusions in your own position… and discussing your thoughts among your peers…

I guess I was kind of pre-conditioned to “think” that this was going to be another book on “best practices” (based on my own biases), but I have decided from reading it that it really is about what Google does…  and how they have changed what they did to what they do in order to better serve those involved…

I don’t think this is the Google Bible On Testing… but a work of how they have come to determine what matters the most for where they are currently…  And I have no doubt this will change as they look for more things to improve upon.  I guess I am surprised by my conclusion on this, and surprised at what I read…

I am glad that I bought the book – hard copy, with real pages – and I am glad I have read most of it… I will get to the missed, grayed-out areas in the near future…  I have no doubt there are some interesting nuggets in those areas as well.

I'm Soooo Excited!...

I have been so busy the last few months that I have begun to notice a bit of a drain in my brain...

When I notice this, I know it is time to find something to stimulate and soothe the cells that are beginning to feel somewhat lacking.  I started doing word games whenever I had a free moment, and, while this helped some, it wasn't really what I was looking for...

I read a couple books that I had not previously read, and, while that helped some, it wasn't really what I was looking for...

I have begun to get into a new hobby - tying flies for fly-fishing... And, while this is really gonna make me have to raise my own bar in fishing - I need to learn how to fly fish in order to use the flies I tie... I have to wait a bit before I can start this new venture... so, again, it didn't really catch what I was looking for...

Last week I decided that it was time to take another online class, or contemplate taking one in a local community college.  I wasn't sure what path to head down, what I wanted to learn, but I figured I would find something...


While I was debating this, I took some time to read some of the blogs that I had been neglecting during my busy time... And, then, it hit me... I found what I was looking for... I found the answer to my quest...

Rapid Testing Intensive!

I am soooo glad I did not miss the time to sign up for this course.  And, while I wish I could go to the onsite course (what a beautiful place!), I do also know that, since I already work "as a remote tester on a busy project team", taking the course online will benefit me more... 

To me, this is a wonderful opportunity to expand upon what I was already taught by Michael Bolton when he taught our test team the Rapid Software Testing course a few years back... 

To me, this is a wonderful opportunity to engage with other testers who desire to build their own skills and learn, at least as much as I do.  And... from all over the planet as well... 

While I have already shared my exciting news with those less likely to be excited with me (my kids really just don't get it)... I thought I would share this exciting opportunity with you as well... In case you too have been so busy lately that you might have not gotten the word... 

Did I mention that I'm soooo excited?!

Sometimes… I don’t want to ask more questions…

Sometimes I just want someone to give me the information I need…

It is times when I feel like this, that I think about writing bug reports…

As I see it, my job is to report information about potential risks and problems, to ask questions about a product/application/system, and report those questions as bugs, if they seem to be incorrect.  However, I add to myself a caveat to this job, with all I can muster up, I don’t want anyone to have to come back and inquire anymore about what I wrote up.  I want/strive for my reports to be succinct.  I don’t really want to have a bunch of questions coming back at me about them; I am usually on to another area that I need to investigate…

Very rarely will I write a bug report that I cannot stand behind.  I may not be able to (nor have the authority to) describe what “should” occur, but I really try to get as much information as I can into a report before I will submit it.  What does this usually mean?

Again, I refer back to the journalist in me: who, what, where, why, when, and how…

To me, these are more than a guideline, they are a code.  I don’t want someone to have to come back and ask any one of these questions to me.  It does happen on occasion, my blog title is my acknowledgement of this:  UE: Tester_LostFocus (my own error, unexplained – UE – but I lost focus of my goal in writing or investigating or reporting, I missed my mark).

I spent a great deal of time today in asking questions… I think I have a bit of empathy towards developers who receive less-than-good bug reports… I think I thought of a few new things because of it today…

Not all people can effectively communicate in written language by nature.  Some need to practice; others need to find another way.  With the technology of today, you can find another way to communicate, or rather ADD to your written communication. 

First, be detailed… be “anal” about this… it sometimes makes the difference in whether or not a bug “should” be fixed, or should be set aside.  Maybe something “bad” happens only if you do XYZ first, but never does outside of this… And maybe that is not how the application/product/system is used by your customer… or… maybe it is how it is used…

Second, work on these skills… notice what you miss, make sure you strive to NOT miss it next time

Third, remember you are part of a team.  You don’t want to make anyone else suffer because you do not give additional information you haven’t thought was important… all the pieces make a puzzle… missing pieces make an incomplete picture.  To the stakeholders… time is money… every minute spent chasing down your issue is money not spent on the next cycle of development… If you cannot think of it in terms of development, think of it as your raise for the next year…

Fourth, add a video capture/screen capture if you think your words are not enough… there are lots of apps out there for this, some are built right into testing tools… use them if you have to… don’t “rely” on them so much that you forget you should try to “not” need them…

Your job is to try to ensure no developer ever needs to ask you about your report… but rather to ask about your day, if they happen to have the time….

Your job is to try to ensure that if a stakeholder comes to your department and says, “Why didn’t QA/the Testers find this?” to be able to say, “We did, please see bug/report number XXXXX, but it was decided to not fix this”.

If you are new to this field, I recommend reading about things like:  philosophy, psychology, UI, UX, writing, reporting, and investigating.  Don’t stick to just software development and how to understand your own PC or the technology of today.  It takes this, but it takes more.  It takes “understanding” what your goal is…. Your goal is to report information… to the people that matter… in a way… that counts… that gives the most “bang for your buck”.

Note:  My definition of a bug comes from my lessons learned through the Rapid Software Testing course… which I hold true to my own convictions… You can learn about that, among other things of value to your testing skills, here:

satisfice.com

developsense