As software technologies continue to grow in power and complexity and microprocessors continue to shrink, we are witnessing the rapid expansion of software into virtually all areas of our business and private lives. Today, it is found in cars, traffic lights, household appliances, communications and transportation systems, hospitals, airplanes, medical devices, next-generation payment cards, business supply chains, and enterprise management systems. Software is truly becoming ubiquitous. This article illustrates the consequences of software failure, the dynamic process of risk analysis, and the importance of the right business decision.
Bugs that make a system crash are the most dramatic, but they may not be the most interesting. Subtle bugs hide where you don't expect them, causing systems to mislead users with incorrect results. Using scientific inquiry, you can expose these deceptive ne'er-do-wells lurking inconspicuously under the covers. Elisabeth Hendrickson offers good examples and pointers to using this investigative method.
The rapid development of applications nowadays does not always leave a project time to perform lengthy assessment of requirements and time to test; as in most cases, time is of the essence. Identifying a simple process for gathering and assessing Requirements makes the testing of applications easier and lessens the risk of delivering inadequately tested software. This paper provides the steps necessary to implement the process.
Can measurement be the system development savior of the 21st century, or is it a passing fad? The truth lies somewhere in between. The secrets of highly successful measurement programs extend well beyond the technical correctness of the chosen metrics and collecting of data. This article explores these secrets and identifies characteristics critical to measurement program success. The secrets of highly successful measurement programs extend well beyond the technical correctness of the chosen metrics and collecting of data. This article explores these secrets and identifies characteristics critical to measurement program success.
Most of the Test Managers say, "Testing without test plans is a crime." The testers should know what is being built and should analyze the way to proceed. He/she will have to prepare the test plans based upon that to proceed with testing the application. Good knowledge of Exploratory Testing is necessary for reading this article. For those who don't have much idea about Exploratory Testing, a small intro is given here.
This paper presents data on the effectiveness of software fault insertion, discusses the advantages and risks of fault insertion, provides tips on gaining cultural acceptance for fault insertion and suggests high payback areas for fault insertion which have proven themselves over multiple products. In a typical software development cycle, defect detection starts to trail off once the mainline code stabilizes. With software fault insertion, it was found that the defect detection rate does not level off and the hardest task becomes not one of finding defects but one of prioritizing the stream of defects.
Have you ever run an installation program that wreaked more havoc than the installed application was worth? We often talk about user headaches from faulty software, but sometimes the pain begins with the installation process itself. Just for fun, here's a humorist's fictional account of a nightmare installation he (barely) endured.
Some testers take it upon themselves to learn as much as possible about the inner workings of the system under test. This type of "gray box" testing is valuable, and most testers have the technical wherewithal to grasp much of what's going on behind the scenes. But it's important to recognize that sometimes "ignorance is strength" when it comes to finding problems that users will encounter.
There is a dichotomy between the development and testing of software, signified by the abundance of software development models and the dearth of test development models. Software testing's ephemeral nature aggravates the issue, as does the software developer's view of testing - represented only by a deadline, not a process.
This paper presents a new model for software test development. The butterfly model is then correlated with the ubiquitous V development model to establish context.
Many bemoan the strained relationship between testers and developers. But while we can't force testers and developers to see eye to eye on everything, we can reduce some of the tension by making simple changes in the way we communicate. Learn some great tips and tricks in this article.