No More Second-Class Testers! First-class testers do more than find and report defects; they supply information about the product to the entire organization. The more information your testers provide to the developers, the requirements people, the writers, and anyone else involved in product development, the more valuable they are. (Jan. 2004 Better Software)

Cem Kaner on Scenario Testing The ideal scenario test has five key characteristics. It is a a story that is motivating, credible, complex, easy to evaluate and powerful. It not only could happen in the real world, stakeholders believe that something like it probably would happen. (Sep. 2003 Software Testing & Quality Assurance)

Testing Error Code Software should either appropriately respond to bad input or it should successfully prevent the input from ever getting to the software in the first place. Of pure nuisance value are uninformative error messages. They are sloppy and will cast doubt in a user’s mind on the credibility of the software producer. (Aug. 2003 StickyMinds)

Orchestrating Integration Testing Verifying the operation of a complex software system can be a daunting task. One helpful approach is to take an "algebraic view" of the task. Using this approach, you first categorize the design and operation of the integrated system as a complex equation, built from interdependent variables. (Jul. 2003 StickyMinds)

Building a better bug-trap Tracking down bugs the old-fashioned way — writing a piece of code, running it on a computer, seeing if it does what you want, then fixing any problems that arise — becomes less and less effective. Tools which look into programmers' code as they work could help a team work more effectively. (Jun. 2003 The Economist)

Test-Physicians, Source Code, and BSODs Oh so many times I hear testers whine about release dates. Quality is important but market pressures, competition, strength of user demand, staffing and personnel issues and many more nontesting issues must determine a suitable release date. (Jun. 2003 StickyMinds)

Who’s Testing Your Software? Software customers and investors beware. You need to look harder at the process of software development. Organizations, in a move to save cash, have scaled back testing beyond the point of acceptable risk. (Jun. 2003 StickyMinds)

Oracles, Failures, Models, and Sins Development work is hard, very hard. Developers over the past few decades have had to solve the same problems over and over again and often make the same mistakes over and over again. We testers must remember those mistakes and design tests that ensure that lessons are being learned. (May 2003 StickyMinds)

Improve Tester Performance Assign your testers to only one project or project area for an entire release. Tell the developers for that project that one of their project deliverables is to educate the tester about the product internals. Then give the tester a book about testing or test techniques and let the tester loose. (May 2003 StickyMinds)

Random Testing and "App Compat" Application compatibility means that one application does something to break another one. A user should not have to tell you that your application won’t run with a specific service pack installed; that is something you should find out in your own testing. (Apr. 2003 StickyMinds)

Clarify Your Ranking for System Problem Reports Here’s a puzzle: If one defect has a severity rating of 3 and a priority rating of 2, and another defect has a severity rating of 2 and a priority rating of 3, which one do you fix first? (Mar. 203 StickyMinds)

Test Organization Strategies: Centralized, Distributed, or Hybrid? For large companies with multiple applications or even multiple lines of business, what is the best model for the test organization? Centralized test groups comprise a pool of resources that are shared across applications and projects, and distributed test teams are aligned by application or line of business. Which is best? (Mar. 2003 StickyMinds)

Will the Real Professional Testers Please Step Forward? Begin by hiring college graduates who have majored in something technical and related to computer science. You cannot expect upper management to take you seriously until you take yourselves and your discipline seriously. (Feb. 2003 StickyMinds)

Why won't it work? Software quality always seems to boil down to complexity and testing. Consider a test plan for a simple program that reads three integer values from a card representing the lengths of the sides of a triangle. The program states whether the triangle is scalene, isosceles, or equilateral. How many test cases can you come up with? Binder came up with 65. (Feb. 2003 Application Development Trends)

Mind of a software tester Software testing is a mindset. Testers must take a critical view of software. Defining tests before writing code helps to build testability into the software and often creates more bulletproof code. (Jan. 2003 Application Development Trends)

A Blueprint for Success A system architecture review process can represent a major change in the development culture — but the payoff is enormous, and early, independent, and impartial validation of software architecture is one of the most important quality control activities a software company can do. (Jul. 2002 Software Testing & Quality Engineering)

Software bugs cost $59.5 billion a year, study says The U.S. Department of Commerce National Institute of Standards and Technology says more than half the costs are borne by software users and the remainder by software developers and vendors. Factors contributing to quality problems include marketing strategies, limited liability by software vendors, and decreasing returns on testing and debugging. (Jun. 2002 Infoworld)

Institutionalizing Poor Quality We should expect developers to build-in quality just as we expect airplane engineers to build-in quality -- with testers/inspectors only there to verify quality. It’s time to put the first responsibility for a high-quality product back where it belongs -- in development, with developers. (Apr. 2002 StickyMinds)

What Does It Cost to Fix a Defect? One of the least understood factors is the actual cost of fixing a defect. This cost feeds back into your choice of development lifecycle and development process and can help you decide how much risk you’re willing to take to ship or not ship the product. (Feb. 2002 StickyMinds)

Learning to Love Unit Testing There’s no denying it. It is very, very difficult to add unit tests to a big-wad-o’-legacy code. The code probably isn’t structured to make testing easy. Even if it is, there’s a tremendous overhead in getting the tests in place. (Jan. 2002 Software Testing & Quality Engineering)

James Bach on Explaining Testing to Them Maybe you think your co-workers should already understand how testing works. I feel your pain. Now, get over it. You are the testing specialist. You like this stuff. Because you’re good at it, the other project roles can focus better on what they do well. (Dec. 2001 Software testing and Quality Engineering)

Five Ways to Think about Black Box Testing An easy way to start up a debate in a software testing forum is to ask the difference between black box and white box testing. These terms are commonly used, yet everyone seems to have a different idea of what they mean. Q. What is “gray box” testing? (Nov. 2001 StickyMinds)

The Problem Isn’t Always THE Problem At one company, I thought that The Problem was a lack of unit tests. Then I attended a meeting in which we were discussing bugs in a particular area of the code. The developer already knew about the bugs. He also knew he wouldn't get time to fix the bugs until the test group found the bugs themselves. (Sept. 2001 StickyMinds)

The Science of Catching Hidden Bugs Let’s take an example. If you were testing software that produces random numbers, how could you verify that the numbers are truly random? The facile answer is that you gather a large sample of generated numbers and analyze it both for the distribution of the numbers and for patterns. I thought that answer was sufficient until I began experimenting. (July 2001 StickyMinds)

The Secret to Software SuccessIn 1967 a pioneering software testing company published a paper outlining some best practices for the new field of software engineering. It featured instructions on how to test code, assign a manager to own a project and kill projects that were going nowhere. That's right. The accepted wisdom for managing software development hasn't changed in almost 35 years. And what has the accepted wisdom achieved? Not much. (July 2001 CIO)

Across the Great Divide Some people are genetically predisposed to be developers. And some are likewise predisposed to testing. The relationship between testers and developers, just like any other emotionally charged relationship, is fraught with misunderstanding and lack of communication. Many of our timeworn feudal difficulties can be alleviated by some attention to the language that we use. (June 2001 StickyMinds)

What’s So Great About Inspections?!? Research study after research study shows that inspections are a better, faster, cheaper way of finding errors in a software product than any of the alternatives. Used properly, more than 90 percent of the errors can be removed from a software product before its first test case is run. You may find it painful in the short term, but the long-term payoff is worth it. (June 2001 StickyMinds)

Value Lattice Static Analysis In testing, we tend to focus on the paths that will most likely execute under normal conditions. The problem with this approach is that many of the most devastating bugs we encounter can occur on infrequently executed paths. These are the bugs that can bring a system down. (Mar. 2001 Dr Dobbs Journal)

The Flaw of Averages The Flaw of Averages states that: Plans based on the assumption that average conditions will occur are wrong on average. A computerized cure for the Flaw of Averages is Monte Carlo Simulation. It generates thousands of scenarios covering all conceivable real world contingencies in proportion to their likelihood. (Oct. 2000 Dr Dobb's Journal)