[All Things Quality] When the only tool you have is a buggy whip, everything ...



When the only tool you have is a buggy whip, everything begins to look like a dead horse. 

Over at SQAForums, a member asked about the choice of relying on his current knowledge of one test automation tool, versus taking a position at a different company, but having to learn a new test tool.

http://www.sqaforums.com/showflat.php?Cat=0&Number=642439

Some short-term jobs (such as contracting jobs) may require little more than specific, single-tool knowledge, most testing and QA positions require something different.

If you tie yourself into a one specific tool, you may get lucky for a while and that tool knowledge will be in demand for a long time.  But eventually, it will be replaced by another set of tools.  You risk becoming yesterday's news.  Better not to become a specialist, but rather become a generalist - one with deep knowledge in a few areas, and broad knowledge in many others.

When I hire QAers, I want someone that knows how to test and is able to use a variety of tools and techinques.  If the candidate happens to know the particular test automation tools we happen to be using at that time, it's a plus, but if the candidate knows ANY tools well, I usually find that they can learn others.
The concepts are the important thing here, not the specific tool.

I once had a college professor who said "Life is an open-book test."  His point was that using one specific tool or technique, or memorizing a few bits of information isn't enough.  In the world today, you must be able to adapt quickly, find the information you need or learn the new tool and technique that is appropriate for the task at hand.

Become good at learning new tools and techniques.  When you hear about a new tool, find an opportunity to check it out.  When you hear about a new technique, read about it and give it a try.  Be ready for new requirements that are sure to come your way.

Perhaps you are very good with your buggy whip.  That's fine, but make sure you aren't still beating a dead horse.


My name is Joe Strazzere and I'm currently a Director of Quality Assurance.
I like to lead, to test, and occasionally to write about leading and testing.
Find me at http://strazzere.blogspot.com/.

[All Things Quality] Perhaps They Should Have Tested More - J.P. Morgan Chase

Millions of customers who bank online with J.P. Morgan Chase & Co. lost electronic access to their accounts as the company's website suffered a severe outage starting Monday at 11:00 PM ET.

At one time today the Chase site reportedly indicated it was undergoing "scheduled system maintenance". But as of 8:30 PM ET Tuesday, the site now says "Our website is temporarily unavailable. We're working quickly to restore access. Please log on later."

There's no indication yet when this outage is expected to end.
  • The result of a flaw in a software program tailored for J.P. Morgan.
  • More than 16 million computer and iPhone users impacted
  • The Chase outage "appeared to be unusually lengthy"
  • People can't check their balances or pay their bills online
  • Affects both businesses and consumers
  • Affects all online transactions
Perhaps Chase should have tested more.

See also:


Update: Wednesday, September 15.

When I checked around 6:30 AM ET this morning, the Chase site was back up and running, although there still doesn't seem to be an official explanation for the more than one day outage.

  • down for more than a day
  • "It's an eternity in the online world
  • speculation as to the cause appears on Twitter and online message boards
See also:
    http://chicagobreakingbusiness.com/2010/09/chase-banking-web-site-back-online.html


My name is Joe Strazzere and I'm currently a Director of Quality Assurance.
I like to lead, to test, and occasionally to write about leading and testing.
Find me at http://strazzere.blogspot.com/.

[All Things Quality] Perhaps They Should Have Tested More - J.P. Morgan Chase

Millions of customers who bank online with J.P. Morgan Chase & Co. lost electronic access to their accounts as the company's website suffered a severe outage starting Monday at 11:00 PM ET.

At one time today the Chase site reportedly indicated it was undergoing "scheduled system maintenance". But as of 8:30 PM ET, the site now says "Our website is temporarily unavailable. We're working quickly to restore access. Please log on later."

There's no indication yet when this outage is expected to end.
  • The result of a flaw in a software program tailored for J.P. Morgan.
  • More than 16 million computer and iPhone users impacted
  • The Chase outage "appeared to be unusually lengthy"
  • People can't check their balances or pay their bills online
  • Affects both businesses and consumers
  • Affects all online transactions
Perhaps Chase should have tested more.

See also:


My name is Joe Strazzere and I'm currently a Director of Quality Assurance.
I like to lead, to test, and occasionally to write about leading and testing.
Find me at http://strazzere.blogspot.com/.

[All Things Quality] WinTask - 99 Bottles of Beer

' 99 Bottles of Beer - WinTask Version
'
'
' Author: Joe Strazzere ( http://strazzere.blogspot.com )
'

BottleCount = 99

While BottleCount > 2
  Phrase1$=Str$(BottleCount)+" bottles of beer on the wall, "+Str$(BottleCount)+" bottles of beer."
  Phrase2$="Take one down and pass it around, "+Str$(BottleCount - 1)+" bottles of beer on the wall."
  MsgBox(Phrase1$+CRLF+Phrase2$)
  BottleCount = BottleCount-1
Wend

Phrase1$="2 bottles of beer on the wall, 2 bottles of beer."
Phrase2$="Take one down and pass it around, 1 bottle of beer on the wall."
MsgBox(Phrase1$+CRLF+Phrase2$)

Phrase1$="1 bottle of beer on the wall, 1 bottle of beer."
Phrase2$="Take one down and pass it around, no more bottles of beer on the wall."
MsgBox(Phrase1$+CRLF+Phrase2$)

Phrase1$="No more bottles of beer on the wall, no more bottles of beer."
Phrase2$="Go to the store and buy some more, 1 bottle of beer on the wall."
MsgBox(Phrase1$+CRLF+Phrase2$)



My name is Joe Strazzere and I'm currently a Director of Quality Assurance.
I like to lead, to test, and occasionally to write about leading and testing.
Find me at http://strazzere.blogspot.com/.

[All Things Quality] An Old Test Plan Template

Last night, I was digging through some old documents, when I stumbled across a diskette containing this Test Plan Template.  It was given out as part of a presentation I did during a Users Conference back in 1994.

These days, I generally use a less-formal Test Plan format, although I still occasionally use something like this when warranted.

An oldie but goodie?




Test Plan Template

Test Suite Name

Application:                                                 Name of the Application

Version:                                                        Version of the Application

Developers:                                                 Developer Name

Test Plan Author:                                       Plan Author Name

Date of the Original Test Plan:                Month dd, 19xx

Current Revision Date:                             Month dd, 19xx

Document File Name:                               TESTPLAN.DOC




Related Documentation for this Test Suite:

Requirements Specifications:                           Title                 
            Author:                                                 Author name
            Revision Date:                                      Revision date
            Relevant Pages:                                    Relevant pages

Design Specifications:                                    
            Author:
            Revision Date:
            Relevant Pages:

Development Plan:
            Author:
            Revision Date:
            Relevant Pages:

User Documentation:
            Author:
            Revision Date:
            Relevant Pages:

Standards Manual:
            Author:
            Revision Date:
            Relevant Pages:

Other:
            Source:
            Revision Date:
            Relevant Pages:









Application Overview

Overview of Component Functionality

An overview of the relevant application components and their functionality is described here.  This helps to guide the thought process and place this test suite in the correct application context.     

Other Applications/Components Impacted

Any other applications and/or components that may be directly or indirectly affected are discussed here.  The Test Suites which will be used to perform testing on those components may also be referenced.

Standards Requirements

When the testing process requires checking the application against any pre-defined standards, those standards are described here.     

Performance Requirements

The performance requirements against which this application will be measured are described here.

Defect Tracking System Codes

When defects in the application are found, this section describes how they will be categorized and entered into the defect tracking system.     

Scheduled Availabilities

Application Version:                                          The version to be tested.

Build Date:                                                        The expected date for the following features.
Features to be included in this build:                  The features delivered on this date.

Build Date:                                                        The expected date for the following features.
Features to be included in this build:                  The features delivered on this date.

Build Date:                                                        The expected date for the following features.
Features to be included in this build:                  The features delivered on this date.








Test Suite Overview

General Testing Strategy
The overall approach to implementing this test suite is described here.  

Test Environment:

Hardware
The hardware environment in which the tests will be executed is described here.

System Software
The system software environment in which the tests will be executed is described here.

Databases/Files
Any databases and files required to execute this test suite are described here.

Utilities/Tools
Any utility programs required to execute this test suite are described here.








Test Suite Summary

It is often useful to have a naming convention to use when naming test cases.

Name of Test Case                        Brief Description

1.  Name of test case here                     Description of test case here.                                        
2.
3.
4.
5.








Test Case Specification - 1. Name of Test Case One

Overview:
This section describes, in some detail, what is to be accomplished with this test case (i.e., what particular assertion will be tested).

Prerequisites
Any prior tasks which must be accomplished before this test case can be executed are detailed here.
Any advance preparation of the hardware or software environment is detailed.

Utilities and Files used:
Any utilities, database, and files required to execute or validate this test case are detailed here.  In addition, their version and location is described.

Test Sequence:
The high-level steps required to execute this test case are described here.  This is often the longest portion of the individual Test Case.

Expected Results:
This section describes what results are expected when the above test sequence is executed.

Verification Procedure:
The process for determining if the expected results were achieved is described here.

Script(s):
Any scripts (either written or automated) which aid in execution of this Test Case are listed here.

Time Estimates:
Preparation:                                                      The expected amount of prep time required.
Execution:                                                        The expected amount of execution time. 
Verification:                                                      The expected amount of verification time.



My name is Joe Strazzere and I'm currently a Director of Quality Assurance.
I like to lead, to test, and occasionally to write about leading and testing.
Find me at http://strazzere.blogspot.com/.

[All Things Quality] Testing is a Box of Many Colors

not actually me

During my first ever interview for a QA position, I was asked if I knew what Black Box Testing was.  Not knowing anything at all about QA, I admitted that I wasn't sure.  But I had heard the term Black Box before, so I described that, and how I thought it might apply to testing.  Apparently it was a good enough answer, since I ended up getting the job.

At some point in time, I heard the term White Box Testing.  Knowing what Black Box meant, and the context of how the new term was used, I understood the meaning.

Since then, I've seen a virtual rainbow of invented terms.  And recently, Rob Lambert over at the Software Testing Club asked "How many different colour boxes are there?"

Among the responses he got were:

  • Black Box Testing
  • White Box Testing
  • Gray (or Grey) Box Testing
  • Clear Box Testing
  • Glass Box Testing
  • Pink Box Testing
  • Red Box Testing
  • Yellow Box Testing
  • Green Box Testing


To me, anything much beyond Black Box and White Box is foolishness.  I get the distinction between the two without much thought.  But venturing beyond that almost always requires further company-specific interpretation.

Do we use Gray Box Testing?  Perhaps.  It depends on how dark or light a shade of Gray you mean, I suppose.  Red Box Testing?  I don't know.  Purple or Brown?  I might have done that once by accident.

Can we as professionals refrain from constantly inventing new, dare I say "colorful", terms?  Probably not.  But as Michael Bolton over at DevelopSense writes, the final test of a metaphor or heuristic is "Is it useful?"  I don't see much use for this rainbow of terms, but perhaps you do.

"When I use a word," Humpty Dumpty said in a rather scornful tone, "it means just what I choose it to mean - neither more nor less."  I think I may have interviewed with Mr. Dumpty once or twice.

See also:
    http://www.softwaretestingclub.com/forum/topics/how-many-different-coloured


My name is Joe Strazzere and I'm currently a Director of Quality Assurance.
I like to lead, to test, and occasionally to write about leading and testing.
Find me at http://strazzere.blogspot.com/.

[All Things Quality] A New Hobby - Kayaks

My wife and I have been trying out some new hobbies recently.

This weekend, we rented some kayaks and got a short lesson.  We liked them so much we went and bought our own and tried them out on Silver Lake in Wilmington.

She got a "girlie" color - periwinkle blue, and of course I got the more "manly" flame combination!

It was a lot of fun, not too much work getting them on and off of the roof rack.  Once on the lake, it was very relaxing - a beautiful, sunny day with just a light breeze.  I think we're going to enjoy this one.


My name is Joe Strazzere and I'm currently a Director of Quality Assurance.
I like to lead, to test, and occasionally to write about leading and testing.
Find me at http://strazzere.blogspot.com/.

[All Things Quality] We are Acquired

We just found out that our company has been acquired.


It's not a surprise; we pretty much knew that this was the strategy, that sooner or later we'd need to be part of a much bigger company.  That time is now.

Having worked at many smaller companies, as well as several startups, I've been through the acquisition routine before.  Sometimes it works out really well, sometimes not so much.

The folks from the acquiring company were here, talking about their organization.  They all seem nice enough, and there are certainly many more opportunities in the larger company for all of us to grow and prosper.

Right now we are in the uncertain, slightly uneasy stage.  I'm sure there will be some change eventually, but for now, everything is staying as is.  Still, we keep thinking:

  • How will our roles change?
  • Will they leave our organizational structure in place?
  • Will we stay in our current building?
  • Will we like working for a much larger company?
  • Will they like us?
In some respects, it's like interviewing for a new job.  Except that you have already been hired and you're just not exactly sure what your job is, who your boss is, and where you have to go to work every day.

I'll be working hard over the upcoming days and weeks to make our transition easier on the team in whatever way I can.  Meanwhile, we will try to keep our current projects on track.

This will be interesting.


My name is Joe Strazzere and I'm currently a Director of Quality Assurance.
I like to lead, to test, and occasionally to write about leading and testing.
Find me at http://strazzere.blogspot.com/.