The Latest
|
How to Find the Level of Quality Your Sponsor Wants[article] This paper's purpose is to help you recognize customer needs - whether stated or implied - and turn them into an effective software testing process. It explores requirements gathering techniques, test efficiency, communication skills, and persuasion tactics. |
Sue Bartlett
February 13, 2002 |
|
|
Testing Is a Phase, Quality Is an Approach[article] Some developers and managers might think that if they test their product thoroughly, that the Quality part of their project is covered. Nothing could be further from the truth. This paper provides a brief outline of a healthy approach to testing and its importance. |
Dave Lutzker
February 11, 2002 |
|
|
Categorizing Defects by Eliminating "Severity" and "Priority"[article] With all of the advancements in defect tracking systems within the past few years, companies are still using the same ambiguous, canned fields known as Severity and Priority to categorize their defects. Let's examine a better way to assign importance to a defect. |
Brian Beaver
February 8, 2002 |
|
|
What Does It Cost to Fix a Defect?[article] We all have different attitudes and policies toward finding and fixing defects. The choice about whether and when to fix defects depends upon many factors, one of the least understood being the actual cost of fixing a defect. In this column, testing expert Johanna Rothman shares a formula for calculating the system test cost to fix defects and how to factor that into the bigger picture of your project. |
||
|
Test Result Checking Patterns[article] Determining how a test case detects a product failure requires several test case design trade-offs. These trade-offs include the characteristics of test data used and when comparisons are done. This document addresses how result checking impacts test design. |
Keith Stobie
February 7, 2002 |
|
|
How to Preview User Satisfaction before Your Release[article] Why wait to discover how your users will react to your system when there are ways to measure such things during development? This column describes a simple tool to develop visibility into customer satisfaction. Learn how you can begin to manage expectations so that neither you nor the customer has an unpleasant surprise on release day. |
||
|
Good Money After Bad[article] Many software projects that suffer a lingering death should have been canceled much earlier. Although it is hard to pull the plug on a project with a weak business case, failing to do so does throw good money after bad. Karl Wiegers gives some tips on decision making that can help you avoid this outcome. Karl also shows how to use decision points to keep a good project moving along. |
||
|
The Importance of Data in Functional Testing[article] A system is programmed by its data. Functional testing can suffer if data is poor, and good data can help improve functional testing. Good test data can be structured to improve understanding and testability. Its contents, correctly chosen, can reduce maintenance effort and allow flexibility. Preparation of the data can help to focus the business where requirements are vague. |
James Lyndsay
January 29, 2002 |
|
|
The Arc of Quality[article] During a recent job interview, I had a "Eureka Moment" while describing how to best use a bug-tracking tool. The Arc of Quality is an easy measure of the effectiveness of your testing process. |
Nick Tulett
January 28, 2002 |
|
|
Improving Projects by Communicating What's Below the Surface[article] Technical people often feel uncomfortable sharing their personal feelings toward a project. But there are recognized levels of information beneath the surface of what we hear and see. Here, Eileen Strider explains that even without plumbing the depths of your co-workers' souls, you can conduct a little subsurface exploration to benefit the team and the project. |
Eileen Strider
January 28, 2002 |
|
|
Consistency, Correctness, and Craftsmanship[article] This essay discusses the importance of consistency when developing new software or making changes to existing software, and how developers need to balance the often conflicting concerns of consistency and correctness–that is, correctness as it relates to the conventions and personal preferences for *how* we build software vs. the need to create or maintain consistency within a project, product, or organization. This essay originally appeared as an installment of the developer.* column at developerdotstar.com. |
Daniel Read
January 28, 2002 |
|
|
Learning to Test Wirelessly[article] The beginning of my adventure in learning to test wirelessly was accepting the task of building a software test department in a Campbell start-up company. Setting up the test department infrastructure and instigating a review process for design and test documents happened in parallel with analyzing the wireless test requirements and doing the testing. Testing without the infrastructure already in place contributed to some of the process problems that we encountered. |
Geraldine Conley
January 24, 2002 |
|
|
Unit Testing Database Code[article] The problem is this: You have an SQL database, some stored procedures, and a layer of code sitting between your application and the database. How can you put tests in place to make sure your code really is reading and writing the right data from the database? |
Richard Dallaway
January 24, 2002 |
|
|
The Practical Organization of Automated Software Testing[article] The purpose of this paper is to take a practical approach to automated software testing and explain requirements for its success |
||
|
What Does Success Look Like?[article] How do you know when software is ready to release? This article discusses one piece of knowing when the software is ready to release—knowing what a successful release would look like. |
Pages
StickyMinds is a TechWell community.
Through conferences, training, consulting, and online resources, TechWell helps you develop and deliver great software every day.