Action Word Testing. This concept illuminates testing as an action, a process, an art. Learn how Action Word Testing can be applied to deal with critical test issues such as lack of functional knowledge of a system under test; instability of the design during test development; and automation of 100% of the functional or technical tests. Hans Buwalda uses a financial exchange that's introduced a new electronic trading system to demonstrate Action Word Testing (approximately 15,000 tests). In this example, automation of the entire test was essential, but it was difficult to achieve.
Everyone knows that a large body of automated unit tests for classes, subsystems, and frameworks adds to overall code quality. However, the "burden" of unit test automation is frequently placed squarely on the shoulders of developers because of the perception that only a developer can write a unit test. Since QA personnel typically test from the user interface-and usually have to wait until later in the development cycle for the availability of that interface-they're often left to scramble at the end of the cycle to get their testing done. Michael Silverstein reveals a model for early-cycle collaboration between developers and testers where testers augment the developers' unit testing activities without adding additional process overhead.
Many testing organizations focus primarily on software executable code, but that's not the only thing you can test. For instance, did you ever consider testing your software requirements? When you test only code, you face some big disadvantages, not to mention that design defects often aren't even fixable because they demand too much effort, too late in the release cycle. In fact, it's difficult to even report some requirements defects since the developers have already committed to the design strategy. But if you test your requirements early in the game, you can discover defects before they're cast into designs and code, consequently saving your organization potentially huge rework costs.
Testware: the stuff of which tests are made. The term comprises a bewildering range of artifacts including data files, scripts, expected results, specifications, and environment information. It also implies how these artifacts are arranged, where they're stored and used, and how they're grouped and referenced. Since testware architecture has not traditionally been considered an important issue, individual projects and teams, even individual testers, have evolved their own approaches to the arrangement of their testware, resulting in much wasted effort. Of course, different applications and environments may demand unique testware architectures, but do they have to be so different? Isn't there a single, unified, flexible, and expandable approach that fits most, if not all, situations within an enterprise? Perhaps not, but the goal of uniform testware architecture across projects is certainly worth striving for.
Rapid changes and stunted delivery deadlines are always challenging software testers. To catch up, software testing must take a different approach without cutting corners-hence, the crash team. The crash team approach focuses on integration testing and runs in parallel with functional testing. Its technique discovers system problems early, problems that would be hard to find with traditional methods. It also supports the spiral development model that's been adopted in many rapid application development environments.
When processes include several applications, the testing process is complicated in many ways. Possible complications include: organizational issues because of the multitude of test teams and their interdependencies; processes and transactions that span the chain which require new test scenarios; integral design, information analysis, and process design documents that aren't fit for the purpose of chain testing; and test execution that demands integral knowledge of the chain. This session gives you a list of all the variables that need to be considered, then offers solutions for successfully organizing chain testing.
Basis path testing is a structural testing technique that identifies test cases based on the flows or logical paths that can be taken through the software. A basis path is a unique path through the software where no iterations are allowed; they're atomic level paths, and all possible paths through the system are linear combinations of them. Basis path testing uses a Cyclomatic metric that measures the complexity of a source code unit by examining the control flow structure. Basis path testing can also be applied to integration testing when software units/components are integrated together. You'll see how the use of the technique quantifies the integration effort involved as well as the design-level complexity.
"This isn't what I need," states Customer Bob. "But it's what you said you wanted," replies Engineer Joe. "It's not right. I need something else." We've all encountered this classic users-don't-know-what-they-want scenario. The fact that software professionals continue to have this same experience over and over again suggests that we're overlooking the real reasons for the user/engineer disconnect. This presentation contrasts the different uses of the term "requirements" as it explores the possible solutions to improving understanding between business people and technical people.
The preparation of a realistic, practical project schedule is an essential management function for obtaining stakeholder commitment, setting expectations, and communicating within the team and organization what is achievable. Doing this preparation well is another challenge-one that must be conquered. Rex Black helps participants see the bigger project scheduling picture by focusing on issues such as constituent tasks, the underlying dependencies between them, and the risks attached to the completion of those tasks.
Automated tests using self-verifying data (SVD) can help determine if your query-type tests have the right information or if they are showing you the expected views. In this presentation, Noel Nyman provides a brief overview of an SVD testing method followed by a demonstration of automation techniques that allow you to run random tests on SVDs with millions of records or entries. Using applications such as Microsoft Office, learn how to adapt the techniques taught in this presentation to many different types of applications using most of the common automation tools.