Friday, December 11, 2015

Keeping Up with the Times

Yesterday I conducted two phone screens seeking Senior Quality Assurance experts for a 6-month contract.  They were both great candidates with traditional testing skills and passion.   I am not responsible for hiring these individuals but to offer my assessment.  My conclusion was that they have the skills necessary to do the job.

Here is what alarms me.

  • Neither one has recently read a Testing Book
  • Neither one follows testing blogs
  • Neither one ever heard of SBTM or RST
  • Neither one seemed to participate in local testing community or meet-ups
  • Neither could write code
  • Both assumed documentation exists
  • Both assumed there were people available to help them
So I have a one-word message to all testers around the globe.

Participate!

We have a thriving and pioneering global testing community.  We need everyone to continuously improve our craft by being involved in the learning.

Is my perspective misguided or would you agree?

Happy Testing!

Tuesday, November 10, 2015

Two words making me cringe these days

Lately, two words have been making me cringe.  I am not 100% sure why I am having such a negative response to these two words.

Ready - Test Plan and Test Cases

With respect to the term test plan, my memory conjures up a negative image of lengthy Rational Unified Process documents.  In my mind, I have started replacing the term test plan with the term test strategy.  I outline my test ideas in a mind map.  Using a mind map is fast, flexible, and easily communicated.  I share my test strategy in a mind map.

If I reflect in a neutral way, I conclude that test plan and test strategy are interchangeable.

I think the term test cases causes me to cringe because they were part of the RUP test plan documentation. The term test case conjures up the negative image of scripted tests.  Following a detailed set of steps never seemed productive for me on my mission to find bugs.  I followed this practice early in my career, but it does not make sense to me today.  Mentally I have substituted the term test ideas to replace test cases.

The words themselves are fine.  I need to make sure I articulate my definition when they terms are used in conversation.

Anyone else of a POV to expand upon or refute my negative taste for these terms?

Friday, October 30, 2015

Veterans4Quality

Yes, once again I have been a slacker regarding blog posts.  Some recent events are worth mentioning.

I am extremely excited that I have been nominated and selected as a Board Member for the newly formed non-profit, Veterans4Quality.  We are getting things off the ground, but the 30,000-foot view is that this organization provides training to Veterans on how to test software.

Last night I had the pleasure of being an instructor for this graduating class.  They are such a great group of people.  I hope they got some value from the class because I certainly did.

I hopefully introduced them to some tools they had not previously been exposed too.  Here are the topics that I covered:

  • Schools of Testing, highlighting Context-Driven
  • Mind Maps
  • Heuristics, distributed Elisabeth Hendrickson's cheat sheet
  • Oracles
  • Mnemonics
  • Charters
  • BugMagnet
It was interactive and a really good dialog.  

One student/comedian in the room stated he did not like the XMind tool because it had a template for a "Honey Do List".  Later he kindly pointed out that I was not using autosave functionality for XMind.  I certainly took note.

I had a blast sharing my experiences with this great group of Veterans.

If you are a software company in Austin texas, these Veteran's are looking to cap-off their education with a 90-day internship, so please give them a shot at a bright future with a career in Software testing.

  • ‘internships’ are 90 days – NO STRINGS for extensions or hiring
  • Companies can bring them in direct as 1099’s (which you did at HomeAway) or Veterans4Quality can bring them in as 1099 and be the ‘bank’ for the companies
  • Min. rate $18
  • Start date – fluid – in that we’d like them to start by week of Nov. 16th
  • Contact me for more details or questions  [Brenda_Hall@Bridge360.com]
@Brenda - Thank you for this awesome opportunity!


Sunday, August 23, 2015

What did I learn at CAST 2015?

I attended my fist CAST in Grand Rapids, MI.  What did I learn?

I learned that it takes an extremely dedicated group of people to run an organization such as AST.  Several key board members were stepping down while a new set of energized members were stepping in.  Unfortunately, I could not vote, but looking in, the election process seemed balanced, quick, and successful.  I would like to thank the leaders stepping down, Michael Larson, Markus Gartner, & Peter Walen.  I would like to encourage the new leadership who are dedicating their time, Eric Proegler, Ilari Henrik Aegerter, and Roxane Jackson.

I learned that it takes a ton of dedication and energy to pull off a great CAST conference.  What a fantastic job by Peter Walen.  He had a few bumps in the road that very few would even know who occurred and he handled them like a magician.  I do regret that I did not find the time to have a cold beverage or two with Pete, but he was busy and the conference energy was high.

I learned that facilitators "ROCK".  This conference leverages the LAWST style of running a meeting.  Every participant had unique cards (red, green, and yellow).  The participants used the cards and the facilitators keep the process organized and meaningful.  Red cards were for urgent questions or concerns.  Green cards were for new conversation threads.  Yellow cards were used to keep an engaged dialog moving.  I would like to thank all of those who volunteered, especially Alex Bantz, who facilitated our session.  Every conference should consider this style of facilitation.

I learned that activities that were tangental to the actual conference were crucial to the learning experience.  I met some amazing people sitting on the couches at the hotel.  I have great conversations over meals.  One of the most amazing conversations was in the hallway with Karen Johnson.  I learned a more effective way to hold Lean Coffee.  I would like to thank Matt Heusser for facilitating the Lean Coffee and those who actively participated.

I learned that there is a lot going on in the field of software testing and that there is a ton more to do.  I am currently trying to figure out how I can help make an impact.  Honestly, I have a ton of reflection to do to figure out where I stand on some of the issues.  This is definitely a future post.  One of the key takeaways for all to consider is that we need to do a much better job of education in our profession.

I learned that our profession is a bit fragmented in approach and opinion.  This is also a future blog post, but after some reflection I think this is a healthy situation.

Conferences can be exhausting!  If you are fully engaged and attempting to maximize your experience, you should be exhausted.  I was totally exhausted, but I am looking forward to my next conference.

I have a ton of things on my mind because CAST inspired me.   Hopefully, I will find more time to write these thoughts.

Happy Testing!

Sunday, June 14, 2015

Where is the WWW headed?

I found an opportunity over lunch last week to catch up on my blog roll. So I came across this blog by Michael Bolton.  I really feel and share in his frustration.  Our family budget is accomplished by Mint.com.  Several months ago our bank a local credit union changed their website.  The impact was actually quite severe in that now our checking account does not import into Mint.com.  We have had numerous email threads with both Mint.com and our bank.  Here it is 3 - 4 months later and the issue still has not been resolved.  I have offered to work with their developers to help troubleshoot the problem, but they will not take me up on the offer.  The bank claims it cannot be their problem and Mint.com is a free software, so why should they care they have destroyed a families budgeting process.  The options we now have to consider are leaving a bank with have been with for 30 years or abandon Mint.com.  I do not like either choice because this integrated solution should just work.

I get gas at several local convenient stores.  My blood pressure goes up when I read the digital greeting on the pump and the last letter of the final word appears on line 2.  Such a trivial bug, but it bothers me.

I was interacting with Lanette Creamer via Twitter.  She made this statement that resonated with me a bit; "Have you seen the case yet where they are literally building faster than they can detect sanity? Dropping a deuce on the user."  I really think she is on to something with this statement.  In the effort  to deliver software faster, companies tend to fail the primary users.  Isn't the entire purpose of delivering web applications to delight the customers?

Lanette also made a great post on LinkedIn.  I thought it would be cool to leave a comment on her post.  I was not able to leave a comment.  I tried several browsers, so I sent Lanette my comments via Twitter.  Anyone reading her article will not have that context.  LinkedIn was following the Twitter conversation, so at least they were actively aware of the problem on their site.

Is the internet getting better?  Is it heading in the right direction?  This short analysis would indicate the internet is not headed in the right direction.  Companies are not making their audience happier.

I still believe we can rapidly deliver great software, but we need to do it with the customer in mind.
Michael Bolton and Lanette Creamer are passionate people who care and want customer experiences to be better.   We should all desire great experiences and we should let these companies know.

Happy Testing!

Sunday, May 31, 2015

TestRetreat - Grand Rapids

I am planning to participate in a Test Retreat in Grand Rapids on August 1, 2015.  Test Retreat is an event formed by Matt Heusser two days before CAST.  What is Test Retreat?

The truth is I do not know what Test Retreat is.  Then why participate?

  1. I was invited.
  2. I am participating in CAST
  3. The Retreat takes on Open Spaces format
  4. Smart people will participate
  5. I will learn something valuable
Being invited is an awesome thing, because I have collaborated with Matt several times in the past. Each time we have collaborated I have learned something new.  I also become energized and inspired.

I have never participated in CAST, so I think this retreat is a logical extension of the learning experience CAST will provide.

I love the open spaces format.  The reason is that it allows for a gathering where smart people decide the agenda organically.  I was introduced to the LAWST format in 2007 by Bret Pettichord.  Brett continues to use open spaces style formats with his Test Bazaar and other events.  I have also seen Matt use this style for a panel discussion at STPCon in Dallas.  When people build the agenda, I believe the right conversations happen.

I have learned so much over the past 8 years by trying to surround myself with people way smarter than me.  An additional attribute is that these smart people have passion and drive to make the software industry better.  I believe I share that passion and drive, but often we need new ideas and tools to pivot the industry in the right direction.  We accomplish this by discussing topics with smart people.

I believe four times in this short post I have used the word, learn.  That is exactly the reason I would love to collaborate at Test Retreat Grand Rapids 2015.  I plan to continue my education journey.

If any of these reasons inspire you, please let me know so we can invite you to the Test Retreat.

Sunday, May 24, 2015

Honor Your Veterans

I feel very blessed to have met a wonderful person a month or so ago.  Her name is Brenda Hall, CEO of Bridge360.  Her company has put together an amazing program that teaches Veterans to test software called Veterans4Quality.  I highly encourage all companies to offer these service men and women an opportunity to expand our global testing family.

In my opinion this is such a great opportunity to introduce passionate and talented people into the career of Software testing.  Please consider giving these graduates a 12-week internship at your company.

As a bonus blessing, we have an extremely talented daughter who soon will be going off to the Ringling College of Art and Design.  Here is an art piece she submitted to the Women's Auxillary of the Veterans of Foreign Wars, VFW.  She received a scholarship locally for this piece of art, and it is now at the state level.  My new colleague and friend Brenda Hall also shared this at the Whitehouse a few weeks ago.  Enlarge the attached photo to see the magic.


I would like to end this short post with a huge THANK YOU to all of those great people giving military service around the globe to bring peace to our chaotic world.

Sunday, May 17, 2015

Getting Started

A colleague asked me one morning how his friend could go about getting started in the field of Software testing.  Thanks to his astute note taking, here is the list I had apparently provided.

Take the Online courses at the Association of Software Testing:
Testing – Black Box Software testing is approximately $200 course that you can take online that will give you a good overview of the “Context-Driven School of Testing” which is the direction many companies are moving towards.

Start learning these technologies for Automation:
You can use the Selenium IDE http://www.seleniumhq.org/download/ to record your actions on a web page and it will auto-generate code based off of that.  This is just to get started and familiar, then code on your own after that.
JMeter - http://jmeter.apache.org/  Can be used for performance testing, API testing, and DB testing.
You can use BadBoy http://www.badboy.com.au/ to record your actions in java and it will auto-generate code based off of that that you can use as a base.  Note that BadBoy is Windows only and may not currently be maintained

For gaining testing experience:
If you want to try testing to see if you would like it, you can sign up at http://www.applause.com/ or http://www.utest.com/ or https://testlio.com/ and get real testing assignments that you can get paid for on the side.  A good way to learn testing and see if you enjoy it.
You can also play with some test puzzles at http://www.testing-challenges.org/tiki-index.php

For networking:
There is also one he mentioned that is run by one of the QA leads Ben Rogers  - http://www.agileaustin.org/category/agile-austin-events/qa-sig-north/
He did suggest to talk to some people in the industry to see what it is really like and would be more than happy to share the good and the dark side of software testing so you know what it is like before you get into it.

Longer term things:

To Read
Book - Agile Testing
Book - More Agile Testing
Book - Lessons Learned in Software Testing
Book - Perfect Software (and other illusions about testing)
Book - Explore It
Join the JMeter mailing list: http://jmeter.apache.org/mail.html
Long list of blogs 

For training:
Any courses along the lines of Context-Driven School of Testing are good to read

Austin Community College may offer a software testing set of courses (he’s not sure how specific or helpful these may be)
US Military veterans should try the course provided by Bridge360 - http://www.bridge360.com/v4qlanding.shtml

Happy Testing!

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!