Want to improve the quality of your products? Of course you do. But how? Mette Bruhn-Pedersen uses a simple, but effective method that includes both clients and users in the development process. His company organizes and conducts verification sessions early in the development process. These sessions consist of two parts: First is a demonstration of the implemented functionality using test cases as examples; second is a "play" session in which the customer is given control of the system to explore the functionality from a business perspective. By observing the client, testers get a better understanding of what functionality is most important to the client as well as increasing their knowledge of the software's intended use. Sometimes, the clients find important, new defects during the session. And almost always, testers learn they need to add new test scenarios based on their observations during the play session.
Peer code reviews can be one of the most effective ways to find bugs. However, developers will not accept a heavy process, and it's easy to waste time using poor methods. Jason Cohen describes how lightweight code review practices can succeed where more cumbersome, formal inspections fail. He shares the results from the largest case study of peer reviews ever conducted. You will gain new insights on how much time to spend in review, how much to code review in one session, and how author preparation practices can increase the efficiency of a review. Jason offers tips on the mechanics of lightweight code reviews and compares five common styles of review. He provides advice on how to build checklists and describes what metrics can actually tell us. Learn how to conduct practical, time-efficient code reviews while avoiding the most common mistakes.
Why lightweight reviews work where formal inspections fail
Inspections have over thirty years of history improving software quality and productivity. Numerous studies have shown inspection is the most effective process for discovering defects. Yet today, inspections are not widely used in the software industry. Why are they not more prevalent? Ed Weller knows that successful implementation of inspections requires a thorough understanding of
the process as well as the cultural and organizational roadblocks to implementation. Knowing when to apply inspections, or other defect identification techniques, also requires a cost-benefit analysis. Measuring and improving inspections requires an understanding of inspection process metrics and appropriate corrective actions. Ed discusses the inspection process, measurement, common pitfalls, and how to implement a successful program in your organization.
Learn what makes inspections different from other types of reviews
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
As a CMMI® Level 5 company, Motorola Global Software Group is heavily involved in software verification and validation activities. Shalini Aiyaroo, senior software engineer at Motorola, shows how tracking specific testing metrics can serve as key indicators of the health of testing and how these metrics can be used to improve your testing practices. Find out how to track and measure phase screening effectiveness, fault density, and test execution productivity. Shalini describes the use of Software Reliability Engineering (SRE) and fault prediction models to measure test effectiveness and take corrective actions. By performing orthogonal defect classification (ODC) and escaped defect analysis, the group has found ways to improve test coverage.
CMMI® is a registered trademark of Carnegie Mellon University.
As a manager, you want to select and develop people with the talents to become great testers, the ability to learn the skills of great testers, and the willingness to work hard in order to become great testers. As an individual, you aspire to become a great tester. So, what does it take? Michael Hunter reveals his twenty hallmarks of a great tester from personality traits-curiosity, courage, and honesty-to skills-knowing where to find more bugs, writing precise bug reports, and setting appropriate test scope. Measure yourself and your team against other great testers, and find out how to achieve greatness in each area. Learn how to identify the great testers you don’t know that you already know!
The personality traits a person needs to become a great tester
The talents a person needs to become great tester
The skills you need to develop to become a great tester
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.
Verification at the end of a software development cycle is a very good thing. However, if verification routinely finds important defects, then something is wrong with your process. A process that allows defects to build up-only to be found and corrected later-is a process filled with waste. Processes which create long list of defects are . . . defective processes. A quality process builds quality into the software at every step of development, so that defect tracking systems become obsolete and verification becomes a formality. Impossible? Not at all. Lean companies have learned how wasteful defects and queues can be and attack them with a zero tolerance policy that creates outstanding levels of quality, speed, and low cost-all at the same time. Join Mary Poppendieck to learn how your organization can become leaner.
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"!
The Johns Hopkins University Applied Physics Laboratory formed an embedded software group for producing space flight software. In addition to defining the process for developing and testing this software, the group had to quickly apply and adjust the new processes to a series of four spacecraft missions, starting in 2001, as resources were over-extended and schedules were compressed. Brenda Clyde shares highlights, complexities, and differences of testing these spacecraft missions in the last four years. She describes the initial test process, the problems encountered during the test phase for each mission, the resolution of the problems, and the incorporation of the changes into the next mission. Learn about the challenges the Applied Physics Laboratory faced testing embedded software and the process in place for testing their next spacecraft mission.