|
|
|
|
|
|
|
| |
|
|
|
|
|
|
| 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. |
 |
| Learn more about James Bach |
|
|
|
|
|
|
| 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. Learn new ways to think and talk about the testability of your software and create interfaces for a more robust test effort. |
 |
| Learn more about Alan Myrvold |
|
|
|
|
|
|
| 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. Leave with a better understanding of automated frameworks and the confidence to build your own or improve the one you have. |
 |
| Learn more about Andrew Pollner |
|
|
|
|
|
|
| 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. Join Joachim to learn how testers and developers can collaborate to create more testable Web 2.0 applications. |
 |
| Learn more about Joachim Herschmann |
|
|
|
|
|
|
|
| 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. |
 |
| Learn more about Adam Goucher |
|
|
|
|
|
|
| Some people thrive on challenges; others struggle to deal with them. Handled well, challenges can make us stronger in our passion, drive, and determination. Lloyd Roden describes the software testing challenges we face today and how we can respond in a positive, constructive manner. One challenge Lloyd often sees is identifying and eliminating metrics that lie. While we (hopefully) do not set out to deceive, we must endeavor to employ metrics that have significance, integrity, and operational value. Another challenge test leaders face is providing estimates that have clarity, accuracy, and meaning. Often when developing test estimates, we omit a vital ingredient—the quality required in the product. A third challenge is convincing test managers to actually test regularly to attain credibility and respect with the team they are leading. Join Lloyd as he delivers passionate and compelling arguments for turning these and other challenges into opportunities for the test team. |
 |
| Learn more about Lloyd Roden |
|
|
|
|
|
|
| The basic problem in software testing is choosing a subset from the near infinite number of possible test cases. Testers must select test cases to design, create, and then execute. Often, test resources are limited—but you still want to select the best possible set of tests. Peter M. Kruse and Magdalena Luniak share their experiences designing test cases with the Classification-Tree Editor (CTE XL), the most popular tool for systematic black-box test case design of classification tree-based tests. Peter and Magdalena show how to integrate weighting factors into classification trees and automatically obtain prioritized test suites. In addition to “classical” approaches such as minimal combination and pair-wise, they share new generation rules and demonstrate the upcoming version of CTE XL that supports prioritization by occurrence probability, error probability, or risk. If your test case design methods are stuck in the last century, this session is for you. |
  |
| Learn more about Peter Kruse & Magdalena Luniak |
|
|
|
|
| Kiran Pyneni, Aetna, Inc. |
|
|
| Many testing organizations mistakenly declare success when they first introduce test automation into an application or system. However, the true measure of success is sustaining and growing the automation suite over time. You need to develop and implement a flexible process, and engage knowledgeable testers and automation engineers. Kiran Pyneni describes Aetna’s two-team automation structure, the functions that each group performs, and how their collaborative efforts provide for the most efficient test automation. Kiran explains how to seamlessly integrate your test automation lifecycle with your software development lifecycle. He shares specific details on how Aetna’s automation lifecycle benefits their entire IT department and organization, and the measurements they use to track and report progress. Take back an organization structure, an automation process, and a set of the metrics to showcase how test automation can add value to your entire development organization. |
 |
| Learn more about Kiran Pyneni |
|
|
|
|
|
|
| In most software engineering organizations, development and test labs continuously demand regular computer, storage, and networking infrastructure upgrades and continuous support. Lab administrators have moved toward server consolidation powered by virtualization platforms from vendors such as Citrix, Microsoft, and VMware, often accompanied by a management layer called virtual lab automation (VLA). Together, virtualization and VLA enable the lab to operate as a private, on-premise cloud. While this solves some problems, there are still other challenges to consider. Some test labs now leverage public cloud infrastructures such as Amazon Web Services. Ravi Gururaj reviews virtual labs enabled in private, public, and hybrid clouds, and explains how they improve development, build, and test processes. Learn about the key areas of consideration for organizations adopting or evaluating this approach, including security, public cloud infrastructure, operational flexibility, user access models, and compliance. |
 |
| Learn more about Ravi Gururaj |
|
|
|
|
|
|
| Charters help you guide and focus exploratory testing. Well-formed charters help testers find defects that matter and provide vital information to stakeholders about the quality and state of the software under test. Rob Sabourin shares his experiences defining different exploratory testing charters for a diverse group of test projects. For example, reconnaissance charters focus on discovering application features, functions, and capabilities; failure mode charters explore what happens to applications when something goes wrong. In addition, you can base charters on what systems do for users, what users do with systems, or simply the requirements, design, or code. Rob reviews key elements of a well-formed testing charter—its mission, purpose, focus, understanding, and scope. Learn how to evolve a test idea into an exploratory charter using examples from systems testing, Scrum story testing, and developer unit testing. |
 |
| Learn more about Rob Sabourin |
|
|
|
|
|
|
| Over the years, the test manager’s role has evolved from “struggling to get involved early” to today’s more common “indispensable partner in project success.” In the past, when “us vs. them” thinking was common, it was easy to complain that the testing effort could not be carried out as planned due to insufficient specs, not enough people, late and incomplete delivery, no appropriate environments, no tools, tremendous time pressure, etc. Martin Pol explains how today’s test managers must focus on providing a high level of performance. By using a service-driven test management approach, test managers support and enhance product development, enabling the project team to improve overall quality and find solutions for any testing problem that could negatively impact the project’s success. Learn how to manage in the modern testing scene by anticipating from the beginning, organizing alternatives and shortcuts, enabling the project team to deliver quality, and taking ownership as a full partner in the project. |
 |
| Learn more about Martin Pol |
|
|
|
|
|
|
| Users are the ultimate judge of the software we deliver because it is critical to their success and the success of their business. However, as a tester, do you really understand their tasks, skills, motivation, and work style? Are you delivering software that matches their needs and capabilities—or yours? Personas are a way to define user roles—imaginary characters—that represent common sets of characteristics of different users. Euan Garden shares how his team at Microsoft defined and used one persona named “Ellen” to help them design, develop, and test the first version of a new product. Euan shares before Ellen and after Ellen examples of the product, showing how the product changed when Ellen joined the team. See examples of the robust test cases and acceptance scenarios they defined from unique insights that Ellen provided. Discover how to create and utilize an “Ellen” on your next project or on the one you’re struggling with today. |
 |
| Learn more about Euan Garden |
|
|
|
|
| Martin Gijsen, DeAnalist.nl |
|
Although testers are good at test analysis and design, few are expert developers who can create good automated tests. This often leaves automated test development in a kind of no man's land between the disciplines of testing and development. Martin Gijsen shows how using a high-level, Domain Specific Test Language (DSTL) solves this dilemma. Applicable to any system or application with either waterfall or agile development, this advanced form of keyword-driven testing allows testers to focus on testing issues and developers to focus on programming by separating “what” to test from “how” to test. Using DSTLs, automated tests require no programming skills to write and maintain. Martin demonstrates how developers can implement DSTL keywords using any suitable technology, including free open source software, and how testers can benefit from effective automated testing as systems evolve.
|
 |
| Learn more about Martin Gijsen |
|
|
|
|
|
|
| Organizations currently are using virtualization in the test lab to eliminate underutilized systems such as physical computers and software. So why not virtualize the costly, overutilized, or completely unavailable elements of the software architecture that have serious access and data issues for testing? These elements required for realistic end-to-end testing—mainframe computers, production systems of record, and computing services hosted by other companies—are often difficult or expensive to access for testing. Rajeev Gupta explains how virtualizing these overutilized systems can make the constraints of capacity, test data, and availability for testing a distant memory. Discover how service virtualization, employed as an adjunct to hardware lab virtualization, eliminates the bottlenecks and data management efforts that stymie many test and development teams. Enhance your test lab's availability and capacity and lower costs at the same time with virtualization services. |
.jpg) |
| Learn more about Rajeev Gupta |
|
|
|
|
|
|
| Perhaps the most sought after and least understood metric in software testing is the ratio of testers to developers. Many people are interested in learning the standard industry ratio so that they can determine the proper size of their test organization. Randy Rice presents the results of his recent research on this metric and explores the wide range of tester-developer ratios in organizations worldwide. Learn why this metric is almost always not the best way to determine your test organization’s staffing levels and how to understand and apply this metric in more helpful ways. Find out how different tester-developer ratios relate to test effectiveness. Take away a new appreciation of your own tester-developer ratio and ways to meaningfully convey this metric to management to help rightsize your test team and improve the ROI of testing. Determine the “right ratio” of testers to developers in your team and company. |
 |
| Learn more about Randy Rice |
|
|
Top of Page
|
|
|
 |
|
|
|
|
