Linda Westfall is the President of The Westfall Team, which provides software engineering, software quality engineering, and software project management training and consulting services. Linda has more than 35 years of experience in real time software engineering, quality, and metrics. She has worked as a software engineer, systems analyst, process engineer, and manager. Linda is a past chair of the ASQ Software Division and has served as the Division’s Program Chair and Certification Chair and on the ASQ National Certification Board. Linda is the author of The Certified Software Quality Engineer Handbook. She is an ASQ fellow and has a PE in Software Engineering.
QUEST 2013 Conference and EXPO Sessions:
Testers should be actively participating in peer reviews, bringing diversity of purpose to the team. While everyone else focuses on making the software work, testers bring a “how can I break it” focus that identifies additional defects, improving review effectiveness. Testers are also just as likely to make mistakes as developers. Test work products including test plans, cases, procedures and automation should also be peer reviewed. This minimizes wasted time debugging reported anomalies whose root cause is defects in the testing work products and not in the software. This tutorial is intended to teach skills that increase peer review effectiveness. You will explore the decisions needed to be made in the peer review process including the type of peer review to apply, the level of formality required, the number of participants, and peer review sufficiency.
- Learn skills to increase the efficiency and effectiveness of peer review processes
- Discover how to use criteria for analyzing risk probability and impact indicators when making strategic peer review decisions
- Explore the differences between peer review types and formalities
There is a dichotomy in software configuration management. On one side, individual developers and testers need the flexibility necessary to do creative work, to modify code and tests, to try what-if scenarios, to make mistakes and learn from them to evolve better software solutions. On the other side, teams need stability to allow code and tests to be shared, to create builds and perform testing in a consistent environment, and to ship high-quality products with confidence. This requires an intricate balance. Too much flexibility can result in problems. On the other hand, enforcing too much stability can result in costly bureaucratic overhead, delays in delivery, and may even require developers and testers to ignore the process in order to get their work done. This presentation explores risk-based software configuration control and techniques that can be used to help maintain the balance between flexibility and stability as software moves through the life cycle.