STAREAST 2008 - Software Testing Conference

As systems become more complex--serving the enterprise and implemented on the Web and across the Internet-performance testing is becoming more important and more difficult. David Chadwick suggests that the starting point is to design tests that reflect real user activity, including independent arrivals of transactions and varying input data to prevent "cache only" results. David explains how to break down the end-to-end system response time into the distributed components involved in processing the transactions.

Test managers often choose solutions to problems without sufficient analysis, resulting in a cover-up of the symptom rather than a solution to the underlying problem. Later, the problem may surface again in a different disguise, and we may mishandle it again, just as we did initially. Alon Linetzki describes a simple process you can use to identify the root causes of problems and create an appropriate solution to eliminate them.

What do you say when your manager asks you, "How did it go today?" If you have a pile of test cases on your desk, it may be acceptable for you to say, "I ran x% of these tests today," or "I'll be finished with this stack in y days at the rate I'm going." However, if you're using exploratory testing as your approach, it may be downright terrifying to try to give a status report, especially if project stakeholders think exploratory testing is irresponsible and downright reckless compared to pre-scripted test cases.

Test coverage of application functionality is often poorly understood and always hard to measure. If they do it at all, many testers express coverage in terms of numbers, as a percentage or proportion-but a percentage of what? When we test, we develop two parallel stories. The "product story" is what we know and can infer about the product-important information about how it works and how it might fail.