September 28, 2010

Perhaps Amazon Defines "Nonfiction" Differently?

I like to read a lot.  And I tend to prefer non-fiction.  Since I order books through Amazon fairly often, their sophisticated systems have detected this, and occasionally send me emails with offers for more non-fiction books.

Today, I got this one:


Notice that "Squirrel Seeks Chipmunk: A Modest Bestiary" is the top title this week in Nonfiction.

From this, I suppose we must conclude one of the following:
  1. This "new collection of keen-eyed animal-themed tales" which starts off "The cat had a party to attend, and went to the baboon to get herself groomed." really did occur (or is occuring) somewhere in the world.
  2. Amazon has a unique and interesting definition for the word "Nonfiction".
  3. Someone messed up

Which of the above seems most likely to you?

And if you chose number 1 and have read the book, where do these talking animals all live?  I've got a few questions about testing I'd like to ask of both the Sickly Rat and the Healthy Rat, that might make for an interesting debate.


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/.

September 27, 2010

My Interest Is Kindled In A Nice New Device




For a while, I've had my eye on e-reader devices.  I like to read a lot, my bookcase is getting full, and what the heck - it's time to try something new.

My son got a Nook a while back and likes it.  He owns pretty much every Android device that exists (and a few that aren't yet available publicly).  But I'm not so hooked on Android, so I was also looking at Kindles. When Amazon announced the new generation of Kindle recently (popularly known as the "Kindle 3"), with some interesting features and a reduced price point, I was pretty sure I wanted one.  So after a bit of reading I took the plunge and ordered a Graphite Kindle 3G with free 3G + Wi-Fi.

My Kindle arrived a few days ago, and I've had a few hours to play with it. So far, I'm very impressed.

I think it's clear that the Kindle is optimized for reading. The tiny keyboard, and 5-way pointing device make it possible to type and to click, but you would want to avoid that where possible.

My initial thoughts:
  • Lots of fun so far.
  • The e-book experience is terrific.
  • Reading PDFs is very good. Good enough that I'll use it to read work stuff.
  • It's trivial to email documents in several formats to your free kindle email address and have it automatically re-formatted and wirelessly delivered to your Kinde. Very nice.
  • The text-to-speech feature is intriguing. The voicing is very good. While not perfect, it may just be good enough that I could have any book read to me on a long drive. I'm going to have to try that out.
  • Reading many websites (particularly those optimized for mobile devices) using the Kindle browser is good.
  • While the Kindle has an .mp3 player, it has no UI. Thus, you can't even select which song you want to play without pressing Alt-F until you hear the desired song. Pretty much useless.
  • The keyboard is tiny. It's usable and handy, but I'll always look for ways to avoid too much typing on it. I'm not planning to use it to write any Test Plans soon!
After a bit of experimenting, I found that I can put my .mp3 files in the Audible folder, rather than the Music folder to have them treated as audio books.  On the Kindle, audio books are individually visible, and the player does display a UI with controls. This makes it possible to go to an individual song and play it.  The downside is that there doesn't appear to be a way to let the songs in the Audible folder play in the background while I'm reading something.  This seems to make my Kindle good for podcasts, or when I only want to listen to one song at a time. Passable, but still not wonderful for background music.

Before buying it, I knew the Kindle was very good as an e-reader, but wondered about some specifics concerning the "experimental" browser (which had the potential to be an extremely useful feature for me).

To answer my own questions about the browser:

Q: Does it work well for the sites you visit?
A: It works well enough for most of the sites - particularly those which are text-heavy and allow reading without a lot of clicking.

Q: Does it work for your use of SQAForums and the Software Testing Club site?
A: Not as well. I tend to skim through SQAForums and STC, clicking here and there. The Kindle isn't really optimized for that.

Q: Does it work for your use GMail? 
A: Yes. And it works even better when I use the Mobile version of GMail. For me this is a huge plus. Now I can always be within reach of GMail - either through Wi-Fi, or 3G.

Soon, I plan to experiment with creating my own Kindle-optimized websites, and experiment with using other Google products (Reader, Docs, etc) in the Kindle browser.

Meanwhile, I've already read a few free e-books, and experimented with (tested?) more of the settings and features. Very nice - I like this device!


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/.

September 20, 2010

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





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

While 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. copyrightjoestrazzere

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/.

September 14, 2010

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




Update: Thursday, September 16.

And the fun continued through Wednesday.  Wow...
  • Site failed again on Wednesday
  • Customers reported new problems accessing the site for much of Wednesday
  • Throughout Wednesday, many customers were unable to log in
  • According to JP Morgan, a third party vendor's database software corrupted the log-in process
  • The length of the online blackout suggests "something is significantly wrong"
  • "It raises serious questions about the technology of the bank"
See also:

And here's what the Chase site shows now:






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/.

September 13, 2010

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, 99 bottles 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/.

September 10, 2010

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.     copyrightjoestrazzere

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/.

September 4, 2010

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. copyrightjoestrazzere

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/.