Home » General QA Stuff

Category Archives: General QA Stuff

Happy New Year!

Welcome to 2014!

Any New Year’s resolutions? I have a few:

– Pay more attention to this blog. I tend to let too much time pass between posts. My goal – at least once a week.
– More positive posts. No more whining and complaining. Well less anyway. No one want to read that negative garbage.
– Make nice with the folks at Microsoft and Apple
– Learn something new. Be it a new too, or a new process. Something to keep the tools sharp.
– Speak more. I’m an attention whore. I love getting out and meeting and talking to people. Try to book more speaking engagements. Preferably in Las Vegas!
– Lose 30 pounds (again).

So if you see me out and about, please say hi!

Onion Bagel With Plain Cream Cheese Please…

I run a nightly automated regression test. I made a deal with my developers that if their code broke my regression test they must buy bagels for the team on Friday. Last night the entire regression test suite failed. Once the configuration issue was resolved, 1 test failed due to a change in the text of an error message. I’m thinking this is a multi-bagel offense. But, being the nice guy that I am, I’m only holding them responsible for a single error. I’m starting to get fat(ter).

New Friends

Last night found me at the Software Quality Association in Denver (SQuAD) meeting. It wasn’t a meeting as much as a holiday social. As usual, being the attention whore that I am, I was being loud and obnoxious. As a result, in addition to catching up with some good friends I made some new ones. Anytime they don’t run away screaming is a good day. Happy Holidays everyone!!!

Slamming My Head On The Wall

I’m not stupid. But sometimes I feel like a complete moron. Usually it is something to do with a tool download that humbles me. I have been using Fitnesse for years and I really thought I knew what I was doing. Luckily I have had really good developer support to do the heavy lifting. So I got a little cocky and signed up to do a couple of presentations on Fitnesse at the local software testing conference. I wanted to demonstrate a simple test using the fixtures in the Fixture Gallery. Sounds pretty simple right – cue the brick wall.

So I scour the web and the Fitnesse.org site for simple easy instructions. I find the fixture gallery zip file, download it, and unzip it. It seems to include a completely new installation of Fitnesse. I’m confused – let’s consult the documentation. Well I would if I could find any – i can’t!

Maybe there are books available? Nope! Well there are, sorta, but I’ll save that for another post.

I’m not giving up. Once I get this solved I’m going to write the Idiot’s Guide to Using Fitnesse.

If anyone can help and walk me through this, please contact me at dwhalen14@gmail.com.

Stay tuned.

I’m Unqualified to be Me

I just found out that the company that I was contracting for is looking for 3 contract testers on my old team. I absolutely loved it there, loved the project, loved the company, etc. The open positions are apparently to replace me – the exact same job I spent almost 2 years building – using a test architecture that I built from the ground up. I could be immediately productive. Literally hit the ground running. You’d think I’d be a shoe-in to return. Think again! I just heard that I’m basically not qualified to be me and that I won’t be considered for the open positions. Needless to say, I’m livid. Have you met me? I’m a Golden Test God!…lol. Oh well. No need to dwell on it. It’s their loss! As Jimmy Buffett says – “Breathe In, Breathe Out, Move On”!

Software Quality Association in Denver (SQuAD) Conference

For those of you in the Denver area, or wanting to visit our fine city, SQuAD will be holding their next conference in October. Your’s truly will be providing both a one-hour presentation in addition to a 1/2 day work shop on Fitnesse. Check out http://www.squadco.com for more details. If the current info isn’t up yet – keep checking back.

I Am Not The Quality Guy!

We all are!
I get a kick out of watching the news for “quality” issues – or should I say “lack of quality” issues!  There are usually lots of them.
Someone recently told me that there is no difference between Quality Assurance and Quality Control.  Seriously?
Sadly, its not the first time.  In my not-so-humble opinion – most companies or organizations have absolutely no clue as to the difference between Quality Assurance and Quality Control.  Even though Quality Control has been an out-dated practice for more than twenty years, I still find a “quality control mindset” on each consulting assignment.  They may even call it Quality Assurance, but it ain’t.  Lets look at the two shall we?
Quality Control(QC) is the traditional way of looking at quality.  In a QC environment, quality efforts are usually tacked on at the end of a given process. Something is produced and then given to the QC folks to test and determine if the product meets quality standards.  In the event a quality issue is detected (and there usually is), the entire product may need to be scrapped and rebuilt.  Or, where it is practical, pieces or parts of the product may need rework.  Then the whole production/quality process repeated until quality standards are achieved.  If time is critical, its the quality process that gets the ax.  Ultimatly, only the QC Team is held responsible for quality. A QC mindset is expensive.  Had the problems been found earlier in production or even during the design process it would have been significantly less expensive to fix.  Ask Toyota.
Quality Assurance(QA) on the other hand involves having an eye to quality at every level of the organization, throughout every process, by everyone involved in designing, producing and even using the product – be it a computer, or the software that runs it.  With QA, quality isn’t saved until the end but rather looked at constantly – by everyone, not just testers.  Its having what I like to call the “Quality Mindset”.  The goal should be to identify quality issues constantly, throughout the process and adjust as neccessary (Controlling function of management)  Finding and resolving issues early ultimately saves money!  Sure it may take a bit longer to produce the final product and cost some money, but in the long run I think it saves money.  Ultimately is produces goodwill and trust with the customer.  Unfortunately, to the bean-counters, trust and goodwill are difficult to measure in terms of dollars and cents (or is that sense?).
If you’re Microsoft and control your market, you can slip up on quality (or customer service) and get away with it.  You can make your products difficult to install or completely annoy your customers.  Since there is no real competition, customers have no where else to turn.  So the company can make you lose all of your installed software when you try to upgrade to a more expensive version of THEIR operating system.  (Try upgrading from Windows 7 Home to Windows 7 Professional – you can’t.  They force you to do a new installation.  Not only do you have to reinstall all of your software, you also have to reinstall all of your drivers)  Then they can get away with charging a small fortune to help you resolve the problem when you call customer support.  What other option do you have?  Why make me pay to use the more expensive version of YOUR product then charge me for assistance?  Or for that matter – to use your product at all (see Microsoft Project). Because they can!
It is unlikely your company can get away with it.  You need a quality product and you need produce it as inexpensively as possible.  You probably have to compete in a competitive marketplace.
I like to get involved in any product development early.  I know most of the pit falls and I can catch most of them early – hopefully before the first line of code is ever written.  Will things slip by?  Absolutely?  As much as I like to think I’m perfect, I’m the first to admit that I’m not.  I want to see all design documents, specifications, requirements, etc.  I may find something really trivial – but its a lot cheaper to fix it now by running a spell checker than it is to fix it in the code, re-install it and re-test it.
Watch for the tell-tale signs.  Listen for things like “We’ll catch it in test” or “That’s not important right now” or “Its someone else’s job to fix that – they’ll find it later”.  You gotta love job security!