Conference Presentations

"How to Build a Better Test Script" with a Component-Based Approach

Do you dream of having a centralized, modular set of test script steps or "components" that you can link together many times in multiple test scripts to create end-to-end fully automated tests? If so, join Jeff Roberts as he lays out, step-by-step, the real-life method his company has used for the past four years to do just that. With a database of script components, they write functional test scripts more quickly and, as the software changes, update them more efficiently. In a presentation detailing how this process was used in a real-world setting, Jeff explains the approach adopted by his large testing organization with multiple products and teams operating in multiple locations. Learn to break down your scripts into standardized components categorized as procedures, how-to information, data, and SQL commands. Take back the basics of a complete methodology for building and maintaining better test scripts.

Jeff Roberts, Convergys
Inside The Masters' Mind: Describing the Tester's Art

Exploratory testing is both a craft and a science. It requires intuition and critical thinking. Traditional scripted test cases usually require much less practice and thinking, which is perhaps why, in comparison, exploratory testing is often seen as "sloppy," "random," and "unstructured." How, then, do so many software projects routinely rely on it as an approach for finding some of its most severe bugs? If one reason is because it lets testers use their intuition and skill, then we should not only study how that intuition and skill is executed, but also how it can be cultivated and taught to others as a martial art. Indeed, that's what has been happening for many years, but only recently have there been major discoveries about how an exploratory tester works and a new effort by exploratory testing practitioners and enthusiasts to create a vocabulary.

Jon Bach, Quardev Laboratories
STARWEST 2005: Testing Outside the Bachs: A Hands-On Exploratory Testing Workshop

Simply put, exploratory testing means designing your tests as you perform them. When it's done well, it's a fantastically productive and rewarding approach to testing. However, to do it well requires training, practice, and discipline. Lecture presentations about exploratory testing are a poor substitute for seeing it and doing it. So ... plan to bring your laptop to this session and test along with James Bach and Jon Bach as they demonstrate exploratory testing in a live testing workshop. Participate or just observe as exploratory testing is performed in real time with play-by-play and color commentary. Learn how to bring structure to this apparently unstructured testing method. See if you can find bugs that they do not find as you test "outside the Bachs"!

Jon Bach, Quardev Laboratories
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
Inside the Explorer's Notebook

Exploratory testing is more than just thinking of clever test ideas and executing them on a whim. It's a craft, requiring practice of several classic scientific skills-one of those skills is careful documentation of observations and conjectures. But as much as testers are scientists, they are also explorers. They must document their actions and observations during testing in such a way that stakeholders can easily understand the important problems and issues that are being discovered. In this track talk, expert exploratory tester Jon Bach compares exploratory test notes from several software projects to the journals of historical adventurers, showing how a tester's
journey through unchartered software can reveal similar risks and riches. Jon will discuss three common note-taking styles, as well as good, bad, and ugly notes he has seen (and produced!) in his ten years of testing.

Jon Bach, Quardev, Inc
Legal Compliance in Quality Assurance

In many industries, we must comply with state or federal statutes, government regulations, and other legal standards. The Sarbanes-Oxley Act (SOX) has brought a new awareness to these issues within testing. So, how do you incorporate legal compliance into your QA and test efforts, and how do you get the information you need to do the job well? Elle Ringham, who deals with these important issues every day at Fidelity National Financial, shares her knowledge and experiences. First, she helps you understand the types of legal compliance bodies that can affect applications and offers research methods for industry specific areas of legal compliance, including internal sources, websites, and search strategies. Then, she discusses the artifacts and metrics needed to be maintained

Elle Ringham, Fidelity National Financial
Model-Based Testing Meets Exploratory Testing

When we are faced with software with unknown requirements or software in an unstable condition, exploratory testing is a cost-effective test technique. Once a product is more stable and settled, the value of exploratory testing drops off rapidly. Model-based testing, on the other hand, provides extremely thorough testing that can run day and night, but it can be difficult to justify the required
investment. Exploratory modeling is a technique that bridges the gap between manual testing and model-based test automation. It uses the information you gather during the exploration phase to fuel the test generation in the later phase, combining the best aspects of these very different

Harry Robinson, Google
Structured Testing within the Rational Unified Process

Many organizations have adopted, or are in the process of adopting, the Unified Process (UP) and, in particular, the Rational Unified Process (RUP). The test process defined within UP/RUP differs from more traditional, structured testing processes such as TMap (Test Management Approach) in Europe and STEP™ (Systematic Test and Evaluation Process) in the US. Tim Koomen, who has operated within these and other development lifecycle and test processes,
describes testing as defined in UP/RUP, maps the processes to those in TMap, and combines them into a "best of both worlds" approach. Learn about the UP/RUP defined practices such as the risk based test strategy, testability, test design, the role of the tester, independent testing,

Tim Koomen, Sogeti - Netherlands
Test Improvement for Highly Reliable NYSE Trading Systems

With billions of dollars changing hands every day, financial trading systems demand extremely high accuracy and reliability. So, how do you improve test process performance in the areas of time to market and efficiency and at the same time reduce failures? Over the last three years, using process and project measurement data as a guide, SIAC has focused on doing exactly that. Steve Boycan highlights the key elements of the process changes that have led to SIAC's current performance: the use of a rigorous requirements engineering process; controlled parallel and iterative work flows; changes to the level of abstraction in test documentation; emphasis on test planning, analysis, and design; causal analysis; and improving the test team's skills.

Steve Boycan, SIAC
The QA/Testing Perspective on Software Security

Most everyone now realizes that we cannot solve security vulnerabilities with firewalls, virus scanners, and other tactics that build an electronic “moat” around systems. According to Julian Harty, security is not an operational issue, not a developer issue, and not a testing issue. It is a systems issue that you must focus on throughout the software’s life. From a QA/testing perspective, we need to look early in the development process for adequate security requirements. Then, we should assess the designs for vulnerabilities and participate in security code reviews. When specialized, security tests find bugs that get past our early prevention efforts, causal analysis helps prevent the recurring security defects. Dig into system security issues with Julian and learn about manual techniques, commercial software, and home-brew automation tools to help you find security vulnerabilities-before the bad guys do.

Julian Harty, Commercetest Limited

Pages

CMCrossroads is a TechWell community.

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