|
Testing with Styles Walt Disney is famous for characters like Mickey Mouse and Donald Duck, but there were three special characters he used as thinking tools. No, not Huey, Duey, and Louie, Donald's nephews, but three special character styles. These styles are dreamer, realist, and spoiler. Often Walt participated in meetings having adopted one of these styles. We can also use these styles to guide software development, reviews and testing, user-system interactions, and system-to-system interactions. For testers, the dreamer suggests positive testing to ensure the product works, the realist suggests negative testing in case the user makes mistakes, and the spoiler suggests illogical user actions or destructive testing to focus on unusual or malicious system use.
|
Erik Petersen, Emprove
|
|
STARWEST 2005: Testing Dialogues - Technical Issues Is there an important technical test issue bothering you? Or, as a test engineer, are you looking for some career advice? If so, join experienced facilitators Esther Derby and Elisabeth Hendrickson for "Testing Dialogues-Technical Issues." Practice the power of group problem solving and develop novel approaches to solving your big problem. This double-track session takes on technical issues, such as automation challenges, model-based testing, testing immature technologies, open source test tools, testing web services, and career development. You name it! Share your expertise and experiences, learn from the challenges and successes of others, and generate new topics in real-time. Discussions are structured in a framework so that participants receive a summary of their work product after the conference.
|
Esther Derby, Esther Derby Associates Inc
|
|
The Venerable Triangle Redux Jerry Weinberg's venerable triangle problem has been around since 1966 and was popularized in Glenford Myers' book The Art of Software Testing. To assess a tester's effectiveness, many software companies have used the triangle problem as an interview question. But, past studies indicate testers' effectiveness at solving the problem is relatively low. Recent studies by noted experts indicate that a significant number of testers in the industry lack formal training in software testing techniques. Over a three-year period Microsoft conducted several experiments to accurately quantify the effectiveness of testers with different years of experience and skill.
|
William Rollison, Microsoft Corporation
|
|
Risk: The Testers Favorite Four Letter Word Identifying risk is important-but managing risk is vital. Good project managers speak the language of risk, and their understanding of risk guides important decisions. Testers can contribute to an organization's decision making ability by speaking that same language. Learn from Julie Gardiner how to evaluate risk in both quantitative and qualitative ways. Julie will discuss how to deal with some of the misconceptions managers have about risk-based testing including: Testing is always risk-based. Risk-based testing is nothing more than prioritizing tests. Risk-based testing is a one-time-only activity. Risk-based testing is a waste of time. And risk-based testing will delay the project.
|
Julie Gardiner, QST Consultants Ltd.
|
|
Building a Configuration Management (CM) Capability for Test
As more test items exist, there is a tendency for them to evolve due to the changes to requirements and code and, therefore, must be managed effectively. When there are an increasing number of test items, this increases the risk of failing to accurately track all test items, particularly when this is done manually. This is where configuration management (CM) can help.
|
|
|
More Than One Answer; More Than One Question Connect with an expert to learn how to work smarter and discover new ways to uncover more defects. In this issue, Michael Bolton continues his discussion of James Bach's Heuristic Test Strategy Model by focusing on the importance of customer-facing quality criteria.
|
|
|
Agile Process Improvement and the Evolution toward Software Factories The concept of software factories is becoming a hot topic in software engineering circles. So, how can the factory model fit with Agile development practices? Damon Carr makes the case that Agile development is a stepping stone-not an alternative-to software factories. This is not the dreary vision of mindless workers in a factory. Instead, think of highly skilled individuals working with multi-million dollar machinery to develop systems. Even if you are not considering the factory model, Damon offers new practices that can reduce overall Agile development costs by as much as 40 percent. These include explicit refactoring to design patterns in your iterations, quantitative risk management, metrics for understanding the health of your project, and a new approach to team structure.
|
Damon Carr, AGILEFACTOR
|
|
Better Software Conference 2005: Software Production Line Automation with Concurrent Development In some contexts, the software development process can be optimized when it is thought of-and run-like a highly automated manufacturing production line. Rather than producing many identical widgets like a manufacturing plant, software organizations produce many programming changes. These changes may not be identical like manufactured widgets, but programming changes can start looking a lot like widgets when you look at the big picture. In this session, Tom Tyler describes how to bring the processes and benefits normally associated with manufacturing to software development-efficiency, reliability, and extensive automation. Manufacturing organizations invest heavily in tooling and infrastructure to automate production lines, and they reap great rewards in efficiency.
|
C Thomas Tyler, The Go To Group Inc
|
|
Elemental Models Connect with an expert to learn how to work smarter and discover new ways to uncover more defects. In this issue, Michael Bolton continues his discussion of James Bach's Heuristic Test Strategy Model by introducing the Product Elements perspective on test coverage.
|
|
|
Reduce Stress, Write a Test All code is not created equal. Learn from a master of the craft how to spot bad code and mold it into good. This month, Mike Clark explains how writing automated tests can give you confidence to change code fearlessly.
|
|