Testing by the Numbers | testingReflections.com

Karen Johnson has a great post on 9 numbers that she likes to start with when testing something that takes a numeric input. It is nice short description of why these values are useful in testing.

It reminded me of a utility used for generating skeleton junit classes, junitdoclet. One feature is passing various values into setters and verifying the value using the getters. How this relates to Karen’s post is that within the utility is a data file that has the values to use for various data types. The file, junitdoclet.properties, is found in the root directory of the jar.

Since this is a junit related tool and java has compile time type checking, you cannot pass a float to a method that only takes an integer. For the numeric types, these are the values junitdoclet uses:

byte Byte.MIN_VALUE, -1, 0, 1, Byte.MAX_VALUE
double Double.MIN_VALUE, -1.0, -0.5, 0.0, 0.5, 1.0, Double.MAX_VALUE
float Float.MIN_VALUE, -1.0f, -0.5f, 0.0f, 0.5f, 1.0f, Float.MAX_VALUE
int Integer.MIN_VALUE, -1, 0, 1, Integer.MAX_VALUE
long Long.MIN_VALUE, -1, 0, 1, Long.MAX_VALUE
short Short.MIN_VALUE, -1, 0, 1, Short.MAX_VALUE

The non-numeric data type values junit doclet uses are:

boolean true, false
char ‘ ‘, ‘a’, ‘A’, ‘z’, ‘Z’, ‘ä’, ‘\n’, ‘ß’, ‘?’
string “” (empty string), ” ” (blank character string), “a”, “A”, “ä”, “ß”, “0123456789”, “012345678901234567890”, “\n”, null
date new java.util.Date(), new java.util.Date(0), null

In a later post, I will put in some of the values I like to use.

Helpful DST Links

I have been working on the upcoming daylight savings time rule changes at work. Here is a collection of information that I gathered during my research:

Daylight Savings Time Change Background Information

Text of U.S. Energy Policy Act of 2005 See section 110.
Wikipedia article on Energy Policy Act of 2005

The new Daylight Saving Time changes start in March 2007:

Year DST Begins DST Ends
2007 March 11 November 4
2008 March 9 November 2
2009 March 8 November 1
2010 March 14 November 7
2011 March 13 November 6
2012 March 11 November 4
2013 March 10 November 3
2014 March 9 November 2
2015 March 8 November 1


Note: According to the Sun advisory, changing the time on the system as a workaround will not work – “There is no workaround. Attempts to change the TOD clock of the system are temporary and will not resolve all the time zone issues.”

Sparc Solaris 8 requires the following patches (check to see if there are newer versions):
109809-04 (Reboot after install)
108993-65 (Install in single user mode, reboot after install)

Sparc Solaris 10 requires the following patches (check to see if there are newer versions):
122032-02 (Reboot after install)
118833-24 (Install in single user mode, reboot after install)

x86 Solaris 10 requires the following patches (check to see if there are newer versions):
122033-02 (Reboot after install)
118855-19 (Install in single user mode, reboot after install)

Firmware update required:
Sun Fire 3800 Server, Sun Fire 4800 Server, Sun Fire 4810 Server, Sun Fire 6800 Server, Sun Fire E6900 Server, Sun Fire E2900 Server, Sun Fire V1280 Server, Sun Fire E4900 Server, Netra 1280 Server
Sun Advisory Link:
Daylight Saving Time (DST) Changes for Australia (2006), United States (2007) and Others
Required Server Firmware for Timezone Changes Due to U.S. Energy Policy Act of 2005


JDK/JREs with support for DST Changes
1.3.1_18 or later
1.4.2_11 or later
5 update 6 or later

Sun Java SE TZupdater Tool
Option for updating existing 1.4.x and later JDKs (instead of upgrading them). In the readme, this is not the preferred option – “Sun recommends utilizing the latest Sun Java SE JDK/JRE update release as the preferred vehicle for delivering both timezone data updates and other product improvements such as security fixes.”

Overview and Mitigation of the USA 2007 DST Issue for the Java SE platform and Solaris OS
U.S. Daylight Saving Time Changes in 2007

Windows 2000 / 2003 Server

Windows Server 2003 – see 928388
Windows 2000 – see description of tzedit.exe in the article below.

Preparing for daylight saving time changes in 2007

Planning & Tracking a Software Project at the “Right” Level

Today I attended a webinar sponsored by ASPE Technology (a training firm) by Bob Galen entitled “Planning & Tracking a Software Project at the ‘Right’ Level”. The beginning of the presentation was absolutely outstanding. It discussed the various symptoms of not enough planning and tracking or too much planning and tracking.

The slidedeck used in the webinar is not available on the web (at least not yet). However, a very similar slide deck from an earlier presentation can be found on Bob’s site here. Take a look at slides 5 – 15 in particular.

The theme of the presentation – that the “Right” level depends on your context – is driven home by the factors around too low or too high of planning. I found it useful to ask myself if these factors can be found in my current projects.

Update 01/13/2007: The presentation used during the webinar can be found here.

Jira Priority (vs. Severity)

One of the first things I show a new tester is our bug tracking system (currently a modified Bugzilla – however, we are in the process of migrating to Jira). During this orientation, I discuss the difference between severity and priority. Severity is the subjective rating of how bad an issue is while priority is a decision of how quickly the bug should be addressed.

Bugzilla supports priority and severity out of the box. Jira does not support severity out of the box. My complaint is the default values supplied for the priority field:

Blocker – Blocks development and/or testing work, production could not run.

Critical – Crashes, loss of data, severe memory leak.

Major – Major loss of function.

Minor – Minor loss of function, or other problem where easy workaround is present.

Trivial – Cosmetic problem like misspelt words or misaligned text

To me, these are clearly severities and not priorities. (To be fair, Jira makes it easy to customize the priorities.) It is also true that generally, the more severe an issue is the higher priority it will have. The counter example I usually use is what happens is the company name is misspelled on the product splash screen. This is a low severity issue. However, in most companies I have worked for, this is a high priority issue to fix (especially when a demo before the executives is scheduled…)