Testing History

Recently I came across the website www.testingreferences.com whose author Joris Meerts did a great job in collecting a history of testing. In addition, he  provides a pretty extensive listing on

  • Testing web sites
  • Testing blogs
  • Testing videos (educational)
  • Testing literature

I am sure you will love this site. As the list is pretty long I will tell you my personal shortlist here:

Testing Classification for Focused Test Planning

Testing can mean very different things, depending on the software to be tested, the organization in which the testing takes place, and several other factors. Since testing can be so different, it is useful to have a classification system for testing at hand. It can guide test management during planning and preparation of the various test activities.

A notable classification of testing has been proposed by Robert L. Glass, along with recommendations for test planning. I came across it in late 2008, when I read one of his columns in IEEE Software magazine. Let’s have a look on Glass’s testing classification and discuss what it means to test management practice. At the end of the article, you find references to additional information.

Glass classifies testing along two dimensions. The first dimension is the goal of testing, i.e., the main principle that drives identification of test cases. There are four goal-driven approaches to testing: (1) Requirements-driven testing derives test cases from defined requirements. (2) Structure-driven testing derives test cases from the software’s implementation structure. (3) Statistics-driven testing derives test cases from typical and frequently conducted usage scenarios of the software. (4) Risk-driven testing derives test cases from the most critical software-related risks.

The second dimension of Glass’s model refers to the phase of the software development lifecycle, in which the testing takes place: (1) Unit testing involves the lowest-level components of the software product. (2) Integration testing involves the intermediate-level of the software product and lifecycle. (3) System testing involves the final level of software development.

Glass argues that both dimensions must be combined. For each combination, he recommends the degree at which the respective testing type shall be executed. The following table summarizes the recommendations.

Testing phase
Testing approach Unit testing Integration testing System testing
Requirements-driven 100% unit requirements 100% product requirements 100% system requirements
Structure-driven 85% logic paths 100% modules 100% components
Statistics-driven 90-100% of usage profiles if required
Risk-driven As required As required 100% if required

How can we use this classification system and its recommendations?—First, it tells us that testing focus should be different in different lifecycle phases or stages of product aggregation. Second, the classification system recommends that we shall aim for complete requirements coverage in every testing phase, while other testing approaches should be emphasized mainly during the later phases of testing. This way, we receive guidance for focused and more efficient testing.

While I value the essence of Glass’s classification very much, I partly question the first dimension of testing approaches, and I am particularly sceptic of the recommended 100% testing degree for the requirements-driven approach. In my opinion, only the first two testing approaches are basic and fundamentally different categories: Requirements-driven and structure-driven testing. The other two approaches, statistics-driven and risk-driven, are variants of the basic approaches. Statistics-driven usage scenarios and risk can only be determined based on requirements or structure. So, those latter approaches are means for focusing requirements-driven and structure-driven testing.

Why am I sceptic of the 100% degree for requirements-driven testing? I find it impractical for several reasons: First, most testing that I have encountered suffered from severe time and resource constraints, which clearly demanded “less than 100% testing!” Second, requirements are often vague and uncomplete. So, 100% of something vague is just an illusion of 100%. Third, hardly any project has explicitly stated unit and product requirements. As a consequence, there is no basis for stipulating any kind of test coverage for those requirements types.

However, the basic messages from Glass’s testing classification remain valid and important: Distinguish between requirements-driven and structure-driven testing, and apply different kinds of testing at different phases of system aggregation. Also use statistics-driven and risk-driven approaches for focusing testing. In an earlier article, I have proposed a pragmatic approach for establishing good test coverage based on those principles: Two Essential Stages of Testing.

Further information about Robert L. Glass’s classification can be found in two of his columns in IEEE Software magazine and in a publically available excerpt from one of his latest books: An Ancient (but Still Valid?) Look at the Classification of Testing (IEEE Software magazine Nov/Dec 2008), A Classification System for Testing, Part 2 (IEEE Software magazine Jan/Feb 2009), and The Many Flavors of Testing (Book Excerpt).

http://makingofsoftware.com/archives/358Two

Requirements Prioritization

Beyond the Limits of One-Dimensional Lists

Prioritizing requirements for a software release is an activity which frequently crosses the border between science and psychology. The goal is to determine the right set of things to do for a release. For many IT projects this turns out to be a moving target.

In software product development, requirement priorities are set by the product manager. Typically a product manager focuses exclusively on the market need of a requirement and its selling potential. Excellent software companies look at additional factors as well:

  • Cost
  • Risk
  • Fit to product strategy and architecture
  • Ability to deliver

Creating estimates for these factors cannot be done by a single person. Experts from different domains are needed.

There is a couple of techniques available to cope with this issue. Most of them are based on “cost-value” approaches. In my projects, I have applied a variety of them ranging from simple to complex ones. Often we started with something similar to Karl Wieger’s requirements prioritization approach (see www.processimpact.com).

Ultimately, these techniques yield a list of requirements ordered by their relative priority. Such a list is charming because you can always pick the most important requirement next. It is so charming, that this approach has made it into today’s most prominent development approach: Agile methodologies. In agile projects, the term “product backlog” describes a priority-ordered list of work items, which are addressed from top to bottom.

However, there are some shortcomings with these approaches, which need to be overcome in industrial practice. The key problem is the underlying assumption that requirements can be prioritized independently from each other.

Experience shows that this is seldom the case. Most requirements are interdependent from other requirements.

Across many industry domains including software and IT, the fundamental approach to building a system is always the same: A high-level plan is decomposed until the units of work are manageable. Elements of such units share some characteristics. They belong to the same domain and have similar complexity. Rating such elements in relative order works well. However, if the elements are from different domains, you may run into problems: They might have architectural dependencies which cannot be addressed in isolation. Many times, I saw projects getting stuck, because one team was waiting for something that another team had decided to lower in priority.

This problem of deadlock situations can be addressed by explicit dependency management. In requirements engineering, the concept of traceability is used to manage dependent work-items. Directional links express dependency relationships. These techniques exist and are available in most modern requirements management tools. However, in practice, these solutions can be very hard to accomplish, because they require more discipline than most projects are able to bring up.

So I recommend to deploy lightweight traceability using tagging mechanisms at requirements. Sometimes multiple backlogs are used. Each backlog holds items from the same domain. I have seen such approaches working pretty well in many project situations. So they might be the optimal solutions with the right mix of rigor and flexibility.

And don’t forget the importance of communication: Whatever approach one uses, it will be successful only if it is accompanied by good communication structures in the organization.

Two Essential Stages of Testing

Good test coverage is important and sometimes not easy to achieve. A simple principle can lay a solid foundation for test coverage: Distinguishing two essential stages of testing.

The initial low-level stage tests basic development artifacts immediately or soon after they have become available. This is usually called component, module or unit testing.

The later high-level stage tests the entire system or its higher-level aggregates as early as possible and lasting until very close before product delivery. This is usually called acceptance test.

The concepts of low-level and high-level tests are not new. Important is to relate them to different phases of the development cycle (or to activities within agile iterations, likewise; levels become stages) and to systematically plan associated activities. This way, good test coverage  can be achieved very efficiently.

Low-level testing stage High-level testing stage
Tests cover implementation of each basic development artifact from an implementation point of view (white or grey box testing) Tests cover design of the entire system or major system part from a business or usage point of view (black box testing)
Test cases defined by developers; derived from requirements and design Test cases defined by testers, domain experts from the software team, and/or customers; derived from explicit requirements or tacit domain knowledge
Tests conducted by developers Tests conducted by testers and/or customers or users
Defects usually fixed immediately or otherwise entered into defect database Defects usually entered into defect database, fixed, and being re-tested

I have seen many projects in trouble, because they did not properly address these test stages. Sometimes, low-level testing was replaced by pure faith (“My programs always run well”). Sometimes, high-level testing was shallow and ineffective (“We don’t have any time for more tests”). Often, the relation between both stages was not managed well, lowering product quality and limiting the efficiency of testing.

Taking care that both stages of testing are being addressed is a first and important step towards improved testing. Both stages are complementing each other well, so that higher test coverage can be achieved without very little planning and qualification efforts. This is also a good basis for subsequent improvement activities.

Additional details on the concepts of low-level and high-level testing are described in the testing literature, although the relation between the levels and phases of the development lifecycle is often not explored very much. A very instructive book is TMap® Next by Koomen et al. (2006). Another elaboration on the two testing levels are Brian Marick’s agile testing quadrants. Lisa Crispin’s presentation on  agile test planning provides a detailed explanation of those quadrants. Finally, an inspiring reflection on testing is Robert L. Glass’s text on The Many Flavors of Testing.

Quality Center Workflow Debugging

State of the art workflow debugging with HP Quality Center using Microsoft Visual Studio.

Users of HP Quality Center (HP QC) who do workflow programming often suffer from the very limited – not to say: lacking – support that HP QC offers for debugging of workflow code. It can easily happen that programmers spend hours in search of a tiny but nasty defect.

But there is help that greatly improves workflow programming and debugging in HP QC: You may use Microsoft Visual Studio (MVS) as a debugging environment for HP QC workflow programs. You can then add breakpoints, inspect variables, step through programs, and much more. All you need to do is the following:

  1. Launch HP QC
  2. Open the workflow editor in HP QC
  3. Launch MVS
  4. Attach the HP QC process to Visual studio
    (process name “iexplore.exe”, title “Script Editor”)
  5. Within project explorer window double click on “blank”
    (or “leer” in case you run a German version of MVS)

Final step to get HP QC into MVSNow, you should have your workflow code accessible within Microsoft Visual Studio, and debugging will be much more comfortable and efficient than before. See the attached picture to get an impression about debugging with breakpoint and variable inspection.

If you can’t see the line with “blank” make sure that you are in the requirements module and have at least a single custom line of workflow in the requirements module.

I got it to work with QC Version 10 and MVS 2008 Professional.