When writing software test automation, some of the main ways you can store test case data include embedding the data directly into your test harness, storing as a simple text file, storing as an XML file, storing in a SQL database, and storing in an Excel file. Excel 2007 uses an interesting new file format called the "Open XML File Format" that changes the way in which you access data programmatically. The new file format is essentially XML (which provides a non-proprietary, easy to use format) which is compressed (which provides an efficient small size). Suppose I have test case data stored in an Excel 2007 worksheet named TestCases.xlsx and which looks like this:

 

caseID arg1 arg2 run      expected
001      3.5   4.1   TRUE   7.6
002      2.4   1.3   FALSE  3.7
003      5.2   3.3   TRUE   8.5

 

The .xlsx file is actually a .zip file so if I rename the file as TestCases.zip and then extract the compressed data using WinZip or some other utility, I will see three directories (_rels, docProps, xl) and one file named [Content_Types].xml. The actual data is contained in files sharedStrings.xml (located in the xl directory) and sheet1.xml (located in a subdirectory named \xl\worksheets). The sheet1.xml file contains XML including:

 

<sheetData>
  <row r="1" spans="1:5">
  <c r="A1" t="s">
    <v>0</v>
    </c>
  <c r="B1" t="s">
    <v>1</v>
    </c>
(etc.)

 

This means row 1 has 5 columns. The column at row A1 contains a string (t="s") whose value is index 0 (<v>0</v>). All string values are stored in a sharedStrings.xml file so that duplicate string need only be stored once. The sharedStrings.xml contains in part:

 

<si>
  <t>caseID</t>
</si>
<si>
  <t>arg1</t>
</si>
(etc.)

 

This means the string at [0] is "caseID", the string at [1] is "arg1", and so on. File sheet1.xml also contains:

 

<row r="2" spans="1:5">
  <c r="A2" s="1" t="s">
    <v>5</v>
  </c>
  <c r="B2">
    <v>3.5</v>
  </c>
(etc.)

 

This means the value at cell B2 is 3.5 -- non-strings are simply stored as is. In short, Excel 2007 data is stored as compressed XML. To programmatically access Excel 2007 data you can use standard XML parsing techniques, and although the process is simple in principle the details can be a bit messy. 

When I was working as a software test engineer at Microsoft, test automation was a relatively new area. The majority of software testing was still done manually in the mid 1990s. Around that time I coined the acronym "SAPES" to describe the advantages of software test automation compared to manual testing.  SAPES stands for speed, accuracy, precision, efficiency, and skill-building. Speed - test automation can execute test cases much faster than manual testing. Accuracy - test automation is not as prone to human errors such as incorrectly recording a test case result. Precision - test automation executes the same way every time but manual testing executes slightly differently. Efficiency - test automation can run overnight or while you are performing more interesting testing. Skill-building - writing test automation increases your skill-set while manual testing can be mind-numbingly boring. These advantages of test automation over manual testing are of course well known, but the SAPES acronym nicely summarizes the advantages. 

I manage training for all kinds of software engineers (developers, testers, support engineers, network engineers, and so on) working at Microsoft. One of the biggest trends we've seen over the past 24 months is the increasing importance of engineers having basic project management skills. Software engineering as a whole is becoming more mature -- systems are becoming larger and more complex. Larger and more complex software systems require more management. But in general, existing project management resources are not well suited to a software environment. The Project Management Institute (PMI) dominates project management certification, but PMI certification focuses on principles that apply to all industries. Sure general knowledge is vital, but, for just one instance, cost estimation in the software industry is much different from cost estimation in the construction industry. Furthermore, the PMI, like all organizations, has one primary objective: generating revenue for PMI. This leads to over-priced PMI training and an exclusionary rather than collaborative attitude. The CompTIA company has a very lightweight Project+ certification which is aimed more at software engineering. It is pretty decent, but is really a repackaging of PMI essentials. There are no existing project management certifications that meet my personal definition of "very good" in the context of software engineering. The major problem is that until just recently, software engineering was changing too fast for solid techniques and a stable body of knowledge to be established -- developing a commercial Web application using Agile methodologies is much, much different from developing an industrial application using a traditional waterfall model. But the software industry is definitely maturing. I believe that there is a significant market opportunity here and that sooner or later (say, within 7 years) some organization will develop and release a comprehensive set of materials for project management in a software engineering environment that gains widespread acceptance in the software industry.

If you are a software tester, sooner or later you'll have to deal with software risk analysis and management. Risk is loosely defined as the possibility that an unwanted event can happen. Risk analysis is the process of identifying and estimating the likelihood of possible risks. Here's an example. First you list possible risk events. Risk analysis can happen at different levels. For example, at a management level, risk events are things like key personnel quitting. At an implementation level, risk events are things like choosing a multi-threaded architecture for improved performance vs. choosing a single-threaded architecture for simplicity. And as a tester, risk events are often not discovering a particular type of bug. Let's suppose you are worried about 3 arbitrary risk events, A, B, C. Now you must estimate the probability of each of these events. Suppose you guess that the probability of risk events A, B, and C are 0.3, 0.4, and 0.1 respectively. Notice that because the risk events are not necessarily related, their probabilities need not sum to 1. Now you must estimate the risk impact of each risk event. Let's imagine that you assign the costs of events A, B, and C as $1000, $3000, and $6000 respectively. You can now compute the so-called risk exposure of each event, which is just the probability of the event times the impact:

 

A: (0.3)($1000) = $300
B: (0.4)($3000) = $1200
C: (0.1)($6000) = $600

 

You can use this information to help prioritize where you spend your resources. Next you can compute your overall risk exposure, which is just the sum of the individual events' exposures: $300 + $1200 + $600 = $2100. You can use this value to compare against previous risk analysis data from other projects, and you can use the value to estimate your likely cost overruns from your base budget.

I am not a fan of the risk analysis procedure described above. All the numbers give a very false sense of the accuracy and precision of the process. Here's an alternative approach I prefer. Instead of assigning numerical probabilities to each risk event, you assign a likelihood attribute of L, M, or H (for low, medium, and high). Then instead of assigning a numeric (money) cost for the impact, you assign one of the same L, M, H attributes. So, the example above might translate to the following where the first attribute is the likelihood, and the second attribute is the impact:

 

A: M x L -> ML
B: H x M -> HM
C: L x H -> LH

 

Each risk event will be described by one of 9 attribute pairs: LL, LM, LH, ML, MM, MH, HL, HM, HH. You should pay most attention to the HH and HM risk events. You can often ignore LL and LM risk events. How you treat the other five risk types will depend on your particular situation.