The Latest
If at First, and Last, You Don't Succeed ...[magazine] Sometimes, no matter how talented you are and how hard you work, you will not be able to succeed, at least within the constraints you are handed. If your boss says you have to achieve project goals with the resources you have, what can you do? Esther Derby suggests: 1) Start by assuming that a reasonable approach will get reasonable results; 2) If your boss isn't willing or able to hear what you have to say, decide what you are willing to do; and 3) Consider what you might do differently next time. |
||
Project Archaeology[magazine] This article aims to show you the rich variety of information that can be used to help you build a good model of the system you are involved with. Some of the areas covered are: the business context; the language; the organizational structure; the culture; and cross-departmental relationships. |
Andy Schneider
October 17, 2002 |
|
|
Bypassing the GUI[magazine] Graphical User Interfaces make test automation hard. The problems are well known. You need specialized tools to drive the GUI. Those tools can be confused by the common programming practice of inventing custom user interface controls. When they are used in the simplest way, the tools lead to fragile tests that tend to break en masse when the GUI changes. Making the test resistant to change requires elaborate and sometimes awkward testing frameworks. Learn how to use a scripting interface to get around the GUI problem. |
Brian Marick
October 17, 2002 |
![]() |
Delivering Unwelcome News to Developers[magazine] How well you present a defect to a developer can impact when a defect is resolved–or whether it is resolved at all. Deliver the information abruptly or inappropriately, and you run the risk of alienating a person or creating project hot spots that aren't needed. Deliver news too passively, and your report may be discarded. Karen Johnson describes some ways to soften the blow so that your defects are not only acknowledged, but fixed. |
|
![]() |
A Picture's Worth a Thousand Words[magazine] Maps are a universal way of describing an area. You use them to plan your route and find your destination. Just as it's a good idea to have a map when traveling, it's a good idea to have a picture of the software you're testing. Elisabeth Hendrickson describes UML, parts maps, flow charts, state diagrams, and more. |
|
![]() |
A Measured Response[magazine] An infinite number of metrics can be applied to various aspects of software development. In fifteen years of managing software development, Mike Cohn has found a handful of metrics that really help him do his job--and keep him cool and confident when the heat is on. Here, he describes product stabilization metrics, programmer quality metrics, customer satisfaction metrics, and complexity metrics. |
|
Not Getting What You Want?[article] The project plan is clear and the specifications are detailed. So why is the final product so different from what you expected? In this week's column, Nicole Auger brings a product manager's perspective on how features get changed or added during the development process. And she gives tips on how to get what you ordered, instead of a substitute. |
||
What To Do When What You're Doing Isn't Working[article] If at first you don't succeed, try, try again. But if you keep trying the same things that worked for you in the past, and they're not working for you now, you might never succeed. In this column, Eileen Strider shows you how to tap new sources for fresh approaches to tackling problems. |
Eileen Strider
September 26, 2002 |
|
Automation Opportunities: Finding the Sweet Spot in Your Project[presentation] In any test automation effort, there are "sweet spots," points of leverage where you get more for your automation efforts. |
![]() |
|
XP: That Dog Don't Hunt[article] Books, Web sites, conferences, and "experts" in Extreme Programming abound these days. The latest StickyMinds RoundTable is devoted to the subject. Agile methods have their critics as well. Read this week's column by Bill Walton for some of his objections to the latest approaches, and see if you agree. |
Bill Walton
September 19, 2002 |
|
Seven Steps to Test Automation Success[presentation] Test automation raises our hopes yet often frustrates and disappoints us. Although automation promises to deliver us from a tough situation, automating implemented tests can create as many problems as it solves. |
Bret Pettichord, Tivoli Systems
|
|
Why Software Fails (And How Testers Can Exploit It)[presentation] Testers know all too well that software fails. If we can understand the fundamental reasons why this happens, we can become more efficient and effective at finding bugs. |
![]() |
|
The Influential Test Manager[presentation] Many of us have worked in test groups where we felt as if we didn't have enough time, staff, or computer resources to do the work. We may not even know precisely what we need to test. |
![]() |
|
Senior Management Asks: Will We Ever Finish Testing?[presentation] Based on his testing experiences, Mike Lee illustrates through practical examples the steps taken to dramatically raise the probability of a successful test improvement implementation. |
Mike Lee, CPT Consulting
|
|
Using the ICED T Model to Test Subjective Software Qualities[presentation] Since the subjective aspects of software quality do not lend themselves to being put into numbers or graphs, they are often overlooked. |
Andy Roth, Rational Software
|