When Should a Test Be Automated?

This paper describes how I think about the tradeoffs. Scenario

Experience With The Cost Of Different Coverage Goals For Testing

this paper

Experience With The Cost Of Different Coverage Goals For Testing

this paper. What percentage of branch, loop, multi-condition, and weak mutation coverage can be expected from thorough unit testing? Seven units from application programs were tested using an extension of traditional black box testing. Nearly 100% feasible coverage was consistently achieved. Except for weak mutation, the additional cost of reaching 100% feasible coverage required only a few percent of the total time. The high cost for weak mutation was due to the time spent identifying impossible coverage conditions. Because the incremental cost of coverage is low, it is reasonable to set a unit testing goal of 100% for branch, loop, multi-condition, and a subset of weak mutation coverage. However, reaching that goal after measuring coverage is less important than nearly reaching it with the initial black box test suite. A low initial coverage signals a problem in the testing process. BIOGRAPHICAL SKETCH Brian Marick graduated from the University of Illinois in 1981 with a BA in English Literature and a BS in Mathematics and Computer Science. Until 1989, he worked in product development as a programmer, tester, and line manager, while attending graduate school as a hobby. The work reported here was a result of a research project funded by a Motorola Partnerships in Research grant through Motorola's Software Research Division. He is currently applying the techniques and tools reported here to Motorola products, training others in their use, and planning further investigations of cost-effective and predictable testing techniques. Author's address: Motorola, 1101 E. University, Urbana, IL 61801. Phone: (217) 384-8500 Email: [email protected] or [email protected]. 1. Introductio

The effects of wetting and drying cycles on the dry density of compacted cohesive soils

The objective of this study was to determine the factors that control the change in dry density of a soil when subjected to cyclic wetting and drying. The Gasconade Clay, a cohesive soil of low plasticity, was used in this study. Three samples for each of four different dry densities, were tested in this study. For each density, the samples were tested at two different confining pressures. The amount of accumulative volume change for each cycle was recorded in all cases. Samples tested dry of OMC experienced a greater amount of shrinkage at a confining pressure of 8 psi rather than 3 psi. As the dry density of the soil increased the amount of volume change decreased. For the samples compacted wet of OMC, the amount of shrinkage increased as the dry density decreased. The samples tested at a confining pressure of 8 psi experienced less shrinkage than the samples tested at 3 psi. It was found that for each dry density and confining pressure, the amount of volume change experienced was different. It was determined that the final dry density of a soil, after being subjected to cyclic wetting and drying, depends upon the initial dry density and water content --Abstract, page iii

Methodology Work Is Ontology Work

I argue that a successful switch from one methodology to another requires a switch from one ontology to another. Large-scale adoption of a new methodology means "infecting " people with new ideas about what sorts of things there are in the (software development) world and how those things hang together. The paper ends with some suggestions to methodology creators about how to design methodologies that encourage the needed "gestalt switch". In this paper, I'm going to abuse the word "ontology". In philosophy, an ontology is an inventory of the kinds of things that actually exist, and (often) of the kinds of relations that can exist between those things. My abuse is that I want ontology to be active, to drive people's actions. I'm particularly interested in unreflective actions, actions people take because they are the obvious thing to do in a situation, given the way the world is. Here are some examples of ontologies

Working Effectively With Developers

This paper is about my approach to working effectively with developers. I expect that you, my reader, are a tester and spend most of your time looking for bugs, talking to developers, and writing bug reports. This paper describes three things I've learned to do better over the years: 1. Define my role in a way that makes a developer want me around. I help the developer get rid of bugs before anyone else sees them, which reduces total project cost. 2. Explain myself and my job such that a developer gives me the benefit of the doubt. I reduce the opportunity for snap judgements about me, and I take an unusual approach to convincing the developer that bug reports should not be seen as threats. 3. Write bug reports in a way that allows for little misinterpretation. The three main sections are largely independent. The techniques do not depend on each other. 1. Picking an Effective Rol