|
|
Multi-level Testing in Agile Development Before they could begin automated testing, test teams used to wait on the sidelines for developers to produce a stable user interface. Not anymore. Agile development environments and component-based applications challenge testers to contribute value earlier and continuously throughout development. Although most agile testers currently focus on unit and integration testing, they also need to test the application’s business and service layers-all the way to the system level. Roi Carmel guides you step-by-step through these stages, describing which practice-GUI or non-GUI automated testing-is the right choice and why. The incorrect choice can lead to iteration delays, lower team productivity, and additional problems.
|
Roi Carmel, Hewlett-Packard
|
|
|
Debunking Agile Testing Myths What do the Agile Manifesto and various agile development lifecycle implementations really mean for the testing profession? Extremists say they mean “no testers”; others believe it’s just “business as usual” for testers. As a test manager who has been around the block a few times, Geoff Horne has participated in countless test projects, both agile and traditional. Some of his traditional thinking about testing was turned on its ear and challenged by the key precepts of agile development. He’s discovered that traditional projects can achieve many benefits of the agile testing approach. In this revealing session, Geoff identifies and dispels the myths surrounding agile testing and demonstrates how traditional and agile methods can co-exist within a single project. For testers not versed in agile, Geoff offers suggestions for being prepared to work on an agile project when the opportunity arises.
|
Geoff Horne, iSQA
|
|
|
Requirements Based Testing on Agile Projects If your agile project requires documented test case specifications and automated regression testing, this session is for you. Cause-effect graphing-a technique for modeling requirements to confirm that they are consistent, complete, and accurate-can be a valuable tool for testers within agile environments. Whether the source material is story cards, use cases, or lightly documented discussions, you can use cause-effect graphing to confirm user requirements and automatically generate robust test cases. Dick Bender explains how to deal with short delivery times, rapid iterations, and the way requirements are documented and communicated on agile projects. By updating the cause-effect graphic models from sprint to sprint as requirements emerge, you can immediately regenerate the related test cases. This approach is far more workable than attempting to maintain the test specifications manually.
|
Richard Bender, Bender RBT, Inc.
|
|
|
Agile Testing: Facing the Challenges Beyond the Easy Contexts Don't let anyone tell you otherwise-doing testing well on agile teams is hard work! First, you have to get management over the misconception that you don't need specialist testers within agile teams. Next, you have to integrate testers with the developers and provide holistic, high quality results. Those are just the easy challenges you face. Then, comes the hard part! Bob Galen explores more difficult agile testing contexts-how to attack a total lack of test automation, how to remain agile in highly regulated environments, how to serve your PMO or Testing COE while remaining agile, how to organize testing when your agile team is globally dispersed, how to blend traditional testing processes with their agile counterparts, and more. If you're in a difficult testing context within an agile development environment, come and join the conversation. You'll find examples and options, but no silver bullets. Remember-it's HARD!
|
Bob Galen, iContact
|
|
|
Refactoring: What You Need to Do It Right As certain as evolving requirements lead to code changes, code changes lead to code degradation. Therefore, code refactoring is critical to the long-term viability of all software products. Kevin Sawicki shares tips and tricks for refactoring to help developers identify code that needs refactoring, preserve the correct code history during refactoring sessions, and ensure that appropriate unit tests cover the refactored code. Kevin demonstrates the Eclipse open-source frameworks and Java-based tools, including EMMA for code coverage analysis and JUnit for unit testing. These tools not only make code refactoring less painful, they also empower developers to constantly improve their code through relentless refactoring. Kevin outlines a step-by-step process to find refactoring candidates, perform the refactorings in an isolated code branch, and collaborate with other developers to review the refactored code.
|
Kevin Sawicki, Perforce Software
|
|
|
Security Guidelines for Agile Development Some security experts would have you believe that it is "impossible" to implement secure development practices using agile development methodologies. Admittedly, the use of agile does pose some challenges to traditional security development lifecycle (SDL) processes-challenges such as meteorically short release cycles, infinitely long product lifetimes as in the case of cloud applications, and a general You-Ain't-Gonna-Need-It planning mentality within agile. Despite these challenges, securing systems developed in agile projects is possible. SDL and agile can work well together. In many ways, they can actually work better together than do traditional development approaches. Bryan Sullivan details the process changes that the Microsoft SDL team made to improve the applicability of the SDL to agile development methodologies.
|
Bryan Sullivan, Microsoft
|
|
|
End-to-End Agile Planning: Oxymoron or Powerful Release Planning Method? It's a very common pattern. Agile methods don't seem to specify much in the way of preparation or strategies for project planning-so teams simply dive-in and start iterating toward a solution to their business problems. In some contexts, such as small-scale simple projects, this works just fine. However, what if your project is more complex? How do you determine a budget when you have a distributed or larger-scale project and no real requirements? In many real-world contexts, establishing a consistent and thoughtful baseline project plan can be an incredibly powerful contributor to your ultimate success. The good news is that you can do end-to-end planning and still "be agile." Bob Galen shows how to use the Crystal Clear's Blitz Planning approach, user story mapping, and other end-to-end planning techniques to establish a "proper beginning" and define a holistic map for your agile projects.
|
Bob Galen, iContact
|
|
|
Risk Identification, Analysis, and Mitigation in Agile Environments Although risk identification, analysis, and mitigation are critically important parts of any software project effort, agile projects require non-traditional techniques that are much quicker and easier to use than classical risk techniques. James McCaffrey focuses-not on theory-but on realistic risk analysis methods agile teams can readily implement with lightweight tools. James explains and demonstrates how you can employ taxonomy and storyboarding methods to recognize project meta-risks and identify product risks throughout the development lifecycle. Using “central moment” and “PERIL” techniques, you'll learn to analyze these risks and develop management and mitigation strategies dynamically, while the project is underway.
|
James McCaffrey, Volt VTE
|
|
|
The Battle of Scrum vs. Kanban Over the past ten years, Scrum has become the leading project management approach in agile development. Now, there’s a new kid on the block-Kanban. Devotees of each approach emphasize their fundamental differences, debating pros and cons of one versus the other. Recognizing that their principles and practices are not utterly dissimilar, Jean Tabaka leads an open discussion about Scrum and Kanban approaches. For instance, both approaches create high project visibility and work in smaller increments than traditional development. And yet, each approach emphasizes its principles that influence which practices and measures guide the team and its organization. Scrum uses a Burndown Chart for visibility on progress; Kanban tracks work-in-process (WIP) as one of its tools for progress visibility. Is one better than the other? Or more importantly, when is one better than the other?
|
Jean Tabaka, Rally Software Development
|
|
|
Working with Globally Distributed Agile Teams Miscommunications, misunderstandings, and interpersonal conflicts often thrive in the typical distributed team. Distributed agile teams, especially globally distributed teams, are more likely to face these issues than those employing traditional development methods. Global agile teams are not only geographically dispersed, but they're also separated by time zones, language barriers, nationality, and organizational culture. Ken Pugh describes the challenges he’s seen globally distributed agile teams face and shares ways you can anticipate and address these challenges. He discusses the different tokens teams can use in their communication and how to create a common understanding among all team members. Ken emphasizes building trust and developing a sense of “us” among the distributed team members.
|
Ken Pugh, Net Objectives
|
