|
|
Testing and the Flow of Value in Software Development High quality software should be measured by the value it delivers to customers, and high quality software process should be measured by the continual flow of customer value. Modern processes have taught us that managing flow is all about the constraints restricting that flow. Testing, rather than being thought of as a conduit in that flow, is often perceived as an obstacle. It doesn't help that most testers struggle to answer the questions that their managers ask: What has and hasn't been tested? What do we need to test next? Where do we need to shift resources? If it works in the lab, why isn’t it working on those production machines? Where do we need to fix the performance or security? The ability-or inability- to answer these questions can determine the success and budget of a test team as well as how it is valued by its organization.
|
Sam Guckenheimer, Microsoft
|
|
|
Code Coverage: Where Does it Fit? Many organizations use code coverage almost religiously in their testing. Just as many or more organizations do not use code coverage or have tried it and stopped. If you want to begin using code coverage for the first time or improve its value and usage within your team, come hear what Dale Brenneman has to share. Using real-life examples, Dale explains the value of code coverage analysis as part of a comprehensive test plan and the potential side effects when you do not use code coverage. Find out about the many levels of code coverage and ways to enhance the value of code coverage analysis with other analysis techniques. Take away a step-by-step approach for integrating code coverage analysis into your organization's test process and fitting it into your functional test automation program.
- The levels of module code coverage: entry, line, statement, branch, Boolean, cyclomatic path, all paths
|
Dale Brenneman, McCabe Software
|
|
|
STAREAST 2006: Apprenticeships: A Forgotten Concept in Testing The system of apprenticeship was first developed in the late Middle Ages. The uneducated and inexperienced were employed by a master craftsman in exchange for formal training in a particular craft. So why does apprenticeship seldom happen within software testing? Do we subconsciously believe that just about anyone can test software? Join Lloyd Roden and discover what apprenticeship training is and-even more importantly-what it is not. Learn how this practice can be easily adapted to suit software testing. Find out about the advantages and disadvantages of several apprenticeship models: Chief Tester, Hierarchical, Buddy, and Coterie. With personal experiences to share, Lloyd shows how projects will benefit immediately with the rebirth of the apprenticeship system in your test team.
- Four apprenticeship models that can apply to software testers
- Measures of the benefits and return on investment of apprenticeships
|
Lloyd Roden, Grove Consultants
|
|
|
STAREAST 2006: 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 Johanna Rothman 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.
|
Facilitated by Esther Derby and Johanna Rothman
|
|
|
Testing Windows Registry Entries Warning: Registry keys may be hazardous to your program's health! Registry key entries in Windows applications-visible or hidden-are often neglected by testers. A registry key entry is a program feature just like any other application function and as such needs to be validated. Michael Stahl describes why registry keys should be accorded special attention during testing and proposes a strategy for mitigating risks posed by incorrect registry key entries. He suggests a test strategy, as well as coding standards for input value and type validation, default values, regeneration, and naming rules. Michael demonstrates the use of correct and incorrect registry keys in common commercial applications.
|
Michael Stahl, Intel Corporation
|
|
|
Open SourceTest Automation Frameworks Open source software has come a long way in the past few years. However, for automated testing there still are not many ready-made solutions. Testers often must spend their time working on test cases rather than working on a test automation framework. Allen Hutchison describes the elements of an automated test framework and demonstrates a framework that you can quickly assemble from several open source software tools. He then explains how to put the pieces together with a scripting language such as Perl. Once you build the framework, you can improve and reuse it in future test projects. At the end of the presentation, Google will release the described framework as a new open source project that you can begin using immediately.
|
Allen Hutchison, Google
|
|
|
Test Driven Development - It's Not Just for Unit Testing Test-driven development (TDD) is a new approach for software construction in which developers write automated unit tests before writing the code. These automated tests are always rerun after any codes changes. Proponents assert that TDD delivers software that is easier to maintain and of higher quality than using traditional development approaches. Based on experiences gained from real-world projects employing TDD, Peter Zimmerer shares his view of TDD's advantages and disadvantages and how the TDD concept can be extended to all levels of testing. Learn how to use TDD practices that support preventive testing throughout development and result in new levels of cooperation between developers and testers. Take away practical approaches and hints for introducing and practicing test-driven development in your organization.
|
Peter Zimmerer, Siemens
|
|
|
Let's End the Defect Report-Fix-Check-Rework-Cycle Find out how teams transitioning to Agile practices must re-think their workflows and project metrics originally designed to handle many hundreds of defect reports that occur in typical testlast development cycles. Richard Leavitt discusses how a real-world implementation of key practices like early testing and continual integration-though not without bumps and bruises-lowered the number of open defect reports by an order of magnitude. These practices also can improve how the team communicates, reduce delays, and provide more direct measures of project status, feature progress, and release readiness.
|
Richard Leavitt, Rally Software Development
|
|
|
The Next Stop in Test Automation: Test Environment Setup To achieve the most effective test automation, you need to go beyond automated test case creation and implement automated environment setup. In tracking the testing time spent over several projects, the Clustering group Amit Mathur worked with found that more staff time was being spent on setup than on actual testing. He discusses and demonstrates the Environment Configuration System (ECS) his group developed to automatically set up test environments and trigger automated test execution. Find out how ECS has dramatically improved the ability to automate many more manual tests. ECS employs a scripting language (Perl) and libraries for environment setup and test cases. Based on interface specifications and dependency rules, ECS bundles environment setups and test cases for complex test scenarios. Learn how you can adapt the ECS approach for your applications and environment.
|
Amit Mathur, VERITAS Software Corporation
|
|
|
How Much Quality is Enough? Are you striving for more quality than you really need? How would you know? "Good enough" quality does not mean "substandard" or "mediocre" but is actually an optimal and responsible economic principle we use everyday. Managing test lead for Quardev Laboratories, Jon Bach says because quality is expensive, the "good enough" framework provides the criteria to enhance decision-making about when to ship. He discusses the perils of quality-at-all-cost techniques and shares examples of software that features sufficient quality. Find out how testers and test managers can help project stakeholders know whether they are releasing software with too little quality or are unnecessarily striving for too much quality.
|
Jon Bach, Quardev Laboratories
|
