|
|
Testing the Nth Release Congratulations! Your team is entrusted with testing the next release of an excellent product, one your customers have depended on for years. How do you make sure the fifth, tenth, or even the fiftieth update release is as good or better than the first version? Mature products have their own testing issues, different from those faced with new products. Susan McVey discusses the issues many testers face with legacy systems: what to test and what to trust, dwindling resources, handling known problems, aging test cases, inadequate time to maintain infrastructure, and more. Susan shares the promises and the traps of automated regression testing suites and discusses ways to keep your tests and testware up-to-date and clean. Learn to iterate toward higher quality and keep up the enthusiasm of your team-even when they're testing the Nth release.
- The technical debt that builds up in mature systems
|
Susan McVey, IBM Rational Software
|
|
|
Code Coverage Myths and Realities You've made a commitment to automate unit testing as part of your development process or you are spending precious resources for automated functional testing at higher levels. You may be asking yourself: How good are those tests anyway? Are many tests checking the same thing while large parts of the code go completely untested? Are your tests triggering the exceptions that normally show up only in production? Are your automated tests adequately covering the code, the requirements-both, neither? Andrew discusses the truths and untruths about code coverage and looks at the tools available to gather and report coverage metrics in both the opensource and commercial worlds. He describes the different types of code coverage, their advantages and disadvantages, and how to interpret the results of coverage reports.
- The concept of mutation testing and how it fits into a code coverage strategy
|
Andrew Glover, Vanward Technologies
|
|
|
Better Software Conference 2006: Agile Development and Its Impact on Productivity Agile development projects are different. Sure, they still have high-level business requirements, but they usually lack system descriptions, technical design documents, and system architectures. The projects tend to be smaller than those employing more traditional methods, and much of the testing occurs concurrently with development. The teams tend to be very small and often in one room, more like a group of friends than a typical development team. How do these and other differences affect productivity and the resulting products? Based on his research and personal experiences, David Garmus discusses the differences between Agile and traditional methodologies and offers specific ways to measure these differences to help you decide: Is Agile development right for your next project?
- The quantitative and qualitative differences between Agile and more traditional projects
|
David Garmus, The David Consulting Group
|
|
|
User Stories for Better Software Requirements The technique of expressing requirements as user stories is one of the most broadly applicable techniques introduced by Extreme Programming. In fact, user stories are an effective approach on all time-constrained projects, not just those using Agile methods. Mike Cohn explains how to identify the functionality for a user story and how to write it well. He describes the attributes all good user stories must exhibit and presents guidelines for writing them. Learn to employ user role modeling when gathering a project’s initial stories. Whether you are a developer, tester, manager, or analyst, you can learn to write user stories that will speed up development and help you deliver the systems that users really need.
- Defining a user story and learning how to write one
- Six attributes of all user stories
- Thirteen guidelines for writing better user stories
|
Mike Cohn, Mountain Goat Software
|
|
|
How to Estimate Anything Given the choice between making an estimate of the time and resources to complete a project or getting root canal surgery, most of us would rush to the dentist’s office. We know that the pain of a root canal is short lived ... poor estimates can cause us agony and frustration for months or even years to come. The good news and bad news is that anything can be estimated. However, the quality of the estimate will depend upon the effort invested in the estimate, how thoroughly the thing to be estimated is understood, the quality of relevant assumptions, and finally, luck. An effective process can improve everything but the luck. Join Payson Hall as he presents a practical estimation process that can be applied to estimate anything and then practice applying the process during his presentation.
- What goes into any good estimate
- How to develop a good estimate for complex things
|
Payson Hall, Catalysis Group Inc
|
|
|
Building Traceable UML Models While effective for modeling requirements, analysis, or design of a software system, UML diagrams are typically used in isolation or only for portions of a system. The resulting inconsistencies have the potential to create more confusion than clarity, negating the investment in the modeling process. Explore tips, tricks, and techniques to build a complete, traceable UML model for all aspects of a software application. Thomas Bullinger shares ways to gather behavioral requirements and map them into UML use cases. Learn to map use cases onto sequence or activity diagrams and extract them onto class diagrams. In a recursive process, each of the UML diagrams and associated descriptions is logically related to ensure a complete problem model and a consistent design solution.
- Create self-consistent UML models of requirements behavior and designs
- Manage change in UML models to reflect updates to requirements
|
Thomas Bullinger, ArchSynergy, Ltd.
|
|
|
Essential Software Quality Planning An old-yet still true-saying is "You can't test quality into a software product." By planning for the quality expected in your software, your team and management will focus on the big picture-integrating development methods, the test processes, and the customer and product requirements within the framework of a quality assurance perspective. Starting with the key element of quality planning and its benefits, Tony Raymond explains how to derive quality objectives from requirements using a "just enough" balanced approach. He introduces methods to confirm that the development lifecycle processes are consistent with quality objectives and discusses the relationship of the quality plan to the test plan. Take back examples of quality planning and test planning templates to use in your next project.
- How to define "just enough" quality objectives
|
Tony Raymond, New Harbor Technical Management
|
|
|
Integrating Security into the Development Lifecycle Software security is neither a development problem nor an IT operations problem. Rather, it is a paramount business problem requiring a multidisciplinary approach that minimizes organizational risk when delivering software products. By making a program-level commitment to security, IT organizations will be in the best position to defend their businesses from growing threats. Ryan English explores business management and the process components of defining, designing, instituting, and verifying secure development practices. He describes a broad set of principles that leading companies are adopting to improve the security of their software and outlines an application security program your company can implement. This approach requires a commitment to application security at all levels of management and offers the promise of a mature level of security without undue effect on the overall development process and delivery schedules.
|
Ryan English, SPI Dynamics Inc
|
|
|
Leadership - The Forgotten Element of Agile Development We often hear about the difficulties and failures surrounding Agile methodologies. Articles describe everything from team and execution issues to the inadequacy of Agile methods on large projects and failures in large organizations. The root cause of these issues is often not a flaw in Agile methodologies but rather a lack of Agile leadership. A commonly held belief is that Agile teams are self-motivated and that leadership is almost evil. Quite the opposite is true. To succeed, Agile methodologies demand greater leadership skills at all levels. Learn from Michael Portwood about the differences between traditional and Agile leadership skills. Take away an Agile leadership model for team members, managers, and executives and proven techniques to foster and grow leadership skills development in your Agile organization.
- Why leadership and management are diametrically opposed
|
Michael Portwood, Spectra Intelligent Marketing, Inc
|
|
|
Better Software Conference 2006: Software Production Line Automation Traditional manufacturing employs extensive automation for maximum efficiency and reliability. Manufacturing organizations invest heavily in tooling and infrastructure to automate production lines and reap great cost savings. For certain software applications and technologies, the software development process can be optimized if it is thought of and run like a manufacturing process. With a focused tools group made up of architects, engineers, and technicians, you can build a software product line for your applications. Find out from Thomas Tyler what a software production line looks like and how it supports geographically distributed development teams with highly automated workflows. Learn to implement a concurrent development process with a flexible project management infrastructure that delivers more functionality per unit time.
- The tools and supporting infrastructure of a software production line
|
C. Thomas Tyler, The Go To Group Inc
|
