Defect Bash - Literature Review
---
paper_title: The 10-Minute Test Plan

paper_content:

The lowly test plan is perhaps the least appreciated of all supporting (read: noncode) software development artifacts. All projects need one, but few engineers appreciate their existence. So it's important to spend no more time than is absolutely necessary in the creation, care, and feeding of the test plan. Ten minutes, to be precise.
---
paper_title: Maximizing the Utility of Customer Product Testing: Beta Test Design and Management

paper_content:

Abstract Many companies regularly use beta tests as part of their product development program. Beta testing can validate the product concept, eliminate performance problems prior to market introduction, and serve as an effective sales promotion device. The risks are significant, however, in that a poorly designed test can destroy account relationship, generate inaccurate data on product performance, and stimulate negative publicity. Robert Dolan and John Matthews present guidelines for effective management of beta test programs. They develop these guidelines based on a literature review, an analysis of twenty-one beta test programs as described in secondary sources, and four in-depth field investigations with cooperating firms.
---
paper_title: Information Security Plan for Flight Simulator Applications

paper_content:

The Department of Defense has a need for an identity management system that uses two factor authentications to ensure that only the correct individuals get access to their top secret flight simulator program. Currently the Department of Defense does not have a web interface sign in system. We will be creating a system that will allow them to access their programs, back office and administrator functions remotely. A security plan outlining our security architecture will be delivered prior to the final code roll out. The plan will include responses to encryption used and the security architecture applied in the final documentation. The code will be delivered in phases to work out any issues that may occur during the implementation.
---
paper_title: The secret life of bugs: Going past the errors and omissions in software repositories

paper_content:

Every bug has a story behind it. The people that discover and resolve it need to coordinate, to get information from documents, tools, or other people, and to navigate through issues of accountability, ownership, and organizational structure. This paper reports on a field study of coordination activities around bug fixing that used a combination of case study research and a survey of software professionals. Results show that the histories of even simple bugs are strongly dependent on social, organizational, and technical knowledge that cannot be solely extracted through automation of electronic repositories, and that such automation provides incomplete and often erroneous accounts of coordination. The paper uses rich bug histories and survey results to identify common bug fixing coordination patterns and to provide implications for tool designers and researchers of coordination in software development.
---
paper_title: Using continuous integration and automated test techniques for a robust C4ISR system

paper_content:

We have used CI (Continuous Integration) and various software testing techniques to achieve a robust C4ISR (Command, Control, Communications, Computers, Intelligence, Surveillance, and Reconnaissance) multi-platform system. Because of rapid changes in the C4ISR domain and in the software technology, frequent critical design adjustments and in turn vast code modifications or additions become inevitable. Defect fixes might also incur code changes. These unavoidable code modifications may put a big risk in the reliability of a mission critical system. Also, in order to stay competitive in the C4ISR market, a company must make recurring releases without sacrificing quality. We have designed and implemented an XML driven automated test framework that enabled us developing numerous high quality tests rapidly. While using CI with automated software test techniques, we have aimed at speeding up the delivery of high quality and robust software by decreasing integration procedure, which is one of the main bottleneck points in the industry. This work describes how we have used CI and software test techniques in a large-scaled, multi-platform, multi-language, distributed C4ISR project and what the benefits of such a system are.
---
paper_title: The 10-Minute Test Plan

paper_content:

The lowly test plan is perhaps the least appreciated of all supporting (read: noncode) software development artifacts. All projects need one, but few engineers appreciate their existence. So it's important to spend no more time than is absolutely necessary in the creation, care, and feeding of the test plan. Ten minutes, to be precise.
---
paper_title: The Management Spectrum

paper_content:

While leadership dominates the attention of many, it is management that drives the work at hand. Julian Birkinshaw and Jules Goddard suggest that you reconsider the management model you practice daily to see if it's really working inside your company.
---
paper_title: The Persona Lifecycle: Keeping People in Mind Throughout Product Design

paper_content:

Offering techniques and tools related to planning, creating, communicating, and using personas to create great product designs, this innovative text addresses the how of creating effective personas and using them to design products that people love.
---
paper_title: Microdynamics of process evolution

paper_content:

Presents the seven basic steps of opportunistic software process evolution. (1) Notice problems in products or outcomes. (2) Choose an important or chronic problem and look for a way to solve it, in whole or in part. (3) Conceive of a new, borrowed or modified process that could solve the problem at an acceptable cost and in an acceptable time frame. (4) Try the new process on a real project. (5) Adjust the process in light of experience and in light of the new problems that were created by the process. (6) If the solution is worth perpetuating, look for a way to make it more efficient or durable by adding infrastructure (such as documentation, training or tool support). Otherwise, try to understand why it doesn't seem to work. (7) Return to step 1. Pay attention to projects on the scale of hours, cubicles, people and episodes. In complex cognitive processes like software development, if process evolution is foiled on the micro scale, it will be foiled utterly.
---
paper_title: The secret life of bugs: Going past the errors and omissions in software repositories

paper_content:

Every bug has a story behind it. The people that discover and resolve it need to coordinate, to get information from documents, tools, or other people, and to navigate through issues of accountability, ownership, and organizational structure. This paper reports on a field study of coordination activities around bug fixing that used a combination of case study research and a survey of software professionals. Results show that the histories of even simple bugs are strongly dependent on social, organizational, and technical knowledge that cannot be solely extracted through automation of electronic repositories, and that such automation provides incomplete and often erroneous accounts of coordination. The paper uses rich bug histories and survey results to identify common bug fixing coordination patterns and to provide implications for tool designers and researchers of coordination in software development.
---
paper_title: Using continuous integration and automated test techniques for a robust C4ISR system

paper_content:

We have used CI (Continuous Integration) and various software testing techniques to achieve a robust C4ISR (Command, Control, Communications, Computers, Intelligence, Surveillance, and Reconnaissance) multi-platform system. Because of rapid changes in the C4ISR domain and in the software technology, frequent critical design adjustments and in turn vast code modifications or additions become inevitable. Defect fixes might also incur code changes. These unavoidable code modifications may put a big risk in the reliability of a mission critical system. Also, in order to stay competitive in the C4ISR market, a company must make recurring releases without sacrificing quality. We have designed and implemented an XML driven automated test framework that enabled us developing numerous high quality tests rapidly. While using CI with automated software test techniques, we have aimed at speeding up the delivery of high quality and robust software by decreasing integration procedure, which is one of the main bottleneck points in the industry. This work describes how we have used CI and software test techniques in a large-scaled, multi-platform, multi-language, distributed C4ISR project and what the benefits of such a system are.
---
paper_title: The Management Spectrum

paper_content:

While leadership dominates the attention of many, it is management that drives the work at hand. Julian Birkinshaw and Jules Goddard suggest that you reconsider the management model you practice daily to see if it's really working inside your company.
---
paper_title: Team Exploratory Testing Sessions

paper_content:

Exploratory testing (ET) is popular, especially among agile development teams. In this paper, we study the team aspect in the ET context and explore how to use ET in team sessions to complement other testing activities. The goal was to define a team exploratory testing (TET) session approach and to provide evidence that the approach is worth using. A TET session approach is defined by means of parameters, roles, and process. Also, instructions for using the approach are given. The team is the key factor that gives the approach its value and distinguishes it from basic ET. The team enables greater access to expertise, experience, and information. The TET session approach enables participants with different professional background to join in the session. The sessions may be focused on different purposes; they can contribute to finding defects or learning the system, for example. With careful parameter definition, the approach’s risks are mitigated.
---

Title: Defect Bash - Literature Review

Section 1: INTRODUCTION
Description 1: Introduce the topic of defect bash, its significance in software testing, and state the goals and structure of the paper.

Section 2: SYSTEMATIC LITERATURE COLLECTION
Description 2: Explain the systematic literature review method used to gather information on defect bash, including sources and search strings.

Section 3: DEFINITION
Description 3: Provide the various definitions of defect bash found in the literature.

Section 4: BENEFITS
Description 4: List and describe the benefits of defect bash as mentioned in the reviewed literature.

Section 5: LIMITATIONS
Description 5: Outline the limitations of defect bash identified in the reviewed literature.

Section 6: PROCESS
Description 6: Detail the processes involved in conducting a defect bash, including preparation, the defect bash session, and post-process activities.

Section 7: CONCLUSIONS
Description 7: Summarize the findings of the literature review, discuss the implications, and suggest future research directions.