Everyone pays lip service to the importance of unit testing, but rarely do developers actually integrate unit testing into their daily routine. In the spirit of eXtreme Programming, this presentation offers a simple two-class framework for automating unit tests in three popular languages: C++, Java, and C. No GUI, no templates, just a fast and productive way of organizing and running suites of unit tests. You'll walk away wondering how you have done without this simple technique for so long.
Thousands of hours are spent testing, but most software professionals find that traditional testing simply isn't enough to ensure code quality. This presentation gives software professionals a complementary approach: software inspection. Learn how software inspection differs from traditional testing, and gain an understanding of principal inspection techniques.
How many times have you finished testing on a release and said "Boy, I never want to go through one like that again." Or have you ever had a project canceled and said "If only I would have known at the beginning, what I know now, I would have done things a lot differently." Or when you finished testing on release one, said “next time I want to do it differently,” then said the same thing on releases two, three, and four? If any of these thoughts resonate with you, then I think you will be interested in the Lessons Learned process. Lessons Learned is a powerful post-mortem process that can be used at the end of a project, phase, or deliverable to evaluate how things went, and what could be improved.
Randy Slade, Kaiser Permanente Information Technology
If you want a higher quality product in an eXtreme Programming (XP) project, you must be prepared to pay a higher price. We make decisions and compromises based on quality versus cost every day. Extreme programming teams are driven to do their best work, but customers have the right to specify and pay for only the level of quality they require. This presentation explores ways to resolve these two potentially conflicting points of view.
This presentation is about bugs: where they hide, how you find them, and how you tell other people they exist so they can be fixed. Explore the habitats of the most common types of software bugs. Learn how to make bugs more likely to appear and discover ways to present information about the bugs you find to ensure they get fixed. Drawing on real-world examples of bug reports, Elisabeth Hendrickson reveals tips and techniques for capturing the wiliest and most squirmy critters crawling around in your software.
It's difficult to quantify the true state of a test effort. Often, it's measured by quantity of work combined with deadline compliance. But if this is the case, then the true level of quality remains unknown. The Requirements-Based Testing (RBT) process offers a set of metrics that can be utilized throughout the development cycle. These metrics can provide an accurate picture of the test effort at any given time.
The key to accelerating test automation in any project is for a well-rounded, cohesive team to emerge that can marry its business knowledge with its technical expertise. This session is an in-depth case study of the evolution of automated testing at the BNSF Railroad. From record-and-playback to database-driven robust test scripts, this session will take you through each step of the $24 billion corporation's efforts to implement test automation.
What is usability? Why is it important? If these questions wake you in the middle of the night, then this presentation is for you. Cheryl Nesta discusses the relevance of usability testing within the broad framework of quality assurance and appropriate expectations based on its uses and applicability. Explore methodology, process flow, goal identification, and definition. Real-world examples create a hands-on introductory experience.
In this paper, I'll talk about how to focus yourself to do effective testing. I'll cover where to start, what to look for, what and who are your resources. There is a level of understanding you need about the quality goals for a project. I'll give some examples of ways to figure that out without even asking questions. Or, who to ask if you could and then what to do with the information to be
effective in your testing efforts. Some of this is similar to risk based testing, which you can use in a complementary fashion. The way it is different is in its focus on the sponsor’s expectations.
There's a need for standardized, organized hardware and software infrastructure, and for a common framework, in a complex test environment. Gerhard Strobel focuses on the experience of testing diverse products on many different platforms (UNIX, Windows, OS2, z/OS, OS400)-how they differ and how much they have in common. He explains how to configure and profile test machines, then highlights the technical areas where test efficiency can be increased. He also covers methods of execution control.