Search

Standard software testing might not catch important defects, and formal methods can be difficult to use. But, there's a middle ground between the two. This middle ground involves adding five steps to standard testing and employing test randomization, model-based testing, and a more aggressive use of assertions (also called self-tests). [ABSTRACT FROM PUBLISHER]

This article gives a short overview of the main characteristics of mutation tools. If a test suite finds all the artificial errors inserted in the mutants and finds no fault in the original, it's likely that the program under test is free of them. Obviously, the validity of this affirmation depends on the nature of the artificial fault: some of them are better than others. This testing technique has been used in the research arena to check the effectiveness of new proposed testing techniques, but it hasn't been used until recently in industry due to its costs and the lack of knowledge and industrial tools. [ABSTRACT FROM PUBLISHER]

Developers of embedded systems are driven to constantly improve product quality, reduce cost, and rapidly deliver reliable working code. The embedded software domain applies constraints which can hinder agile methodologies commonly used to achieve such benefits. Simulation-based software development is one proven method that addresses these constraints. When tailored to work in conjunction with agile principles, simulation centric development facilitates meeting product goals. In this article, the authors discuss techniques for leveraging software-in-simulation (SiS) in conjunction with agile methodologies, and illustrate how combining agile with SiS contributes to gaining more benefit from agile practices and facilitates better software development. [ABSTRACT FROM PUBLISHER]

James Gimpel gives some fascinating insights into the growth, technology, and impact of the very widely used static analyzer, PC-lint in the never-ending battle against the bug. [ABSTRACT FROM PUBLISHER]

A personal narrative is presented which explores the author's experience of testing safety-critical flight control softwares with various organizations such as Aeronautical Development Agency, Moog India Technology Centre and Defense Research and Development (R&D) Lab, India.

The article focuses on the role of traceability in establishing evidence regarding the hazards and risks related to specifications and implementations of safety critical software devices such as pacemakers and train signals. Topics discussed include strategic practices to provide cost-effective support to evaluate a system's safety, traceability standards in safety-critical projects and analysis of traceability project documents by the U.S. Food and Drug Administration for medical devices.

The article offers information related to the DO-178C, software considerations in airborne systems and equipment certification document published by Radio Technical Commission for Aeronautics (RTCA) Inc. in 2011. It discusses the testing-based verification activities under the DO-178C which includes two processes that involves requirements-based and structural coverage analyses.

The article focuses on the role of model-driven approaches in the development of high-quality and cost effective safety-critical software for air traffic control (ATC). Topics discussed include interoperability of the model driven architecture (MDA) development paradigm, integration of MDA into the verification and validation (V-model) and MDA and Model-Driven testing in a V-Model.

The article focuses on the need of statistical model checking (SMC) of safety-critical softwares to validate software reliability at an early stage. It mentions that the softwares should be checked to prevent the propagation of reliability allocation errors and design errors at later stages. It further discusses a case study related to SMC of fault-tolerant fuel control system (FFCS) a safety-critical component of an automobile's engine controller.

Testing is a destructive task in which the goal is to find relevant defects as early as possible. It requires automation to reduce cost and ensure high regression, thus delivering determined quality. This article reviews technologies for test automation. [ABSTRACT FROM PUBLISHER]

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. [ABSTRACT FROM PUBLISHER]

The article presents a case study on the experience of a subdivision of FedEx, a Fortune 500 global courier delivery firm, in implementing the business rules approach and examines its effects on software testing throughout the software development life cycle (SDLC). Topics include business rules management systems (BRMSs), adoption and implementation of available BMRS products such as iLog and Tibco, and benefits and challenges of using business rules approach.

The article discusses research on cost reduction in mutation testing. Mutation testing is a testing technique that has shown worth in the evaluation of software and software testing techniques. Applicable mutation testing tools such as Bacterio should have requirements such as a selective set of generally applicable mutation operators, the means to choose a random set of mutants, and compiled-code level mutation. The tool should support executing test cases, program instrumentation, and n-order mutation to reduce result analysis costs.

The article presents a discussion of the usage of static code analysis to ensure that embedded software performs according to specifications and does not fail. The usefulness in applying static code analysis prior to code inspections and unit testing is mentioned, noting that it can detect defects in software after the code successfully compiles. Its nearly automatic nature is described, mentioning that it can be applied prior to verification techniques that are more manual in nature. The article also examines the practical application of static code analysis in common situations.

The article discusses technological innovations that will help create automatic software testing programs for computers. It is theoretically impossible to create a program that can automatically test and debug every line of code in a software application, but tools that can test large portions of C programs would be better than any previous technology. Software engineers at Microsoft Corp. have worked on dynamic test generators which offer significant improvements over static test generators. They are using a combination of symbolic execution, dynamic analysis, and systematic state-space exploration tools to test their software.

The article offers information on how to manage agile project requirements through storytest-driven development, a complementary form of test-driven development applied to overall system development. It discusses the use of FitLibrary, a wiki-based tool that supports storytests, in easing storytest-driven development which draws requirements and automated testing ideas and practices to support agile software development. The author describes storytest-driven development practices and presents storytest examples developed with FitLibrary. In addition, the process of structuring storytests and the challenges in storytest-driven development are presented.

The article discusses how static code-analysis tools are used and what defects they can detect. It compares several open source tools which reduces the number of bugs of all software types before deploying the more expensive verification techniques. The author explains that programmers employs static checkers after compilation and before testing, they work with a program that has an initial indication of correctness and avoid well known traps and pitfalls before measuring it against its specifications. Open source tools used to detect defects includes FindBugs static code checking in Java developed by the University of Maryland, the program compiles but fails to do the programmers wants, and the PMD and Checkstyle, are tools used for coding problems.

The article focuses on the increasing popularity of parameterized unit tests to document customer requirements, reflect design decisions, protect against changes and achieve set code coverage goals during testing. Developers at Microsoft Corp. commonly utilize unit tests such as Extreme Programming and test execution frameworks which cover only specific cases and cannot automate creation of a comprehensive set of unit tests. But developers are more positive with their parameterized unit tests that use symbolic execution techniques, which increase code coverage by finding relevant variations of existing unit tests. This depends on inputs which describe behavior more concisely than traditional unit tests.

This article focuses on debugging of computer softwares through unit testing. Unit testing offers a way to keep bugs in check. First, it applies to individual pieces of code-typically, functions or methods and unless these smallest pieces are correct, the whole software edifice, is sure to crumble. Second, unit testing lets the people who write the code units also test them-if only programmers would buy into it. Testing smokes out the bugs, but programmers are generally loath to devote time to anything but coding. Easy integration of coding and unit testing lies at the heart of Extreme Programming and the agile software development movement. In agile programming, software is constructed by implementing functionality incrementally, in short spurts of activity. Individual tests are called test cases. Test cases seldom exist in a vacuum. If a project undertakes serious unit testing, it will accumulate a large test case collection. Often, programmers seem to exercise some of these cases together. When this occurs, they can combine the cases into test suites that run as a single group.

This article discusses the value-based processes for component off the shelf (COTS)-based applications. Economic imperatives are changing the nature of software development processes to reflect both the opportunities and challenges of using COTS products. Traditional software process models fail to accommodate many challenges of using COTS, however, because their process guidance is overly sequential or underdetermined. Project teams often scope the COTS assessment and selection process on the basis of COTS products' likely cost. A better scope criterion is the amount of risk exposure involved in choosing the wrong combination. For example, a supply chain project team scoped its assessment based on the COTS products' cost of US$200,000, but the loss from picking an incompatible combination of best-of-breed COTS products ran about $3 million plus eight months of delay. Had they invested more than $200,000 in COTS assessment to include interoperability prototyping, they would have been able to switch to a more compatible COTS combination with only minor losses in effectiveness and without expensive, late rework.

Focuses on a software tool called Signpost which notifies programmers of known program faults and steps required to fix them that can help programmers debug a program in less time and with less effort. Usefulness of knowledge bases developed by various vendors in helping programmers deal with bugs; Features of Signpost's description language; Strategy used by Signpost in matching articles of a knowledge base with bugs.

Focuses on the use of deterministic execution debugging and testing in solving the nondeterministic execution of concurrent programs. Conventional approach used in sequential program testing; Example of concurrent program behavior.

Reports the use of a functional testing theory in testing computer programs. Principal goal in program testing; Use of oracle in theoretical computer science; Kinds of synthesis.

Compares structural test coverage metrics in computer program testing. Definition and goal of testing; Categories of strategies in the selection of test cases; Infinity of possibilities in programming with loops.

Continuous integration has been around for a while now, but the habits it suggests are far from common practice. Automated builds, a thorough test suite, and committing to the mainline branch every day sound simple at first, but they require a responsible team to implement and constant care. What starts with improved tooling can be a catalyst for long-lasting change in your company's shipping culture. Continuous integration is more than a set of practices, it's a mindset that has one thing in mind: increasing customer value. The Web extra at http://youtu.be/tDl_cHfrJZo is an audio podcast of the Tools of the Trade column discusses how continuous integration is more than a set of practices, it's a mindset that has one thing in mind: increasing customer value. [ABSTRACT FROM PUBLISHER]

Modern virtualization technology allows us to run operating systems in a virtual machine that can be hosted on facilities ranging from our laptop to a datacenter in the cloud. It's thus possible to create a virtualized development environment that contains all the tools, applications, and libraries that a programmer requires. This speeds up developer setup time, brings economies of scale, introduces parity between development and production environments, allows the use of platform-specific tools, and simplifies embedded-system development. Using VMs, testers can ensure a pristine environment and access to diverse (virtual) platforms. Deployment is also simplified by packaging all the system's components and setup into a VM appliance. Finally, on the operations side, VMs make it easier for a system to support application provisioning, maintenance windows, high availability, and disaster recovery. [ABSTRACT FROM PUBLISHER]

The article focuses on the history of inspection practices in software engineering and its wide dissemination in various industries. It was stated that software inspections, which was adopted by the U.S. National Aeronautics and Space Administration (NASA) since late 1980s and early 1990s, was considered one of the best example of evidence-based innovation-diffusion. According to the authors, inspections are among the most mature and best-studied practices in software engineering. It is also conceived as a powerful tool for finding problems in systems. However, the authors believe that relying on inspection process has disadvantages.

Phillip G. Armour responds to "Differential Debugging" in the Tools of the Trade column September/October issue of IEEE Software to discuss the process of predicting defects. [ABSTRACT FROM PUBLISHER]

The article offers several suggestions related to sytems software development to avoid its failure. Topics discussed include writing a vitally required piece of systems software by an applications programmer, testing systems software to check the compatibility of the software and debugging systems software.

The article presents a series of hypothetical book reviews, noting that the subjects for the nonexistent books address computer software-related topics the author believes are in need of exploration. Book topics mentioned in the article include an examination of the code of large open-source software applications as it relates to a reference architecture, an introduction to the design and characteristics of virtual machines (VMs), and an introduction to debugging programs which inspect and control other pieces of software.

The article focuses on testing classification systems. It states that testing is the most important phase in software development and influences product reliability to the greatest degree. It comments on the book "Building Quality Software," published in 1992, concerning testing approaches and how they are still valid 17 years later. It explains concepts such as structure-driven testing, statistics-driven testing, and risk-driven testing. It states that three quarters of errors in software are a result of missing logic or software structure problems.

The article offers information on design repair valuation and how to manage antipatterns or often used ineffective solutions in computer software development. It discusses various antipatterns, such as Frankenstein, Rocky Road, and Lava Flow. The author suggests that taking informed diagnosis before fixing antipatterns and other problems in software design involves several individuals assessing any programming, reporting, and data dependencies. She indicates that better planning and proper execution of necessary repairs are important in preventing certain antipatterns.

The article discusses debugging strategies, techniques, and issues involving logging codes. The most effective debugging procedure is by searching for the symptom and then looking for the cause of the problem. In Microsoft Windows, a debugger is launched right after a program crashes. Application that are considered to be complicated to debug are games, operating systems, as well as embedded systems. The program code where the instructions in generating logging and debugging messages appear, shows the behavior of a program without having to use a debugger.

Cloud computing is a new paradigm for software systems where applications are divided into sets of composite services hosted on leased, highly distributed platforms. There are many new software engineering challenges in building effective cloud-based software applications. This special issue provides a set of practical contributions to the engineering of cloud computing applications and includes software processes, architecture and design approaches, testing, scalability engineering, security engineering, and applications of highly parallel cloud-based systems. [ABSTRACT FROM PUBLISHER]

The increasing pervasiveness of cloud computing is changing the state of the practice in software testing. In an interview with James Whittaker, an engineering director at Google, editor in chief Forrest Shull explores some of the important trends in cloud computing and their implications. The conversation covers key technology changes, such as more pervasive access to monitoring frameworks, the ability to aggregate and act on feedback directly from massive user communities (the "crowdsourcing" of quality assurance), and the ability to know the exact machine configuration when bugs are discovered. All of these changes are having concrete impacts on which skills are important—and which no longer so—for software testers. An accompanying audio interview provides a complete recording of the conversation and more details on points such as privacy testing. [ABSTRACT FROM PUBLISHER]

STAREAST 2012 Advertisement [ABSTRACT FROM PUBLISHER]

Model-based testing (MBT) strives to automatically and systematically generate test cases. In this column, Ina Schieferdecker introduces MBT technologies and methods. [ABSTRACT FROM PUBLISHER]

A list of terms related to software development is presented. Some of the terms are coupling, abstraction, detailed design, class, design, architecture, encapsulation, bottom-up design, error processing, exception handling, and global data. A class is defined as a static programming entity in an object-oriented program that contains a combination of functionality and data. Class is a design and code-time concept but is often used interchangeably with object. A bottom-up design is a design approach in which low-level pieces of a system are combined into an overall design. Construction is defined as an activity in software development consisting of detailed design, coding, unit testing, and debugging. It is also known as programming or development. A function is defined as a routine that returns a value; in C language. Architecture is defined as the organizational structure of a system and its implementation guidelines; sometimes refers to the design of a system's hardware and software components. It is similar to high-level design. A defensive programming is defined as a general approach to programming that assumes that errors will occur during both initial development and maintenance and, as a result, creates code in such a way that the program still operates properly when errors occur.