|
|
Testing SOA Applications: A Guide for Functional Testers Functional testers assigned to their first SOA application can easily be caught off guard by some of the challenges posed by the SOA architecture. Testing without a user interface, the importance of security and performance, and the heavy emphasis on negative testing all require testers to approach SOA applications with new tools, techniques, and a different attitude. Through practical demonstrations of open source and commercial tools, Brian Bryson demonstrates techniques to test SOA applications. Brian starts by building and deploying a Web service, the main building block of SOA applications. Then, he tests this Web service from the ground up beginning with functional unit testing using jUnit and progressing to infrastructure testing using SoapClient and Eclipse. Brian concludes with a discussion of security and performance testing issues.
|
Brian Bryson, IBM Rational
|
|
|
The Ten Principles of an Agile Tester On an agile team, everyone is a tester-anyone can and often does take on testing tasks. If that’s true, then what is special about being an agile tester? If I'm a tester on an agile team, what does that really mean? Do agile testers need different skill sets than testers on traditional teams? What guides agile testers in their daily activities? An agile tester embraces change, collaborates well with both technical and business people, and understands the concept of using tests to document requirements and help drive development. Agile testers have good technical skills, know how to collaborate with others to automate tests, and are experienced exploratory testers. How do they get that way? Skills are important, but mindset and attitude count even more.
|
Lisa Crispin, ePlan Services, Inc.
|
|
|
Branch Out: Using Classification Trees for Test Case Design A structured, visual approach to identify and categorize equivalence partitions for test objects, classification trees offer a unique way for you to document test requirements so that anyone can understand them and quickly build test cases. Join Julie Gardiner to look at the fundamentals of classification trees and how they can be applied in both traditional and agile test and development environments. Using real-world examples, Julie shows you how to use the classification tree test technique, how it complements other testing techniques, and its value at every stage of testing. She demonstrates one classification tree editor from among the free and commercial tools now available to help you build, maintain, and display classification trees.
- How to develop classification trees for test objects
- Benefits and rewards of using classification trees
- When--and when not--to use classification trees
|
Julie Gardiner, Grove Consultants
|
|
|
The Angels and Devils of Software Testing It's never been easier to fool your manager into thinking you're doing a great job testing! Does that sound tempting? Some would rather spend time playing Spider Solitaire, Foosball, or watching online videos of cats begging for cheeseburgers instead of doing their testing work. Jonathan Kohl and Michael Bolton discuss the types of test fakery that are out there-and that you need to avoid. These temptations include banishing critical thinking, using misleading test case metrics, generating impressive looking but useless test documentation, maintaining obsolete tests (so we have something to count and display), engaging in methodology doublespeak, tinkering endlessly with expensive test automation tools, and taking credit for a great product that would have been great even if no one had tested it.
|
Michael Bolton, DevelopSense
|
|
|
Testing Lessons Learned from Extreme Programmers One of the things testers often notice about Extreme Programming (XP) is that there is no defined role for testers on the team. Yet XP teams describe themselves as "test infected." They practice Test-Driven Development (TDD), writing executable unit tests before writing the code to be tested. Many teams practice Acceptance Test-Driven Development (ATDD), writing executable acceptance tests before implementing a feature. They use continuous integration to give them rapid feedback about the effects of changes. They practice pair programming, a technique that results in all code being peer reviewed before it's checked in. In short, XP teams test continuously from the very first moment of any given project. You could even call them "test obsessed." That obsession helps explain why Elisabeth Hendrickson, author of Test Obsessed, likes XP teams so much.
|
Elisabeth Hendrickson, Quality Tree Software, Inc.
|
|
|
Testing Dialogues - In the Executive Suite As Microsoft’s only dual-role security and reliability architect, James Whittaker is often asked to brief company executives on product quality disasters and recommend remedies. With billion dollar warranty write-offs at stake, such counsel is often sought, but the answers those executives receive are rarely what they expect. James tells them that the ecosystem is sick. From academia who train our new developers and testers, to tool vendors who manage only to delay our suffering, to consultants who offer incremental process improvement (with largely unnoticeable results), to our very own testing-oriented culture of last minute project heroics-the system is broken. To fix it, James argues against three sacred cows in software development-(1) A four year computer science degree is the proper training for a software developer.
|
James Whittaker, Microsoft
|
|
|
Testing on the Toilet: Revolutionizing Developer Testing at Google You work in an organization with incredibly smart and diligent software engineers. Deadlines are tight and everyone is busy. But when developers outnumber testers by ten to one and the code base is growing exponentially, how do you continue to produce a quality product on time? Google addressed these problems by creating the Testing Grouplet-a group of volunteer engineers who dedicate their spare time to testing evangelism. They tried various ideas for reaching their audience. Weekly beer bashes were fun but too inefficient. New-engineer orientation classes, Tech Talks by industry luminaries, and yearly "Fixit" days became successful and continue to this day. But no idea caught the attention of engineers like Testing on the Toilet. This weekly flyer, posted in every Google restroom, has sparked discussions, controversy, jokes, and parodies.
|
Bharat Mediratta, Google, Inc.
|
|
|
Transforming Your Test Culture: One Step at a Time Whether we develop software-based systems to create invoices, solve difficult physics problems, diagnose heart disease, or launch rockets, we've learned that nothing stays the same very long and software defects are inevitable. However, one thing has remained constant—the role and value of testing has been misunderstood by many in senior management. A Lockheed Martin Fellow since 2005, Tom Wissink describes steps undertaken at Lockheed Martin to change this culture of misunderstanding into a culture of appreciation, satisfaction, and excitement. Tom's experience has convinced him that this change is not just theoretical but both possible and rewarding. In a few organizations, both large and small, this has resulted in dramatic changes including greater tester satisfaction, increased company profits, and improved software quality often delivered on time and within budget.
|
Thomas Wissink, LM IS&S
|
|
|
Ready to Ship? When developing software systems, the inevitable question is "Are we ready to ship?" Facing this question, many testers and test managers rely on their intuition and gut feeling to come up with a subjective verdict of the system under test. John Fodeh describes how to establish and use a set of Release Readiness Metrics in your organization. These metrics provide a snapshot of the system state and quality that you can use throughout the development process--especially when approaching the release date. John takes a closer look at these metrics and examines the role of testing and testers as “information providers.” John demonstrates different release-related metrics, including a model for predicting how many defects remain in the system after release.
|
John Fodeh, HP Software
|
|
|
That's Not Right! Using Fit to Prevent Business Rule Defects Sophisticated applications involve huge numbers of detailed domain business rules. These rules are the heart of the application, determining critical details such as how much money is transferred between two banks (in a financial application), which compounds have been identified in a sample (in a chemistry application), or how a customer's money should be refunded (in a point-of-sale application). These details, while crucial, are too easy to get wrong. Sometimes, only the business experts can tell when the software is right or wrong. That's where open source Fit can help you. Fit is an automation tool for helping improve communication between business experts and programmers, allowing you to identify miscommunication and prevent business rule defects before they happen. Join James Shore for an introduction to using Fit in your project.
|
James Shore, Titanium IT LLC
|
