Thursday, April 30, 2015

Don't be a Cow

In early April I was reading some various articles and blog posts when I stumbled upon this quote, “I have a very strong opinion that there is no place for manual testing in the industry whatsoever - manual being testers who are told to spend days following test scripts.”  Scott Noakes - CEO of Linewize

This is one of those quotes I think you have to carefully interpret.  If read rapidly you conclude he wants all manual testing eliminated.  If you read the quote carefully he has a specific definition for manual testers.  Manual testers are people who are "told to spend days following test scripts".

I think Scott Noakes has it right.

Testers should not follow a script, but instead challenge themselves to leverage their cognitive skills.  A scripted path through a software application will most likely land you at the same spot every time.  It is a testers job to deviate from a path to go where no one has explored before.

Chapter 12 in "More Agile Testing" by Janet Gregory and Lisa Crispin will show you a newer definition of manual testing.  The chapter focuses on an investigative style of testing.

Testers should be adventurers, explorers, and scientists.  We should not follow a common path. Are you being told to spend your days following test scripts?

I encourage you to find alternative approaches.  You should read "More Agile Testing".  You should also read more about Session-Based Test Management.

You are not a cow, but a human with a brain.

Happy Testing!


Sunday, April 26, 2015

"There's a hole in my soul"

Late last year our family went to see Bastille at the Cedar Park Event center.  As I started thinking about this post, I thought of their song "Flaws".  The title of this post is one of the lyrics.  I am finding recently that there is a hole in the soul of software testing.

I have conducted numerous job interviews for software testing candidates.  One of my common questions is "What testing books have you read?" or "What testing blogs do you follow?".  It pains me to say, but very few of the candidates have an answer.

"Are you familiar with Context-Driven School of software testing or Session Based Test Management?"  I am constantly surprised that the answer is NO.

"I see you have listed Selenium and Cucumber on your resume, please tell me about those tools."  And I get extremely vague answers, "my team uses those tools".

So the moral of this story is quite simple.  If you want to be a great Software Tester, Quality Engineer, QA Engineer, SDET, or  another career title in the field of software testing, you had better start paying attention to your craft.

There are tons of brilliant people out in the Software industry fighting to move testing forward through innovation and conversation.  Please join the conversation.

If you are going to put a term on your resume, you had better damn well know something about the term.

Please read a book or two on you craft.  There are plenty of great books available.

I participated in a discussion lead by Matt Heusser in Dallas a few years back at Software Professionals conference.  The debate was centered around, "Is Software Testing a Career".

"Hell yes!", Software testing is a career so help foster your career by participating in the industry.

Software testing rocks; however, "There's a hole in my soul, Can you fill it? Can you fill it?"  

Sunday, April 19, 2015

Experiments

Last week Teslio posted on Twitter this link, "How to Become and Efficient Tester".  Here is the list of primary points.

  • Organize everything
  • Write detailed bug reports
  • Write clear test cases  
  • Take part and communicate
  • Ask yourself questions
  • Be positive.
  • Don’t test
In general I agree with these points; however, I would like to explore the third bullet point in a bit more detail.

For me the term "Test Case' has become somewhat poisonous.  It flashes me back to the days of using Rational Unified Process, RUP and Word documents full of word density.  Today I find myself trying to avoid the words "Test Case". 

Right, wrong, or otherwise I prefer Test Idea or Charter. Both of these terms come from Session Based Test Management articles I have read over the years. Unfortunately the term Test Case is probably here to stay, so let me attempt to redefine the term from my point of view.

Test Case - an idea worth an experiment

So what is needed to conduct an experiment?  We need a hypothesis (Mission).  We need some contextual idea of the variables or inputs.  We need a control (Oracle).  We may need some mental tools (heuristics). We may need some physical tools too.  Then after conducting the actions we need observations and results.

I do not believe we need a list of detailed steps as described in Willie Tran's article.  Based on our observations and results we may have to repeat the experiment, so it is important that in your results you describe your journey and decisions you made along the journey.  I encourage testers to not write a detailed list of steps, because they may cloud the experiment.

Happy Testing!

Sunday, April 12, 2015

Wearing Multiple Hats

This week there was an interesting exchange of thought on Twitter.  Here is a subset:

  1. Once again, testers: WE DO NOT PREVENT DEFECTS. We provide insight and information that can help other people to prevent them.
  2. Did you change the code yourself? The design? Or did you help the person(s) who did?
  3. ... In some cases. In others I did not. Is writing code the only way to prevent defects?
  4. Of course not. But let's be clear on who has responsibility and authority, and let's be appropriately humble.

I definitely like the aspect that testers provide insight and information.  Where this exchange sparked my brain cells was with respect to responsibility and authority.  Unfortunately I think there is a tweet missing where Matt Heusser talks about preventing a defect by fixing some code himself and committing the fix.  I think this is where Michael Bolton injects responsibility and authority by stating Matt was in the developer role and not the tester role.

This distinction caused me to think about what role might I want to play.  I think I want to be a "Team member".  Sure I think the skills I bring to the table is that of a tester's mind, but I also have other skills. I want to always apply each of those skills in the context of a Team.

I think Michael's point is that the actions taken can be bucketed into roles and that point is fine.  What I want to see happen is we reduce the dependency on roles and focus more on creating great teams with a diverse set of skills.  At Agile Testing Days 2014 Janet Gregory and Lisa Crispin talked about the T-Shaped tester.  A diverse set of skills with depth and breadth help form great teams in my opinion. Everyone can contribute in a spontaneous manner to build great software.

One of the battles I have seen over the years is the siloing or segregation of roles.  I would rather see the lines blurred.  This morning I read several articles in the April addition of Testing Trapeze.  I felt this quote in an article by Michael Trengrove resonated more closely to my point of view,   "Testers writing code, and programmers further developing a tester’s mindset.”

The quote itself implies a set of roles; however, I think the roles should be merging and applied.

In the Trengrove article I think there is another quote that also describes my point of view.  The development Director fo Orion Health, Jan Behrens states, “Today the biggest benefit of having test professionals embedded in cross-functional development teams is not that they are the ones doing all the testing but, similar to an architect or a business analyst or a UX designer, they have a particular set of skills that they help the whole team to apply.”  

My position is we should continue to blurr the lines by sharpening all skills and knowledge of all roles.  I greatly appreciate the acuteness of which Michael Bolton makes distinctions and those distinctions are important.  I prefer to wear multiple hats; however, relative to the context of the situation it is important to know which hat you have on!


Happy Testing!

Sunday, April 05, 2015

Working as Designed, Really?

I recently saw a Facebook post from a family member.  At first I thought it was a really good April Fools joke, but honestly I am not sure.  The post was showing off a new tattoo.  I did a double take. Is that word spelled correctly? After several sanity checks or explorative tests I realized for sure that there was a typo on a tattoo.  This is a permanent defect or at a minimum will take an extremely complex and perhaps painful solution.

I think the same thing happens in software.  The unfortunately side of this happening in software is we simply mark the defect as "working as designed" or "will not fix".  What if the defect does permanent damage to the customer?  Certainly it will be expensive to redesign the system, but perhaps that is the right thing to do.  Marking something as "working as designed" with out carefully consider the potential for a design flaw in my opinion is a mistake.

Often the resolution working as designed puts a tester in an awkward position.  The tester either advocates for the right action to take place or has to carefully craft an excuse to deliver to the customer.  I have experienced situations where the proper resolution is a complete system redesign and could take a very long time to resolve.

I think the worst part for me is that sometimes someone will set a resolution to "working as designed" when they know deep down it is simply an excuse, stating  "I will let someone else sort this one out".  The burden typically falls upon the tester to put on their advocate cape on and begin the battle for the proper resolution.

In the case of the tattoo spelling error, I do not have the guts to report that to the tattoo owner.  I guess I also fell into the trap of "working as designed" and not advocating for the proper solution.

Let's build software right!  We should spend some time evaluating the defects in our system that were marked as "working as designed" or "will not fix".  We might just find a misspelled tattoo.

Happy Testing!