|
|
| |
| MEDIA SPOTLIGHT |
Agile Development Practices 2008 Video
Brian Marick's "Seven Years Later: What the Agile Manifesto Left Out"
Although the Agile Manifesto has helped many organizations change how they build software, the agile movement now suffers from backsliding, overselling, and a resulting backlash. Brian Marick believes that is partly because the manifesto is focused outwardly; it tells the business how the development team will work with it. What it does not talk about is how the team must work within itself and with the code. Watch Brian's presentation to find out whether you're really doing agile or if you are agile in name only. |
|
|
| |
|
|
| |
|
|
| |
|
|
| |
| AGILISM: DEFINING THE MOVEMENT |
User Story
Agility is often described in terms of iterative development. In fact, it's more of an iterative analysis process with the code being written and tested immediately after the requirements are discovered. The heart of this process is the user story, a collection of requirement descriptions, value statements, cost estimates, architecture designs, and test cases—all rolled into one. While at first glance user stories seem simple, they play a key role in all agile methods.
From Introduction to User Stories by Alan Shalloway |
|
|
| |
|
|
| |
| FEATURED WHITE PAPER |
The Seven Habits of Highly Effective Testing Organizations—Redux
In 2001, author and testing expert Lee Copeland wrote an article uncovering the seven habits of highly effective testing teams, essentially a compilation of industry best practices. Eight years later, Lee brings us a look at the habits that have remained, those that have advanced, and the innovations that we should adopt to take testing to a new level and reap greater value from QA efforts. |
|
|
| |
|
|
| |
| CONTENT POINTER |
ScrumBut: Failure to Deliver
by Michele Sliger
In this article, Michele Sliger discusses one of the more common "ScrumBut" practices that, while allowing teams to say "We suck less," isn't really in keeping with intended Scrum practices. This ScrumBut practice is the persistent failure of the team to complete the agreed-upon features in the iteration or sprint. |
|
|
| |
|
|
| |
| BOOK REVIEW |
Collaboration Explained
by Jean Tabaka
Reviewed by Lisa Crispin
We all know that it's not the methodology, tool, or process that makes a project successful. It's the people. Collaboration helps people do their best work and increases the chance of success. That's why the information in this book is so valuable. Once the first section has convinced you of why you need collaboration, the book goes on to explain how to make it happen constructively. The practices and tools in this book will help make any organization's culture one that encourages working together. |
|
|
| |
|
|
| |
| POWERPASS POINTER |
Conference Archive: Agile and Adaptive Project Management: The Declaration of Interdependence
by Alistair Cockburn
Whereas the Agile Software Development Manifesto is a short and sweet list of principles for developers, the Declaration of Interdependence for Agile Project Management is more of a mouthful. The Declaration of Interdependence was written to provide concrete guidance for software projects and projects in general with applicability to general management. In constructing it, a dozen senior consultants, designers, and managers—project, product, and line—validated that it covered their individual core operating frameworks. In this talk, noted software designer, manager, and methodologist Alistair Cockburn, a co-author of both documents, unravels the six rules of operation in the Declaration of Interdependence. |
|
|
| |
|
|
| |
|
|
| |
|
|
| |
|
FEATURED WEB SEMINAR
|
Achieving Full Lifecycle Traceability from Requirements to Code at Boston Scientific
Brought to you by StickyMinds.com and Better Software magazine
Sponsored by IBM
Speaker Greg Sittler will discuss how an integrated systems and software solution can help you build a coherent development environment, decrease productivity costs and redundancy, meet time-to-market goals, and drive quality by enforcing business processes while controlling content changes. Greg will also review a case study about how Boston Scientific optimizes its production test software development with an integrated process and platform for meeting demands within an integrated application lifecycle management suite. Join us Tuesday, June 30, at 1 p.m. ET. |
|
|
| |
|
|
| |
| THE AGILE EXPERIENCE |
One Year Later: Revisiting Johanna Rothman's "Does Exploratory Testing Have a Place on Agile Teams?"
Last summer, StickyMinds.com columnist Johanna Rothman took a look at the value of exploratory testing—often seen on waterfall projects—to agile teams. We've reprinted an excerpt below and invite you to visit the article on StickyMinds.com to discuss your experiences with the use of exploratory testing techniques in agile environments.
It's easy to see how exploratory testing works on waterfall projects. In fact, it makes a ton of sense on waterfall projects to do at least a little exploratory testing before you decide where to focus your efforts, design your tests, or consider any automation. That's because on a waterfall project testers are much more likely to be crunched for time at the end of the project. (For ideas on how to use exploratory testing on a waterfall project where you don't have enough time, see my column, "So Many Tests, So Little Time.")
But does exploratory testing make sense on an agile project? Of course. Yet agile exploratory testing doesn't look the same as it does on a waterfall project. There is less of a need for exploratory testing after the product is created and a greater role for exploratory testing as the team defines and develops the product.
Michael Bolton says, "When people talk about exploratory testing, they often mean the process of test execution. But the three pillars of exploratory testing are test design, test execution, and learning." In waterfall projects, the execution is most visible. But on agile projects, the feedback loop between test design, test execution, and learning is quite short—and agile projects require all three pieces.
On agile teams, there is little role for a manual black box tester who waits for the requirements, the design, or the code and finally tests according to a predefined script. That's because there's no waiting for requirements, design, or code. The product owner "defines" a feature or chunk of a feature, but the definition is more like a promise to keep discussing that feature rather than a firm commitment—"This is what the feature will do."
If the developers are using test-driven development, the tests help define the design. Even if the developers aren't using test-driven development, they tend to work in small chunks—no more than a day or so long—which decreases the waiting time for code.
There is still a role for testers who can turn their keen observations into ways to quickly test an area in depth. But those testers are even more valuable if they can develop tests and testing ideas—both manual and automated—before the feature is completely coded.
Roles for Agile Testers
- Testers can help the whole team work in a test-driven way by:
- Assisting with defining requirements in the form of user stories and generating system-level tests from those requirements. Think of this as a questioning, test-driven approach to development.
- Assisting with modeling the requirements (user stories)— by asking questions—and generating system-level tests from these stories.
- Testers provide information about each chunk, as the developer delivers it. Sometimes that information is confirmation that the code does what the user story says, does not have side effects, and is releasable at the end of each iteration. Sometimes that information is extra information about the product and other paths the testing could take.
- Finally, testers can perform system-level regression testing during an iteration. (To be honest, on well-established agile teams, the developers typically run the low-level regression tests, allowing the testers to do what they do best: explore, question, and learn.) If the organization is new to agile, the testers might run regression system-level testing at the end of the project.
Where Does Exploratory Testing Fit During an Agile Project?
Exploratory testing is helpful when working with the product owner and the project team, trying to define user stories. Imagine you're working on a banking system and want to allow between-account transfers. The developers have a scheme to use checksums to verify the From and To account numbers. You may have heard about the Fossbakk case, an example of insufficient checking for input and confirmation failure. If exploratory testers had been involved at the time of user story definition, testers might have asked, "What happens if we put in a longer account number than the system expects?" Or, during the modeling stage (which I certainly would expect on an agile project with a financial transaction system comprised of databases), an exploratory tester could ask questions such as how many ways can we make the transaction "fail?" Testers who ask questions like that all the time and explore the answers to those questions before the code is written may help the developers write better code. And, they'll have the basis for some great, nasty tests to see what the system really does. The questions lead to the test design, which leads to the test execution, which provides learning for everyone on the project.
Continue reading: Does Exploratory Testing Have a Place on Agile Teams? at StickyMinds.com.
Johanna Rothman is a management consultant and a regular StickyMinds.com and Better Software magazine columnist.
Visit the Iterations Archive to find out what you may have missed in past issues. |
|
|
| |
|
|
| |
|
|
| |
|
|
| |
Iterations is an extension of StickyMinds.com and Better Software magazine—and a reminder that your "online resource for building better software" is just a click away at www.StickyMinds.com |
|
| |
|
|
| |
SUBSCRIBER SERVICES
|
You are receiving this issue of iterations as part of your StickyMinds.com membership, Better Software magazine subscription, or iterations subscription. We hope this publication will be a useful and enjoyable benefit. To ensure optimal receipt of these emails, please add iterations@lists.stickyminds.com to your address book or all messages from @lists.stickyminds.com to your email white list.
SOFTWARE QUALITY ENGINEERING • 330 CORPORATE WAY • STE. 300 • ORANGE PARK, FL 32073 |
|
|
| |
|
|
|
|
|