Scenario-based testing is a powerful method for finding problems that really matter to users and other stakeholders. By including scenario tests representing actual sequences of transactions and events, you can uncover the hidden bugs often missed by other functional testing. Designing scenarios requires you to use your imagination to create narratives that play out through systems from various points of view. Basing scenarios on a structured analysis of the data provides a solid foundation for a scenario model.
STARWEST 2008 - Software Testing Conference
This is the tale of a team of software professionals at Microsoft patterns & practices group who wrote a book on software acceptance testing. Grigori Melnik was the content owner, writer, and project manager. Jon Bach was the writer, material producer, and the acceptance testing reality checker, ensuring that the project team used its own methods so the book would be acceptable to you, the reader.
Conceptually, most testers and developers agree that reviews and inspections of software designs and code can improve software and reduce development costs. However, most are unaware that measuring reviews and inspections greatly magnifies these improvements and savings. Riley Rice presents data from more than 4,000 real-world software projects in different domains-defense, commercial, and government. He compares the results of three scenarios: doing few or no reviews, doing unmeasured reviews, and doing measured reviews.
Most test automation focuses on regression testing-repeating the same sequence of tests to reveal unexpected behavior. Despite its many advantages, this traditional test automation approach has limitations and often misses serious defects in the software. John Fodeh describes "test monkeys," automated testing that employs random inputs to exercise the software under test.
FitNesse is an open-source test automation tool that enables business users, developers, and testers to cooperate on agile acceptance testing. FitNesse allows them to build a shared understanding of system requirements that ultimately produces the software that is genuinely fit for its purpose. Gojko Adzic presents an introduction to agile acceptance testing. He discusses when to use FitNesse, when not to use it, and how to start writing acceptance tests with this free tool.
On an agile team everyone tests, blurring the lines between the roles of professional developers and testers. What's so special about becoming an agile test professional? Do you need different skills than testers on traditional projects? What guides you in your daily activities? Lisa Crispin presents her "Top Ten" list of principles that define an agile tester. She explains that when it comes to agile testers, skills are important but attitude is everything.
Although a myriad of testing tools have emerged over the years, only a few focus on the area of API testing for Windows-based applications. Nikhil Bhandari describes how to automate these types of software tests with Windows PowerShell, the free command line shell and scripting language. Unlike other scripting shells, PowerShell works with WMI, XML, ADO, COM, and .NET objects as well as data stores, such as the file system, registry, and certificates.
Although less well known than security and usability testing, conformance and interoperability testing are just as important. Even though conformance and interoperability testing-about standards and thick technical specifications documents-may seem dull, Derk-Jan De Grood believes that these testing objectives can be interesting and rewarding if you approach them the right way. SOA is one example in which numerous services must interact correctly with one another-conform to specs-to implement a system.
Before we can realize the promises of technical agility and reuse from a distributed, service-oriented architecture (SOA), we must first establish trust among stakeholders that SOA will meet business requirements. Rajeev Gupta believes that the best way to instill this sense of trust and make SOA adoption possible is through a shared center of excellence focused on SOA quality.
It seems that senior management is always complaining that testing costs too much. And their opinion is accurate if they consider only the costs-and not the benefits-of testing. What if you could show management how much you have saved the organization by finding defects during testing? The most expensive defects are ones not found during testing-defects that ultimately get delivered to the user. Their consequential damages and repair costs can far exceed the cost of finding them before deploying a system.