Monthly Archives: December 2010

One of my info posts was read in translation!

Someone looked at my “how to build a plastic model” info, translated into Slovenian. A little international flare there. Pretty cool!
Here’s what they clicked, you can see for yourself: 1

Well, I DO think its pretty cool and yes, I ought to be working on more career-work-related stuff. Next.


White Box QA Test of a 3 text-field and 2 pushbutton web panel…

In an interview, I was asked how I would construct a White Box QA test for a screen with

a Name field,
a password field,
a passwordConfirm field,
an OK button and
a Cancel button.:

I set down my best effort, below, on paper, and then checked it against a software testing book I have- “How to Break Software”. I was fairly pleased with what I’d come up with, since what the book says is to concentrate on generating each and every error message. More or less the same as what I had come up with:

name Password Password Screen

Name: [ ______________________]
Password: [_______________]
Password conf: [_______________]
[ OK ] [ Cancel ]

(Implied outputs:
Error Message: [==============];
Dialog box: msg [=============], [ OK ];
Status message: [============]; )

Note that the “Name”, “Password” and “Password conf” lines are explicitly outputs as well as inputs. They are set to something when the screen comes up. The Passwords might or might not be replaced with “*”s or big black dots. [Cancel] might or might not clear the strings

Inputs: Name, Password, PasswordConf, Ok_button, Cancel_button

(I’m conflicted on one point- Password1 and Password2 are useful definitions *inside* where keeping track that they are two, very similar, pieces of information is important. For a user, “Password” and “Password Confirm” are better definitions. I have to pick one nominclature and use it consistently.)

In addition to text in the Name, Password and Password Confirm fields, at least one or two of the following should be available:

Error Message: I assume that we have some space to output a message on error, Have to remember to blank this once we’re out of the error state.

Dialog box: If there’s a message that requires acknowledgement, then a dialog box is really what we’re talking about (modal use of the buttons in the ‘normal’ interface would be evil.) Of Necessity, a dialog box includes both an output line (which may be an error mentioned OR something else..) and an acknowledgement pushbutton.

Status Message: (blank), (ok), (error), (reset), ? – a complex screen, interface or underlying program might have an internal state, and for testing, it would be nice to show it.

By “White Box” I presume we mean we know something about how it works inside, so we know if the screen is well defined and not subject to sequence effects… or we know we DO have to address sequence effects..

For each input, there are relevant lengths, because Name and Password typically have minimum and maximums, and there are error messages relating to them:
For any text input: Name, Password, PasswordConfirm, etc., the 5 possible lengths are:
(1 character,
minimum number of characters – 1,
minimum number of characters,
maximum number of characters,
maximum number of characters + 1)

For each input, there is an acceptable character set and characters which are not allowed:
Alpha: [A-Z,a-z]
numeric: [0-9]
Alpha no case: [Aa]-[Zz]
Shift-numeric: [0-9,[!@#$%^&*()]
Special chars: [`-=[]\;’,./], [~_+{}|:”?].

Out of these categories, or a literal list of values, we can make acceptedNameChar and acceptedPasswordChar sets. We can also make unAcceptedNameChar and unAcceptedPasswordChar sets. Obviously overkill for testing the little screen this started with but worth considering in the case of algorithmically generating a bunch of non-identical test cases for a large set of screens or other objects-under-test.

name, passWd and passWdConf strings of characters are sets of the 5 possible lengths of the acceptable characters, or acceptable + unAcceptable

PRESUMING sequence doesn’t matter, before the Ok_Button is clicked, the test input and output vectors would look like:

Name PwdA PwdB , ErrorOut
—– ——- ——– ———— ————
“a”, “b”, “c” expect errors: Less than minimum , b & c don’t match…
minName-1, minPwdA, minPwdA (expect error: Less than minimum name error)
minName, minPwdA-1, minPwdA (expect error: Less than minimum passwd1)
minName, minPwdB, minPwdB-1 (expect error: Less than minimum passwd2)
minName, minPwdA, minPwdB Ok (expect error: passwds don’t match)
minName, minPwdA, minPwdA Ok (expect success)
minName, minPwdB, minPwdB Ok (expect error, name used already with different passwd- or does this just reset the password to the new one?
maxName, maxPwdB maxPwdB Ok (expect success)
maxName, maxPwdB, minPwdB Ok (expect error, name used already)
maxName, maxPwdA, maxPwdA Ok (expect success)
maxName + 1 , maxPwdB , maxPwdB error More than maximum error.
maxName, maxPwdB +1 , maxPwdB error More than maximum, pwds don’t match.
maxName1 , maxPwdA , maxPwdA+1 error More than maximum, pwds don’t match.

The vectors of input values and single outputs might expand to walking a blank through valid data. walking valid data through blanks. etc.

I prefer using arrays, arrays of structs and enums as indexes to handle this kind of thing. Because I find it easier to inspect and see whether its correct or not. Since the same values are used over and over again, it seems better controlled with the repeated values coming from a single variable.

enum lengths={ aChar, minM1, min, max, maxP1, numLengths };

String[] name=new String( “a”, “minim”, “minimu”,


“minimum_minimum_minimum…minimum_minimum_minimumX” );

String[] passWd=new String( “a”, “minim”, “minimu”,


“minimum_minimum_minimum…minimum_minimum_minimumX” );

String[] passWdB=new String( “b”, “binim”, “binimu”,


“binimum_minimum_minimum…minimum_minimum_minimumX” );

Name, PwdA, PwdB , ErrorOut?
—– —— —— ———— ————
name[ aChar ], passWd[ aChar ], passWd[ aChar ], errors: Less than minimum.
name[ aChar ], passWd[ aChar ], passWdB[ aChar ], errors: Less than minimum , Password and PasswordConf don’t match…
name[ minM1 ], passWd[ min ], passWd[ min ], error: Less than minimum name error
name[ min ], passWd[ minM1 ], passWd[ min ], errors: Less than minimum passwd1, passwords don’t match
name[ min ], passWd[ min ], passWd[ minM1 ], errors: Less than minimum passwd2, passwds don’t match
name[ min ], passWd[ minM1 ], passWd[ minM1 ], errors: Less than min. chars, both pwds.
name[ min ], passWd[ minM1 ], passWdB[ minM1 ], error: passwds don’t match
name[ min ], passWd[ min ], passWd[ min ], expect success
name[ min ], passWdB[ min ], passWdB[ min ], error, name used already with different passwd- or does this just reset the password to the new one?
name[ max ], passWd[ max ], passWd[ max ], expect success
name[ max ], passWdB[ max ], passWdB[ max ], error, name used already?
name[ maxP1 ], passWd[ max ], passWd[ max ], error More than maximum name error.
name[ max ], passWd[ maxP1 ], passWd[ max ], errors More than max pwd, pwds don’t match.
name[ max ], passWd[ max ], passWd[ maxP1 ], errors More than max pwd, pwds don’t match.
name[ max ], passWd[ max ], passWdB[ max ], error, pwds don’t match.
name[ max ], passWd[ maxP1 ], passWd[ maxP1 ], error More than max pwd.

For symmetry, I suppose name, passWd and passWdB could include a second set of strings which incorporate unacceptable characters and 5 more enums to pick them (or an “un” value to addd… or there should be three more arrays named unName, unPassWd, unPassWdB.

Point is, there are a lot of different error messages implied by this relatively simple panel, and to be certain that it behaves for each and every build.

Generally, I think its a good thing to get each error by itself from each possibly position, but not to get too worked up about combinatorials…. so walking a too short or too long string through the three inputs is fine, but having to wrangle TWO too long or too short or one of each is probably overkill- Its worth having ALL the inputs be errors to be sure that arbitrary collections of errors work, together, and you’re done, unless there’s some reason to think errors interact.

Recomended Christmas Movies, and why:

A Charlie Brown Christmas
– what Christmas is about, straight up, with New Testament reading, friendship, giving, wonderful music and Silent Night at the end. The Best. You’ve got to know the basics, here they are.

How the Grinch Stole Christmas (animated version)
– Dr. Seuse’s story, Chuck Jones’ animation, Boris Karloff’s narration. Thurl Ravenscroft’s marvelous singing of the song about the Grinch. Priceless. I sing the song to myself for days after I see it. This and the Charlie Brown movie show how good, family, art can also be entertaining, touching and meaningful. They’re both solid parts of English-speaking culture, today. Long may they wave. Note the role good music plays in both.

Rudolph the Red Nosed Reindeer – GE Theater stop-motion animation from the 1960s. The one with the elf who wants to be a dentist and Burl Ives giving voice to the snowman -narrator. Because its sweet but a little goofy and a little scarry- kinda like real life!

Miracle on 34th Street
(1947 version)
– Makes you want to believe in Santa Claus, or at least Kris Kringle, again. My favorite moment is when the judge hands down his verdict.

It’s a Wonderful Life

– Heartwarming and uplifting. What a great handsome-leading-man Jimmy Stewart was. What an inspired choice of story and staging.


– Unexpectedly sweet and enjoyable. Will Farrell is completely believable in the part, which is an amazing thing to see. The story is very appealing. By far my favorite of his movies.

A Christmas Story

– interesting and made with care and love, but a bit post-modern for me- its funny if you know the premises, mysterious if you don’t.

A Christmas Carol (Mr Magoo animated version)
– Pretty much the straight Dickens story, with Magoo as Scrooge.

Latest resume. Will make ‘writer’ version next. Start sending out!

More under BillAbbott at Linked-in. Comments welcome, please!

Home: (510) 594 1567 Mobile: (510) 502 1567 _________________________________________________________________________
Senior Software/Hardware Interface/Test Engineer

An implementor, fixer, problem-solver, filler-in-of-details, document writer and explainer. Complex performance test, verification, calibration and driver software, from client user-interface to hardware.

Over 15 years experience creating performance test, diagnostic, QA, calibration, driver, bring-up and verification software, in sh/BASH, Java, C++, C, Visual Basic, using client-server, multi-platform and “device test” environments; Extensive experience with legacy code, porting, completing, converting interfaces, and upgrading existing systems; Development, release and regression testing; Created many user interfaces and models to make data and systems usable by customers;
Worked closely with hardware and other software engineers, managers, marketing, sales, customer users, field support, applications and manufacturing engineers, and production technicians; Development, pre-sales, manufacturing and post-sales support roles; Extensive experience in multi-site and multi-national development and support, and identifying and re-using best practices in legacy products and projects;

Used the following tools to make production code in the last 15 years:

* Java, C++ in Linux, Mac OS-X; Visual C++, Visual Basic, OOP in Windows XP; C, C++ in Solaris
* sh/BASH, Perl and WinXP .bat scripts; Offline and online performance/benchmark, release, regression and unit tests;
* Perforce source management, Call and Bug tracking; Clearcase, Clearquest, home-brew bug tracking systems;
* HProf (Java), icounts (Intel platform), Purify, profilers for analysis, Examinator for cp/cpk process capability/test limit setting;


PERFORCE SOFTWARE, Alameda, CA 7/2009-11/2010
PERFORMANCE LAB ENGINEER, sh/bash, Java, Perforce, Linux, WinXP, Mac OS,

Used, supported, created and released performance benchmarking tools for Perforce Software components, on multiple platforms: Added limits with per-test overrides and report to cpu cycle counting (icounts) benchmark. Tuned MacOS for icounts. Verified new -a -b -h options with massive “obliterate” file lists.
Evaluated available multi-platform Java profiling tools, selected HProf. Developed two different P4Java api benchmarking suites. Began integrating results with developers Eclipse environment.
Compared performance of Mac OSX, Mac OSX Server and openSuSE, on Mac Pro (4,1) platform. Selected openSuSE. Started benchmarking suite for web server tools now in development. Created and released a large set (2GB) of open test data, to tune test times via data size.

Published detailed information related to performance of Perforce Software components. Revised and extended “10 Minute Demo” instructions for Perforce on Mac OSX; Identified existing, post-sales, documents that resolved ambiguities in pre-sales and training documents.

LTX-CREDENCE, Milpitas, CA 8/2007-1/2009
SENIOR SOFTWARE ENGINEER, C++, Clearcase, Linux/Solaris , TotalView, Examinator

Created calibration and diagnostics for 18 bit, <500kHz AC Source and measure, 18 bit DC measure, DCTM; Updated data logging, re-qualified test limits and wrote user documentation for DigHR (High Resolution Digitizer) diagnostics; Duplicated Diag/Cal/Verify field problems in-house; Advocate of peer code reviews and early adopter of the West-coast internal software engineering Wiki;

ADVANTEST, Santa Clara, CA 4/2006- 8/2007
SENIOR SOFTWARE ENGINEER, Visual C++, OOP, Perforce, Windows XP

Discovered and documented “open architecture” build process, seriously revising the SDK instructions; Delivered ported C++ code, scripts, for calibration and diagnostic software for 250 MBPS, 128 channel digital test module, for T2000 open-architecture system; Perforce and Win-script based porting tool-set parameterized starting point source, replacing hard-coded constants with symbols; Pioneered personal-build distribution from workstation to available test system;

TERADYNE, MEGATEST San Jose, CA 1993-2005

Flex-Plus SB6G: Visual Basic, WindowsXP, OOP 2003-2005 Created and released DDS Clock driver and walking strobe driver; Output waveform and clock/timing self-tests (checkers) to rapidly verify hardware integrity at customer sites; Used less than 50% of allowed run time; Drivers and checkers interfaced with raw registers and embedded PowerPC; Presented key pass-fail criteria and complex stimulus/response data (250,000 samples of a 5 bit waveform) in compact, regression-friendly, form; Filled coverage gaps by porting bring-up and applications programs into diag/cal environment; Created and used release validation tools that operated software on real hardware and on forced-fake-data off-line;

Tiger SS10: C, Solaris, 1997-2003 Created a sensible, coherent, user model for differential waveform levels and flyby PPMU interconnect; Drove team, including self, that wrote drivers, functions and libraries to implement the model; Created standard illustrations/graphics for naming and defining interconnect paths; Enabled system to meet DC levels accuracy specification by taking over and correctly implementing calibration measurement library drivers; Created and used release validation tools that operated software on real hardware and on forced-fake-data off-line;

Tiger PE32 & QSB: Created, verified and released user-callable driver software for switchable differential/single-ended pin electronics with two output swing ranges and common mode signaling; Created standard illustrations/graphics for naming and defining waveforms; Defined, designed, developed and released source-synchronous data transfer calibration software, making timing multi-chip modules work for every tester channel and support board; Created and used release validation tools that operated software on real hardware and on forced-fake-data off-line, with graphical display of results;

Tiger ECMS: Led team that defined, created, verified and released driver for (timing) Edge Calibration Measurement Subsystem (ECMS), including embedded state machines; Created and used release validation tools that operated software on real hardware and on forced-fake-data off-line; Defined, created, verified and released new generation serial EEPROM hardware support in common library; Created and released next-generation hardware recognition for embedded cpu;
J973 Time Jitter Digitizer 1995-1997: Designed, developed and released self test (checker) software; Made key contributions to project, including driver to ‘virtualize’ hardware behavior (the DC-blocking inductor was not 0.0 ohms, an unjustified assumption.); was never closer than 400 miles to any prototype hardware; Did all on-hardware work remotely, (X windows), with hardware and software engineers in other facilities;

Specified, designed, and developed transparent, embedded, implementation of polynomial calibration of channel DC Levels for “J975” (Everest), the proposed J973 follow-on product, in C++ under Solaris; Recognized as a member of the Everest Accuracy QIT at 1998 TQM Day. (Everest PE32) .