You are currently browsing the MEE SQA Blog weblog archives for January, 2007.
January 26, 2007 by mensming.
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.
Posted in system testing, web testing | No Comments »
January 18, 2007 by mensming.
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:
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.”
Readme
Links:
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 Server 2003 - see 928388
Windows 2000 - see description of tzedit.exe in the article below.
Preparing for daylight saving time changes in 2007
Posted in system testing | 1 Comment »
January 13, 2007 by mensming.
Being new to blogging, I am on the lookout for tips and tricks. I came across the following link which shows a video of how to use the backup plugin that comes with WordPress. (Unfortunately for me, my hosting provider does not include the referenced plugin…)
Back Up Your Blog or Risk Losing It All | Tubetorial
Posted in blogging | No Comments »
January 10, 2007 by mensming.
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.
Posted in project management | No Comments »
January 2, 2007 by mensming.
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…)
Posted in jira, bug tracking | No Comments »