When we speak of "performance", we are most often using this as a general term applied to systems that denotes how well the system fulfills the tasks expected of it. A system with good performance is generally taken to be one that is stable, responds quickly to requests made of it, and has acceptable throughput levels....   Read Article.

Capture/playback tools make it possible to repeat two or more tests identically and compare the results. This article focuses on capture/playback tools, which hold the largest market share of any test tool category, and on examining trouble spots in test automation, dealing with them proactively and perhaps mitigating the risks of tool abandonment....   Read Article.

This article is based on an paper I wrote awhile back that was meant to be a general guideline document for a hypothetical organizational quality strategy called TechQA. The purpose of this article is to review current testing procedures, planned test strategies, and product design processes utilized by this putative TechQA in order to make recommendations...   Read Article.

This article is based on a paper that I wrote earlier in my career (around 1995 or so) when I thought automation was the be-all, end-all of the testing world. This was sort of an idealistic paper but I think it still contains a few kernels of truth....   Read Article.

In the current environment we have software products that are getting larger, more complex, with a greater degree of various interdependencies, and yet time-to-market is more a priority than ever. Because of the growth of testing cycles along with the growth of software products, the idea of automating testing in some fashion has become an increasingly...   Read Article.

Note: Much of the work for this article came out of reading the work of W. Edwards Deming, Philip Crosby, and Joseph Juran. I also owe a debt to Tom Gilb, whose thinking started me on the path of 'competitive engineering'. I particularly recommend the following books by Gilb...   Read Article.

Operational requirements are basically another way of talking about controlled requirements. (You might want to check out my article on Controlled Requirements.) The focus on operational requirements, from the levels of control and basic processes that I discussed in the "Controlled Requirements" article, is on quantification....   Read Article.

The notion of "controlled requirements" is certainly an interesting one in that I either see people make too much of it on the one hand or too little of it on the other. The very simple basis of these types of requirements are levels of control....   Read Article.

It would seem that Ivar Jacobson's original Objectory method was the birthplace of the formal idea of the use case. This seems to have come from his 1992 book Object-Oriented Software Engineering: A Use Case Driven Approach. It should be noted that "use" is meant to be pronounced as "youce", not "youze". Use cases are one tool of requirements gathering....   Read Article.

As G.K. Chesterton once said, "It isn't that they can't see the solution. It's that they can't see the problem." A large part of the overall quality effort is making sure that the product being considered as a release candidate meets the requirements that were established for it. However, simply meeting requirements alone does not...   Read Article.

The interleaved requirements process seems to be something that a lot of people are asked to do but have no idea what it is. In fact, sometimes it does not even go by that name. In a nutshell, the notion of interleaved requirements is the basis behind a life cycle that acknowledges the need to develop software architectures that are stable and flexible...   Read Article.

Requirements tracing is the process of documenting the links between the user requirements for the system you are building and the work products developed to implement and verify those requirements. These work products include software requirements, design specifications, software code, test plans and other artifacts of the systems development process....   Read Article.

Requirements engineering is, in part, looking at ways to document and manage changes to the agreement between the business and its customers. As Karl Wiegers (in his book Software Requirements) has said: "The goal of requirements engineering is to develop high quality - not perfect - requirements that allow you to proceed with construction at an acceptable...   Read Article.

The difference between a requirement and a specification is basically one of what and how. The requirements define what is going to be done and what is going to be done usually means necessary objectives that the organization feels will be beneficial to the end-users as well as to the revenue of the organization itself....   Read Article.

Behind any concerted effort to build, launch, or maintain a given product, whether that be embedded software, a desktop application, hardware, or a Web site there is the idea or overall concept of what the organization wants done. This will not necessarily dictate how something should be done, just what should be done usually with an explanation of...   Read Article.

[This article was written by David Garmus and David Herron, both of The David Consulting Group and is re-printed here via STSC with permission. It is basically an article that talks about the use of function points but did so in an easy-to-understand manner. I have altered some formatting but no content has been altered.]...   Read Article.

[Please note that this article is directly based on one written by Tom Gilb. That article is Impact Estimation Tables: Understanding Complex Technology Quantitatively, located at his Web site. While this is not a direct copy of that article, the work shown here should be understood to be that of Tom Gilb. My goal here is simply to present this work...   Read Article.

The reason for the strong emphasis on software cost estimation is that it provides the vital link between the general concepts and techniques of economic analysis and the particular world of software engineering...   Read Article.

Risks are not solely determined by the size of the effort of a particular project. Risks are affected by the impact of the project on the organization, and by the potential possibility of occurring. We have to realize that risk management is an often-overlooked project management function....   Read Article.

This article is basically summarizing an article that I wish was better known and more often read. The article in question is "How to Staff Business-Critical Maintenance Projects" by Ramkumar Ramaswamy (IEEE Software, May/June 2000)....   Read Article.