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!

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?

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. 16^th
• Contact me for more details or questions  [Brenda_Hall@Bridge360.com]

@Brenda - Thank you for this awesome opportunity!

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!

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!

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.

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.

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:

http://www.associationforsoftwaretesting.org/training/courses/

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.

http://www.associationforsoftwaretesting.org/training/courses/bug-advocacy/

Start learning these technologies for Automation:

Selenium - http://www.seleniumhq.org/

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.

WATIR - http://watir.com/

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

XPath - http://www.w3schools.com/xpath/

CSS - http://www.w3schools.com/css/

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 this one: http://www.meetup.com/Austin-Software-Test-Automation-Group/

and this one: http://www.meetup.com/Austin-Selenium-Meetup/

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

Join the Selenium mailing list: https://groups.google.com/forum/#!forum/selenium-users

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!

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!

"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?"  

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!

Wearing Multiple Hats

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

1. Michael Bolton ‏@michaelbolton  Apr 10

   Once again, testers: WE DO NOT PREVENT DEFECTS. We provide insight and information that can help other people to prevent them. #testing

   55 retweets40 favorites
2. Michael Bolton ‏@michaelbolton  22h22 hours ago

   @mheusser Did you change the code yourself? The design? Or did you help the person(s) who did? @Squidish_QA

   0 retweets0 favorites
3. mheusser ‏@mheusser  22h22 hours ago

   @michaelbolton @Squidish_QA ... In some cases. In others I did not. Is writing code the only way to prevent defects?

   0 retweets0 favorites
4. Michael Bolton ‏@michaelbolton  21h21 hours ago

   @mheusser Of course not. But let's be clear on who has responsibility and authority, and let's be appropriately humble. @Squidish_QA

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!

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!

What should testers do differently?

I had the awesome pleasure of hanging out some with Peter Walen at Agile Testing Days.  Peter is a tester that really seems to enjoy life and is always willing to share experiences.  I learned that he has many experiences outside of testing that are wonderful to hear and ponder.  You can enjoy his work by reading his blog - "Rhythm of Testing".  Every tester should have a pint of beer with Mr. Walen, so if you get a chance introduce yourself.

At some point in the conference Peter asked me a question - "What is the one thing testers should do differently in the future?"  I almost spit out the first thing that came to mind; however, I suspected a trap.  If you get a chance ask Peter about the Super Ball test.  For some reason I asked for more time to think about the question.

Seriously I knew Peter was not setting me up.  He was asking me a genuine question.  In hind sight the conference was about the future of testing so the question really makes sense.  So I have had quite a bit of time to think about this topic.  I honestly have gone all over the place with my thoughts.

I think I have boiled my answer down to this.  Testers must earn the respect of their peers.  My definition of peers would be anyone you encounter in the field of software testing or in life.

Earning respect can take on many forms such as being a team player, learning to code, better yet always be willing to learn, or demonstrate your skills.  I believe once you have earned the respect of your peers you have gained trust and trust is the key to doing some great things.  If you get a chance read the works of Christopher Avery.

Respect and trust are hard to earn.  Once earned they are hard to keep. The rewards of earning respect are plentiful.  We learn from our mistakes.  Making mistakes together as a group and learning from those mistakes can be even more powerful.

I will conclude this post by saying "Thank you Mr. Peter Walen" for asking the question.  I cannot wait to here his thoughts around the question.  I also want to thank him for reminding me that we should have fun in what we do and it is really important to have fun together.

Anyone have a different answer?

Happy Thanksgiving testers!

Buccaneer Scholar to King

Well I have not written in a while, so I will try to articulate some recent thoughts.  I am certainly not the best wordsmith or most articulate speaker, but I do have an opinion.

Some people you meet in life are inspirational.  They advocate for innovation, instilling drive and passion.  You read a great book about being a buccaneer scholar, pulling yourself up by your suspenders and achieving great things in life.  You attend a presentation at the 2009 STP Conference in Las Vegas and you come away thinking man that person is brilliant. You follow their blog posts and Twitter feeds that lead to inspiration. They teach you to enjoy games and attack challenges.  Today these pioneers seem to be taking a position of my way or the highway.  We are right and everyone else is wrong.

I am not sure that is the intent of the rhetoric or dogma as one colleague stated, but that has become my perception.

These pioneers have been extremely polarizing in their thoughts and critiques of others lately.  I am certainly OK with criticism and the elevation of thought.  I guess I think it should be done in a kind, professional, and collaborative nature.  What happened to politely learning to agree to disagree.

Word choice is an important attribute when debating or collaborating.  I am not great on my feet when it comes to word choice when debating on the fly.  When someone says I am wrong I can take it and I can listen to the point of view.  But when someone continuously attacks and says your idea is wrong it does not foster a learning environment.  I think we have missed the human side of a debate.

There are many people I respect and learn from in the industry of software testing.  Ideas should be challenged, but challenged in a human compassionate way.  We should push each other to be creative thinkers, but not at the expense of destroying relationships.

Although some people are more skilled than others we should not put ourselves on a mountain top and declare I am right; therefore, everyone else is wrong.  It is certainly Ok to think that way, but not belittle the thoughts of others along the way.

I hope the attitudes temper and we can get back to collectively improving our craft of software testing.

I will end with a humorous quote from a colleague - " I am Polish so I know all about Czech's!"

Keep on Testing!

ISO 29119 - What not to do!

This post is inspired by Michael Bolton's post here.

I am a software tester.  I am an advocate for rapid and creative testing.  Think and do not follow!

I am formally a chemist where I managed an Ambient Air Analysis laboratory.  Our laboratory had many other divisions analyzing water, soil, and other tests that had to comply to EPA protocols.  All of these protocols were based on a documented government standard.  The irony of analyzing environmental standards relative to protocols was that if you found a better way to test for something, you were WRONG!  You could get the governing body to draft an amendment to the protocol or actually convert it to a new standard, but it most likely would take years.

Because some of us do things differently in testing software are we WRONG?

One funny story is that to do environmental analysis you had to have "certified" reference standards.  I discovered on a audit/tour of a gas standards company that the standards they were selling were certified against an expired standard.  The further irony was that the some gas standard companies certify their newly generated standards against standards they themselves had prepared.  I created the certification standard and I sell "certified" standards to the public.  Sure seems like a wolf in the hen house.

One of the most frustrating things about working in the environmental laboratory were the government audits.  If you did not follow protocol to the letter you risk large fines and even loss of business.  Something as simple as failing to put your initials in a laboratory logbook or an expired training record could result in a fine.

I believe I was a good chemist solving real world environmental problems.  When the lab got bought and I was told to only run samples of this kind in compliance with this standard to maximize profit.  I changed careers!  I was no longer permitted to innovate and solve environmental challenges.

When I hear debates like the one on ISO 29119, all of those laboratory frustrations resurface.  Today I lead a fantastic team that test a family of web sites designed to help create fun vacations for families and groups of friends.  Does an ever changing website really need to comply with some standard?  I think not.  Do we want a quality product that delights our customers.  Absolutely!

Now there may be software that requires a high degree of rigor and I get that. Just because you follow some guidance does not mean the software complies with a standard.

In the business of analyzing gas samples the oracle was a certified reference standard.  What is the oracle for "Perfect Software"?

I also worked for a software company that was attempting to achieve a high level of CMMI certification. The work became sit in review meetings 8 hours a day, then find time to actually test the software.    This routine involved test plans in word documents, test matrices, change control on test cases, and so on.  I do not want to go back to that routine.

My vote is test software with a high degree of technical creativity, find the bugs, and never follow any mandated guidance.

Honestly if I get a copy of ISO 29119, I will probably read it as a reference of what not to do!

Happy Testing!

Reply to the Two Hour Challenge

Finally getting around to my answer to the two hour challenge.  I appreciated the two people who attempted to tackle the two hour challenge.

Here would have been my approach:

• 25 minutes exploring the site/application gathering context and testing ideas in a mind map
• 5 minutes organizing the test ideas in order of importance or likelyhood to uncover bugs
• 60 minutes executed the test ideas in order of importance and during execution taking notes.  The notes would be tagged - bug, question, observation, enhancement, issue, and action
• 30 minutes summarizing my findings in a report where the report includes a list of bugs, questions, observations, enhancement suggestions, issues, and future action items.  The list of action items would include recommendations on additional test ideas I would recommend the team execute.

Hopefully based on these findings, I would be contracted to do additional testing.

Targeted and time-based sessions work!  Try it!

Two Hour Challenge

It is very safe to say that I have completely blown my objective of writing a weekly blog post in 2014.  I could analyze the plethora of reasons, but that is really not important.  What is important is that I have been inspired to challenge the testing community?

In my opinion testing has been reframed from the POV of what testing does it require to generate a great product to what great testing can be accomplished in a given timeframe and make the product great.

The reframing could be worded better, but hopefully you get my point.

So here is the two hour challenge:

You are being hired to test a website.  You will be provided only a URL.  And you only have 2 hours to test.

How would you structure those two hours and what would you deliver?

Please post your testing approach as a comment.  Don't be shy because I am sure there are no wrong answers!

I will try my best to share my answer next week.

And what is your excuse?

I finally made my way through about 70 blogs.  Many educated me and a few were easily skipped.  It was this one that I found interesting - Top 5 Excuses for not having enough Testers Testing.

My Product is not finished yet:  I agree with the article that this excuse is silly.  The best and perhaps the most important testing happens at the beginning of SDLC.

Quality is everyone's responsibility; No dedicated testers needed:  I very much believe quality is everyone's responsibility and quality is enhanced by having a dedicated tester leading the charge.

We have budget/time constraints:  Oh!  This excuse is so very true.  This is where experienced testers add a tremendous amount of value by executing risk based and Session Based Test Management, SBTM.  In the world of continuous delivery time constraint certainly is playing a more important role in the land of excuses, so creativity and automation are highly valued.

My product is perfect.  It does not need testing:  This one is just laughable.  Hand the team a copy of Perfect Software by Gerald Weinberg.  Honestly it does not take much effort to find flaws in almost every software product today.

A separate QA team can build an 'Us vs Them mentality', which is not Healthy:  I have to admit that I have heard this one too.  And I agree with the article that this sentiment boils down to culture and style.  Agile software teams today should have a set of roles responsible for building great software regardless of the management structure.

I think there may be a couple more excuses floating around.

Our customers will let us know if we have bugs in our product:  This one is very sad, but I think it is true for some web applications.

Revenue is more important than product quality, just deliver it on time:  I think this may be a true excuse for young entrepreneurial companies.

The developers are doing enough testing:  In my opinion you add a great tester to this team it may just be humbling.

I set out to think of 5 additional excuses, but I am afraid I am going to fall two short.  

I think we should all focus on making great software and a little less on excuses.  We are human and yes we all do make mistakes.  I would rather a colleague catch my mistake than a customer.

Happy Testing!

Testing versus Winning the Lottery

I just returned from a wonderful vacation at Seagrove Beach Florida.  I really did not have a clue what to blog about until I reflected on the vacation.  On our road trip we stopped at a Subway/Gas station.  I observed many interactions at this place, but the one that peaked my curiosity was the two ladies who spent $32 each on Power ball tickets and the family who sat at a table rapidly scratching their pile of scratch off lottery tickets.  I guess I was amazed at how they could spend their time and hard earned money on such long shot purchases.

As related to testing is seems like testers may spend most of their time rapidly looking for long shots.
Great testers typically do not rely on random luck, but I feel like there are some similarities.

Sometimes we testers throw money at the problem like the two ladies.

Sometimes we collaborate like the family all doing the scratch off tickets.

I did not observe the diversity of the scratch off tickets, but I could assume that the family strategically selected the tickets they suspected might pay off.  We testers do the same thing using a risk based approach to testing.

I believe the two ladies relied on the random generation of power ball numbers.  We testers use random inputs all the time hoping to hit the defect jackpot.

My conclusion is that testers gamble often.  Our jackpot just happens to be bugs!