The process of selecting requirements for a release of a software product is challenging as the decision-making is based on uncertain predictions of customer value and development cost. This paper presents a method aimed at supporting software product development organisations in the identification of process improvement proposals to increase requirements selection quality. The method is based on an in-depth analysis of requirements selection decision outcomes after the release has been launched to the users. The method is validated in two separate case studies involving real requirements and industrial requirements engineering experts. The conclusions from the two case studies are that the method seems valuable in situations with complex release planning decisions, such as in market-driven projects. It also appears essential that participants with different viewpoints attend the root cause discussion. Requirements interdependencies seem to play a big role in release planning decision-making. In addition, successful projects can also be a source of learning.

There is a need to identify factors that affect the result of empirical studies in software engineering research. It is still the case that seemingly identical replications of controlled experiments result in different conclusions due to the fact that all factors describing the experiment context are not clearly defined and hence controlled. In this article, a scheme for describing the participants of controlled experiments is proposed and evaluated. It consists of two main factors, the incentives for participants in the experiment and the experience of the participants. The scheme has been evaluated by classifying a set of previously conducted experiments from literature. It can be concluded that the scheme was easy to use and understand. It is also found that experiments that are classified in the same way to a large extent point at the same results, which indicates that the scheme addresses relevant factors.

The second edition of Software Testing and Continuous Quality Improvement by William E. Lewis is a comprehensive, practical cookbook of software testing with a slight mix of quality spices.The aim of the book is to integrate software quality and software testing, with the main focus being on the testing activities.Although there are a lot of books describing software testing, few resemble each other.The reader of this book will probably be a newly-employed software tester, a test manager or a practical software tester who knows how to perform testing but wants to learn more in a taskoriented way.After some initial chapters putting software quality into perspective, the book is a step-by-step guide of how to perform testing.It is practically focused and, in many of the chapters, the reader can follow the tasks (as if they were recipes) when performing testing activities.This is beneficial for testers that want to use the book as a hands-on practical guide.However, when reading the book from the first page to the last, or as course literature, it can become somewhat boring.

The main objective of software inspection is to detect faults within a software artifact. This helps to reduce the number of faults and to increase the quality of a software product. However, although inspections have been performed with great success, and although the quality of the product is increased, it is difficult to estimate the quality. During the inspection process, attempts with objective estimations as well as with subjective estimations have been made. These methods estimate the fault content after an inspection and give a hint of the quality of the product. This paper describes an experiment conducted throughout the inspection process, where the purpose is to compare the estimation methods at different points. The experiment evaluates team estimates from subjective and objective fault content estimation methods integrated with the software inspection process. The experiment was conducted at two different universities with 82 reviewers. The result shows that objective estimates outperform subjective when point and confidence intervals are used. This contradicts the previous studies in the area.

Software validation is an important activity in order to test whether or not the correct software has been developed. Several testing techniques have been developed, and one of these is statistical usage testing (SUT). The main purpose of SUT is to test a software product from a user's point of view. Hence, usage models are designed and then test cases are developed from the models. Another advantage of SUT is that the reliability of the software can be estimated. In this paper, Markov chains are used to represent the usage models. Several approaches using Markov chains have been applied. This paper extends these approaches and presents a new approach to estimate the reliability from Markov chains. The reliability estimation is implemented in a new tool for statistical usage testing called MaTeLo. The tool is developed in a joint European project involving six industrial partners and two university partners. The purpose of the tool is to provide an estimate of the reliability and to automatically produce test cases based on usage models described as to Markov models.

Software quality can be defined as the customers' perception of how a system works. Inspection is a method to monitor and control the quality throughout the development cycle. Reading techniques applied to inspections help reviewers to stay focused on the important parts of an artifact when inspecting. However, many reading techniques focus on finding as many faults as possible, regardless of their importance. Usage-based reading helps reviewers to focus on the most important parts of a software artifact from a user's point of view. We present an experiment, which compares usage-based and checklist-based reading. The results show that reviewers applying usage-based reading are more efficient and effective in detecting the most critical faults from a user's point of view than reviewers using checklist-based reading. Usage-based reading may be preferable for software organizations that utilize or start utilizing use cases in their software development.