Application Lifecycle Management

Conference Presentations

A Deeper Dive Into Dashboards

This session is a deeper examination of how to apply dashboards in software testing.I spent several months on a project primarily building a software testing dashboard. I have learned some interesting things, including:

  • Resources for free examples
  • Tools to help build dashboards
  • The human issues
Randy Rice, Rice Consulting Services
The Many Hats of a Tester

As testers, we must wear many hats to do our job effectively. Quite often, it is the pith helmet of an explorer, hacking through the vines and darkness of the unknown; or the baseball cap of the crime scene investigator, determining how the failure occurred. To make things even more interesting, the hats we need often differ from project to project and organization to organization. Adam Goucher begins with a general discussion of some hats testers typically wear and when they are appropriate or inappropriate. He then leads an “Art Show” exercise-a brainstorming process resulting in lots of “art” on the walls-illustrating the hats we all may wear in our daily testing activities. Through the Art Show process, you'll take away new insights into what hats you and other testers need, tips for wearing the beautiful ones with success, and how to avoid putting on the ugly ones.
Adam Goucher, Zerofootprint
STAREAST 2010: Testing AJAX: What Does It Take?

Using AJAX technologies, Web 2.0 applications execute much of the application functionality directly in the browser. While creating a richer user-experience, these technologies pose significant new challenges for testers. Joachim Herschmann describes the factors that are critical in testing Web 2.0 applications and what it takes to master these challenges. After presenting an overview of typical Web 2.0 application technologies, Joachim explains why object recognition, synchronization, and speed are the pillars for a truly robust and reliable AJAX test automation approach. He shows how to architect testability directly into AJAX applications, including examples of how to instrument applications to provide the data that testing tools require. Joachim shares his experiences of Micro Focus's Linz development lab and describes how they overcame the challenges of testing their modern AJAX applications.
Joachim Herschmann, Borland (a Micro Focus company)
Using Test Automation Frameworks

As you embark on implementing or improving automation within your testing process, you'll want to avoid the "Just Do It" attitude some have taken. Perhaps you've heard the term "test automation framework" and wondered what it means, what it does for testing, and if you need one. Andrew Pollner, who has developed automated testing frameworks for more than fifteen years, outlines how frameworks have grown up around test automation tools. Regardless of which automation tool you use, the concepts of a framework are similar. Andrew answers many of your questions: Why build a framework? What benefit does it provide? What does it cost to build a framework? What ROI can I expect when using a framework? Explore the different approaches to framework development and identify problems to watch out for to ensure the approach you take will provide years of productivity.
Andrew Pollner, ALP International Corp
Patterns of Testability

Testability requires interfaces for observing and controlling software, either built into the software itself or provided by the software ecosystem. Observability exposes the input and output data of components, as well as monitoring execution flow. Controllability provides the ability to change data and drive actions through the component interface. Without testability interfaces, defects are harder to find, reproduce, and fix. Manual testing can be improved by access to information these interfaces provide, while all automated testing requires them. Alan Myrvold shares software component diagrams that show patterns of testability. These patterns will help you architect and evaluate the observability and controllability of your system. Apply these testability patterns to describe and document your own testability interfaces.
Alan Myrvold, Microsoft
The Myths of Rigor

We hear that more rigor means good testing and, conversely, that less rigor means bad testing. Some managers-who've never studied testing, done testing, or even "seen" testing up close-insist that testing be rigorously planned in advance and fully documented, perhaps with tidy metrics thrown in to make it look more scientific. However, sometimes measurement, documentation, and planning don't help. In those cases, rigor may require us not to do them. As part of winning court cases, James Bach has done some of the most rigorous testing any tester will do in a career. James shows that rigor is at least as dangerous as it is useful and that we must apply care and judgment. He describes the struggle in our craft, not just over how rigorous our processes should be, but what kind of rigor matters and when rigor should be applied.
James Bach, Satisfice, Inc.
Stop Guessing About How Customers Use Your Software

What features of your software do customers use the most? What parts of the software do they find frustrating or completely useless? Wouldn't you like to target these critical areas in your testing? Most organizations get feedback-much later than anyone would like-from customer complaints, product reviews, and online discussion forums. Microsoft employs proactive approaches to gather detailed customer usage data from both beta tests and released products, achieving greater understanding of the experience of its millions of users. Product teams analyze this data to guide improvement efforts, including test planning, throughout the product cycle. Alan Page shares the inner workings of Microsoft's methods for gathering customer data, including how to know what features are used, when they are used, where crashes are occurring, and when customers are feeling pain.
Alan Page, Microsoft
Agile Testing: Uncertainty, Risk, and How It All Works

Teams that succeed with agile methods reliably deliver releasable software at frequent intervals and at a sustainable pace. At the same time, they can readily adapt to the changing needs and requirements of the business. Unfortunately, not all teams are successful in their attempt to transition to agile and, instead, end up with a "frAgile" process. The difference between an agile and a frAgile process is usually in the degree to which the organization embraces the disciplined engineering practices that support agility. Teams that succeed are often the ones adopting specific practices: acceptance test-driven development, automated regression testing, continuous integration, and more. Why do these practices make such a big difference? Elisabeth Hendrickson details essential agile testing practices and explains how they mitigate common project risks related to uncertainty, ambiguity, assumptions, dependencies, and capacity.
Elisabeth Hendrickson, Quality Tree Software, Inc.
Software as a Service: What You Need to Know

Many familiar products, including email, instant messaging, search, and e-commerce sites, are actually implemented as services rather than PC-installed software. The shift to services now extends to everything from office productivity tools to utilities like storage, authentication, manageability, and application hosting. Engineers who want to build highly available services with a positive user experience face unique design, testing, and operational challenges. Ibrahim El Far and Venkat Narayanan discuss aspects of configurability, including the ability to turn off features quickly or redirect traffic that minimizes the impact of defects on the user experience. They discuss the importance of fault testing and explain why testing a service must happen everywhere from the workstation to the live site. Learn best practices in operations, including automated deployment, monitoring services, and service repairs.
Ibrahim El Far, Microsoft Corporation
Successful Teams are TDD Teams

Test-Driven Development (TDD) is the practice of writing a test before writing code that implements the tested behavior, thus finding defects earlier. Rob Myers explains the two basic types of TDD: the original unit-level approach used mostly by developers, and the agile-inspired Acceptance-Test Driven Development (ATDD) which involves the entire team. Rob has experienced various difficulties in adopting TDD: developers who don't spend a few extra moments to look for and clean up a new bit of code duplication; inexperienced coaches who confuse the developer-style TDD with the team ATDD; and waffling over the use of TDD, which limits its effectiveness. The resistance (overt or subtle) to these practices that can help developers' succeed is deeply rooted in our brains and our cultures.
Rob Myers, Agile Institute

Pages

CMCrossroads is a TechWell community.

Through conferences, training, consulting, and online resources, TechWell helps you develop and deliver great software every day.