LogiGear - Software Testing and Quality AssuranceCommon Software Errors - Initial and Later StatesInitial and Later StatesBefore you can use a function, the program may have to initialize it. Typical initialization steps include identifying the function's variables, defining their types, allocating memory for them, and setting them to default values (such as 0). The program may have to read a disk file that contains defaults and other configuration information. What happens when the file is not there? Initialization steps might be done when the program is loaded (data defaults can be loaded into memory along with the program), when it is started, when the function is first called, or each time the function is called. Initialization needs and strategy vary widely across languages. For example:
Initialization failures usually show up the first time the function is called or the second time, if it doesn't reinitialize variables correctly. Reinitialization failures may be path-dependent. If you reach a function in a "normal" way, it works fine. However, if you take an "abnormal" route, the program might branch into the function at some point after the initialization code. Programmers often treat backing up to modify data or redo calculations as abnormal. Click here - Initial and Later States - to continue... |
Common Software Errors - Calculation ErrorsThis is the appendix from the best-selling book Testing Computer Software, 2nd ed.Copyright © 1988 by Cem Kaner Copyright © 1993 by Cem Kaner, Jack Falk, Hung Quoc Nguyen This is part 5 of 13. CALCULATION ERRORS The program calculates a number and gets the wrong result. This can happen for one of three types of reasons:
This area is huge and this section only begins to scratch its surface. For an introduction to the larger area, read Conte and deBoor (1980) and Knuth (1981). For a second source on topics in Conte and deBoor, try Carnahan, Luther & Wilkes (1969). |
Common Software Errors - Boundary-Related ErrorsThis is the appendix from the best-selling book Testing Computer Software, 2nd ed.Copyright © 1988 by Cem Kaner Copyright © 1993 by Cem Kaner, Jack Falk, Hung Quoc Nguyen This is part 4 of 13. BOUNDARY-RELATED ERRORS A boundary describes a change-point for a program. The program is supposed to work one way for anything on one side of the boundary. It does something different for anything on the other side. The classic "things" on opposite sides of boundaries are data values. There are three standard boundary bugs:
We treat the concept of boundaries more broadly. Boundaries describe a way of thinking about a program and its behavior around its limits. There are many types of limits: largest, oldest, latest, longest, most recent, first time, etc. The same types of bugs can happen with any of them so why not think of them in the same terms? |
Common Software Errors - Error HandlingThis is the appendix from the best-selling book Testing Computer Software, 2nd ed.Copyright © 1988 by Cem Kaner Copyright © 1993 by Cem Kaner, Jack Falk, Hung Quoc Nguyen This is part 3 of 13. ERROR HANDLING Errors in dealing with errors are among the most common bugs. Error handling errors include failure to anticipate the possibility of errors and protect against them, failure to notice error conditions, and failure to deal with detected errors in a reasonable way. Note that error messages were discussed above. |
Common Software Errors - User Interface ErrorsThis is the appendix from the best-selling book Testing Computer Software, 2nd ed.Copyright © 1988 by Cem Kaner Copyright © 1993 by Cem Kaner, Jack Falk, Hung Quoc Nguyen This is part 2 of 13. The user interface (UI) includes all aspects of the product that involve the user. The UI designer tries to strike a balance between
In seeking a good balance, the designer weighs the experience and needs of the people she expects to use the program against the capabilities of the equipment and available software technology. An error in the UI results in a suboptimal match between the user and the program. Because tradeoffs are unavoidable in UI design, a good designer might deliberately make any of many of the "errors" listed below. Don't take this list as gospel. If you are at all unsure, listen to the designer's reasoning before condemning one of her choices. See Baecker & Buxton (1987), Helander (1991), Laurel (1990, 1991), Rubenstein & Hersh, (1984), Schneiderman (1987), and Smith and Mosier (1984) for excellent introductions to user interface design, including extended discussion of many of the issues raised in this Appendix. Throughout this Appendix we write as if you were the user of the program. As a tester of it, you will certainly use it heavily. Realize that other people will also use the program and they will have different problems from you. Try to be empathetic. |
Common Software ErrorsThis is the appendix from the best-selling book Testing Computer Software, 2nd ed.Copyright © 1988 by Cem Kaner Copyright © 1993 by Cem Kaner, Jack Falk, Hung Quoc Nguyen This is part 1 of 13. This Appendix describes over 400 bugs. The descriptions are short, including only what we considered the most interesting information. It's worthwhile reading this list, even though you may find it boring. On first reading it provides a frame of reference, details, and background about problems you should look for while testing. Its greater value is as an organized list of program problems for future reference. A good list, built up with time and experience, can be a powerful tool. |
Load/Performance Test Plan TemplateComprehensive template to help develop a Load/Performance Test Plan. |
How to Measure Testing SuccessBy Rob PirozziIntroduction All to often, senior management judges software testing though the lens of potential cost savings. Test automation and outsourcing are simplistically looked at as simply methods to reduce the costs of software testing. But the sad truth is that simply automating or offshoring a poor software testing effort will simply yield an automated and offshore poor testing effort. And if the same simplistic approach was taken in the planning of automation and offshoring, the costs may not even be lower. It is critically important for management to define "success" for their software testing efforts. While cost is one metric, it is not the sole metric. Other issues that should also be taken into account include:
Using these criteria, management should come up with a clear definition of success that is consistent with their testing strategy and testing methodology. Of course, if there is no strategy and methodology, then that must be developed first - but that is a topic for another article This paper will discuss the importance of these other non-cost success criteria. |
Is Test Automation the Same as Programming Tests?By Hans BuwaldaIntroduction A common issue that I come across in projects is the relationship between test automation and programming. In this article I want to highlight some of the differences that I feel exist between the two. After many decades of often slow and hard fought over progress, software engineering is now a well established profession, with recognized methods and practices. Automated testing, however, is still a relatively new and often misunderstood phenomenon. Often software engineers get involved in software testing and try to apply their programming knowledge and experience. For many aspects of software testing this is a good thing, but over the years I have come to believe that automated testing poses its own distinct properties and challenges, and a practitioner should try to understand those and work with them. This article will explore the differences between software engineering and designing automated tests. |
Software Testing 3.0: Organization and Process RamificationsBy Rob PirozziIntroduction Many companies have come to realize that software testing is much more than a task that happens at the end of a software development cycle. They have come to understand that software testing is a strategic imperative and a discipline that can have a substantial impact on the success of an organization that develops software. Many of these companies are coming to embrace the ideas that are central to the latest phase in the evolution of software testing, Software Testing 3.0 (See the links below for more on Software Testing 3.0). Implementing Software Testing 3.0 is a major undertaking, and as such, should not be embarked upon without adequate planning. While implementing Software Testing 3.0 will require substantial effort, the benefits in terms of software quality, cost and time savings, and mitigation of risk from in market failures are substantial. Software Testing 3.0 has both organizational and process ramifications. These ramifications need to be fully understood to insure success implementing Software Testing 3.0. This paper will explore these organizational and process ramifications to help with an organization's planning efforts. |
Software Testing 3.0: The Continuing Evolution of Software TestingThis white paper traces the evolution of software testing through its first two phases, and then presents the current state-of-the practice: Software Testing 3.0, an independent and strategic approach to software quality. The paper concludes with a discussion for senior executives on how and why software testing can finally meet and exceed management expectations, illustrated by real-world case studies showing how two companies benefited from Software Testing 3.0 to test better and faster while lowering their costs. |
Classic Article - DAST - Diagnostic Approach to Software TestingBy Hung Q. Nguyen and Michael Hackett
Other classic articles... |
Applied Gray-Box Testing for Web ApplicationsBy Hung Q. NguyenToday's Agenda Applied Gray-box Testing
This is a web adaptation of a presentation given by LogiGear founder and CEO Hung Q. Nguyen for a RADVIEW Webinar |
Is Action Based Testing an Automation Technique?By Hans BuwaldaIntroduction Keyword driven methodologies like Action Based Testing (ABT) are usually considered to be an automation technique. They are commonly positioned as an advanced and practical alternative to other techniques like to "record & playback" or "scripting". You can read a lot about ABT on the LogiGear web site or in LogiGear's Newsletter Archives. To see ABT as an automation technique is not incorrect. We do it ourselves at LogiGear in marketing. Some parts of ABT, and the supporting toolset TestArchitect, are very technical and would not fit in a manual process. However, in this article I want to show that the core ideas of ABT are not specifically about automation at all, they are merely a style of test design. |
Classic Article: Development and Delivery of a Successful Commercial Web-based ApplicationBy Hung Q. NguyenWeb Applications -- A Few Differences
|
LogiGear Spring Software Testing Training Schedule
All classes are held at LogiGear's Foster City, California location. |
Should Automated Acceptance Tests Use the GUI the Application ProvidesBy Michael BoltonIntroduction As a consultant and trainer, I am often asked by my clients and students how to deal with automated acceptance tests. One common question is whether automated acceptance tests should use the graphical user interface (GUI) provided by the application.. Click to continue... |
How to Identify the Usual Performance SuspectsWhen You're Out to Fix Bottlenecks, Be Sure You're Able to Distinguish Them From System Failures and Slow SpotsBy Scott Barber Bottlenecks are likely to be lurking in your application. Here's how you as a performance tester can find them. So you found an odd pattern in your scatter chart that appears to be a bottleneck. What do you do now? How do you gather enough information to refute the inevitable response, "The application is fine, your tool/test is wrong"? And how do you present that information conclusively up front so you can get right down to working collaboratively with the development team to solve the problem? Through years of experience as a performance testing consultant, I've learned something very important. It's not safe to assume that most people really know what a bottleneck is - even if you've been doing performance testing for a long time and use the term "bottleneck" in everyday speech - particularly when it is contrasted with a system failure or a slow spot. To provide a teaching tool, I coined "Scott's Eight Basic Rules for Software Bottlenecks," which I'll share with you below. Click to continue... |
LogiGear's Hans Buwalda to Present Keyword Test Automation Session at STARWEST
|
Classic Article: Getting Automated Testing Under Control
During the years we have evolved an approach to counter these issues. Although you shouldn't regard it as a "silver bullet," we think it can be very practical; we would like to use this article to share it with you. The approach is marketed under the name TestFrame but you can easily apply the techniques and principles outlined in this article yourself. |
LogiGear To Double Size of Vietnam Software Testing CenterFully Integrated US-Vietnam Operation Continues Rapid GrowthFoster City, CA - October 15, 2007 - LogiGear Corporation today announced the acquisition of additional facilities in Vietnam to support rapid growth of the LogiGear Test & Research Center, doubling the capacity of the company’s operations there. The first and only US-led software testing center in Vietnam, LTRC will employ 500 test and software engineers and other personnel by the end of 2008, with more growth planned for the future. |
Key Success Factors for Keyword Driven TestingHans Buwalda, Chief Technology Officer, LogiGear CorporationIntroduction Keyword driven testing is a software testing technique that separates much of the programming work of test automation from the actual test design. This allows tests to be developed earlier and makes the tests easier to maintain. Some key concepts in keyword driven testing include:
|
Classic Presentation: The Roles of Software Testing & QA in Security TestingThe Roles of Software Testing & QA in Security TestingHung Q. Nguyen LogiGear, President and CEO Bob Johnson Independent, Security Consultant ASQ-SSQA Presentation, May 14, 2002 Subscribe to LogiGear's latest software testing articles here: http://feeds.feedburner.com/LogiGearArticles |
QA City - Linux Testing Resources
Subscribe to LogiGear's latest software testing articles here: http://feeds.feedburner.com/LogiGearArticles |
