|
|
Agile Process Improvement and the Evolution toward Software Factories The concept of software factories is becoming a hot topic in software engineering circles. So, how can the factory model fit with Agile development practices? Damon Carr makes the case that Agile development is a stepping stone-not an alternative-to software factories. This is not the dreary vision of mindless workers in a factory. Instead, think of highly skilled individuals working with multi-million dollar machinery to develop systems. Even if you are not considering the factory model, Damon offers new practices that can reduce overall Agile development costs by as much as 40 percent. These include explicit refactoring to design patterns in your iterations, quantitative risk management, metrics for understanding the health of your project, and a new approach to team structure.
|
Damon Carr, AGILEFACTOR
|
|
|
Better Software Conference 2005: Software Production Line Automation with Concurrent Development In some contexts, the software development process can be optimized when it is thought of-and run-like a highly automated manufacturing production line. Rather than producing many identical widgets like a manufacturing plant, software organizations produce many programming changes. These changes may not be identical like manufactured widgets, but programming changes can start looking a lot like widgets when you look at the big picture. In this session, Tom Tyler describes how to bring the processes and benefits normally associated with manufacturing to software development-efficiency, reliability, and extensive automation. Manufacturing organizations invest heavily in tooling and infrastructure to automate production lines, and they reap great rewards in efficiency.
|
C Thomas Tyler, The Go To Group Inc
|
|
|
Lipstick on a Pig - How Illusion Leads to Crisis in Real World Projects Change, ambiguity, and risk are key issues whether you are running a software project, managing a development team, or leading an entire organization. We learn it over and over again. It's not a matter of "if" change will happen-it's a matter of "when." When a crisis inevitably arrives, how do you respond? As Jerry Weinberg observed in The Secrets of Consulting, "It may look like a crisis, but it's only the end of an illusion." Andy Kaufman looks at key project illusions that threaten success as we lead projects and people in the realm of software development. Whether you're a project team member or a senior executive, Andy provides practical tips you can immediately apply in your organization.
|
Andy Kaufman, Institute for Leadership Excellence and Development
|
|
|
Agile QA - An Oxymoron? Your software development group is adopting Agile practices. Documentation and processes now are lightweight. There are more unit tests, and all are automated. The software changes quickly with new releases every one to two weeks. What's happening with QA? Quality Assurance groups are typically accustomed to more heavyweight processes in which they spend a third or more of their time documenting tests and tracking results. QA groups that automate user interface tests have difficulty keeping up with the rapid changes inherent in an Agile environment. So, is there a need for Agile QA? Based on her experiences on Agile projects and the experiences others have shared with her, Elisabeth Hendrickson shows how QA teams can respond by becoming more Agile themselves and learning new ways to support the team and the users when the development team moves to an Agile process.
|
Elisabeth Hendrickson, Quality Tree Software, Inc.
|
|
|
The Return on Investment for Finding Defects in Test For testers, finding defects is a way of life. However, we usually don't reflect on what an undiscovered defect can cost a business or how much it costs to find defects late in development. Geoff Horne seeks to put real costs on both of these situations and looks at practical ways to reduce the costs of not finding defects. With real-life case studies that you can use to justify the need for more testing, Geoff provides simple measures and statistics to calculate whether your allocation of testing dollars is too high, too low, or just right. Learn to show how testing can actually save money and how to get the best return for your testing dollar. After all, stock market investors assess their options based on risk and potential return. Why should testing be any different?
|
Geoff Horne, iSQA
|
|
|
Classic Mistakes in Testing: Revisited Some common testing practices seem appealing ... but rarely seem to actually work. Yet software development organizations choose them again and again. Project behind schedule? Just shorten the testing phase! Testers pointing out too many problems with the requirements? Kick the testers out of the room! Many of the software testing gurus suggest adding new "best practices" to the test process. Matt Heusser suggests that test process improvement should start by eliminating worst practices instead of adding extra work through new practices. Matt recounts the existing body of classic mistakes offered by Brian Marick and Steve McConnell. Then he offers a new wrinkle: Mistakes often come from a specific root cause such as short-term thinking. Instead of battling over the specific mistake, teams are better off correcting that root cause.
|
Matthew Heusser, Priority Health
|
|
|
Agile Software Development: The Home of 31 Flavors You've heard of eXtreme Programming (XP) and perhaps Scrum. How about Crystal Clear, Adaptive Software Development, Dynamic Systems Development Method, Rational Unified Process for Agile Development, and Feature Driven Development? These are some of the many variations of Agile development methods. Join Jeff McKenna as he explores the many flavors of Agile development methods and explains the similarities and differences. Find out what aspects of Agile development can help your organization’s development team in its particular environment. If you are considering Agile development and need to decide in which direction to go, this session is for you. Although a one-hour session cannot provide all the information you will need, you can explore what is common-the philosophy, the values, the characteristics-and what is different-the methods, the coverage, the costs-about different Agile approaches.
|
Jeff McKenna, Agile Action
|
|
|
Web Services API Testing Traditionally, test engineers have had some type of a visual user interface for testing client/server and Web applications. Web services, on the other hand, are completely without a user interface, providing only an application program interface (API). A Web service does not display a visual output for testing. Although this fact makes manual testing very difficult, Web services are ideal candidates for automated testing. As a result, some programming skills are almost certainly needed for testers
who test Web services. What about testers with less technical skills? Learn about the challenges Papa Acquah faced with Web services testing: WSDL validation, unit testing, functional testing, client side testing, and server testing. Find out how he used a test harness as well as existing commercial testing tools to accomplish his testing needs.
|
Papa Acquah, LexisNexis
|
|
|
Peanuts and Crackerjacks: What Baseball Taught Me about Metrics Because people can easily relate to a familiar paradigm, analogies are an excellent way to communicate complex data. Rob Sabourin uses baseball as an analogy to set up a series of status reports to manage test projects, share results with stakeholders, and measure test effectiveness. For
test status, different audiences-test engineers, test leads and managers, development managers, customers, and senior management-need different information, different levels of detail, and different ways of looking at data. So, what "stats" would you put on the back of Testing Bubble Gum
|
Robert Sabourin, AmiBug.com Inc
|
|
|
Face-off: Stuctured Testing vs. Exploratory Testing and Error Guessing Exploratory testing and error guessing are valuable functional testing techniques. Like all other methods, though, they have limitations partly because they are based on the knowledge, experience, and intuition of the test engineer. If you primarily use unstructured approaches for testing, you risk wasting effort on redundant testing, testing in non-critical areas, and under-testing critical areas-all of which can lead to missed bugs or finding defects later in the cycle. BJ Rollison uses two case
studies to demonstrate the limits of unstructured testing and how fundamental test design techniques and gray box test design can improve the effectiveness of your tests. You'll correctly prioritize critical areas and uncover serious issues earlier and with less effort. The first case tests Weinberg's triangle algorithm from the design requirements and a C# implementation. The second
|
William Rollison, Microsoft Corporation
|
