You can think of Q-Patterns as a structured set of questions (tests) about the different aspects of a software application under test. They are questions about the system that are categorized, grouped, sorted, and saved for reuse. These Q-Pattern questions can be written ahead of time and stored in a repository of test case templates, developed for requirements and design reviews or built in real-time as a way to both guide and document exploratory testing sessions. See examples of Q-Patterns that Vipul Kocher has developed for error messages, combo boxes, login screens, and list handling. Learn how to associate related Q-Patterns and aggregate them into hierarchical and Web models. Take back the beginnings of Q-Patterns for your test team and organization.
Sharable and reusable test case designs
Templates to organize requirements and design reviews
When test engineers use the term "acceptance testing," they might be saying and thinking profoundly different things. Acceptance testing can mean one of at least a dozen approaches to the testing of a product and serve one or more of at least thirty different customer roles in a project. Tests and testing approaches that are appropriate in one context can be unacceptable-even disastrous-in another. When someone asks you to do user acceptance testing, what should you do? When should you do it? How do you determine success? Michael Bolton outlines the ways in which testers and test managers use context-driven thinking to better serve the mission of acceptance testing and develop skills to handle dramatically different testing situations. Apply your context in this interactive session to discover ways to improve your acceptance testing, and learn to use context-driven thinking in other areas, too.
With frequent reports in the news of successful hacker attacks on Web sites, application security is no longer an afterthought. More than ever, organizations realize that security has to be a priority while applications are being developed-not after. Developers and QA professionals are learning that Web application security vulnerabilities must be treated like any other software defect. Organizations can save time and money by identifying and correcting these security defects early in the development process. Ryan English helps you overcome the “deer in the headlights” look when you are asked to begin testing applications for security issues. See real world examples of company Web sites that have been hacked because of vulnerable applications and see how the attacks could have been avoided.
Security defect categories and responsibility areas
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"!
James Bach, Satisfice, Inc. and Jon Bach, Quardev Laboratories
Many software test and development teams struggle to test systems with complex set-up steps and multiple configurations. With these interdependent software systems, testers must iterate through very large, multi-dimensional test matrixes (for example, permuting front-, middle-, and back-tier platforms) to complete the test requirements. Testers have the difficult and sometimes seemingly impossible task of duplicating failures and saving the system’s state for later analysis and debugging. With several emerging commercial software tools, software development organizations can successfully implement live-state software test configuration provisioning and capture systems.
Many organizations use code coverage almost religiously in their testing. Just as many or more organizations do not use code coverage or have tried it and stopped. If you want to begin using code coverage for the first time or improve its value and usage within your team, come hear what Dale Brenneman has to share. Using real-life examples, Dale explains the value of code coverage analysis as part of a comprehensive test plan and the potential side effects when you do not use code coverage. Find out about the many levels of code coverage and ways to enhance the value of code coverage analysis with other analysis techniques. Take away a step-by-step approach for integrating code coverage analysis into your organization's test process and fitting it into your functional test automation program.
The levels of module code coverage: entry, line, statement, branch, Boolean, cyclomatic path, all paths
Internal test metrics--test progress, defect density, and TPI/TMM measures on process improvement-do not reveal the complete picture of test value and success. By comparing common test metrics with those found in the Balanced Business Scorecard--financial, customer, internal, and learning/innovation metrics-we see the need to also report financial and customer measures. Some of these measures are quantitative (such as profits), and others are more qualitative (for example, customer satisfaction). Learn to measure the financial impact of testing through productivity metrics and measures of how testing affects the total cost of quality. Include in your reporting qualitative assessments such as the customers' perception of the usefulness of testing, the visibility of testing on projects, acceptability measures, and estimation accuracy.
Set measures for all viewpoints of testing's value and success
Achieving CMMI® Level 5 Capability as an independent test organization takes a tremendous effort. However, achieving CMMI® Level 5 or a lower level compliance is not out of your reach. Join Kristen Bevans as she describes how the IBM Global Test Organization team successfully completed a formal SEI CMMI® Level 5 SCAMPI Class A appraisal as an independent test organization. The appraisal used the Continuous Representation of the SEI CMMI-SE/SW/IPPD/SS V1.1 Model achieving CMMI® Level 5 in the project planning, project monitoring and control, risk management, and verification process areas. Discover how to develop your CMMI® core team, establish the scope, plan the effort, prepare for an appraisal, and conduct the appraisal with SCAMPI methods. Kristen shares her thoughts on what they would do differently-and what they would do the same-if they had it to do over again.
It is well known that the earlier in the development lifecycle a fault is found, the less costly it is to resolve. Whether you use traditional or agile development practices, you have an opportunity to implement Agile Inspections for finding faults before the code is even written. An Agile Inspection is a lightweight process that brings the skills and outlook of professional testers into the design of software. A good precursor to formal test planning, an Agile Inspection is a way to inform developers-in a way that makes sense to them-of how you are going to test. It offers the best chance to increase the testability of software at the lowest cost. Find out from Richard Durham the prerequisites for adopting Agile Inspections, what to look for in an inspection, how to communicate findings, and approaches to encourage buy-in from management and developers.
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.