Since we launched the Agile Expedition, we’ve seen a huge number of folks taking the time to learn more about Agile development ideas and methods. What we’ve lacked during most of that period is an easy way for you to take your new knowledge and put it to work in TestTrack. Also, as customers begin the process of becoming more agile, they’ve been asking for help and guidance in using TestTrack to support the adoption of those Agile practices.
Continue reading…
Agile
On January 19, I presented the ‘Manager’s Guide to Defining Testing in an Agile Age’ webinar. This is the last post in a three-part series I’ve been doing to highlight the key takeaways from the webinar; get your testers involved early, make your testers first-class participants, and today I’d like to drill down into the third and last area.
Automate testing processes and activities.
In one sense, Agile methodologies were a reaction to the over-tooling of traditional methodologies. Many Agile proponents believe that too much time was being spent operating and collecting data for tools instead of focusing on the actual work to be done.
But automation is essential in many aspects of Agile testing. Automation enables the easy collection and analysis of data that enable testers and other project team members to make decisions about the quality and completeness of work. And testers need to make use of automated defect tracking to make sure a feature is retested when a defect is found, even if the defect is fixed right away.
Share on Technorati . del.icio.us . Digg . Reddit . Slashdot . Facebook . StumbleUpon
Thanks to everyone who joined us for the A Software Manager’s Guide to Defining Testing in an Agile Age webinar. The recording is now available if you missed the training session or want to watch it again. Q&A from the session follows.
It used to be that users, or product management, submitted a set of features and requirements to the development team and waited patiently while development constructed exactly what they asked for. Six months later, when users saw this new application for the first time, they realized that what they asked for wasn’t really what they needed. Something had been lost in the translation from what they needed to what they told development to create, to what development ultimately created. “No problem,” development would say when told the existing software didn’t meet a specific need, “we can change that in the next release.” And six months later, it would indeed be changed!
Share on Technorati . del.icio.us . Digg . Reddit . Slashdot . Facebook . StumbleUponWe’ve all read the horrifying statistics around IT project failure—they fail often and sometimes spectacularly! Yet enterprises must continue to build, deliver, and support applications to meet business opportunities. As an alternative to curling up in the fetal position when faced with this dilemma, Agile methodologies and iterative delivery have evolved to address this very problem. Rapidly delivering a few features at a time makes it possible to break a big project down in to smaller and more manageable pieces. It also enables users to validate the software at each iteration, and allows for mid-course corrections to be easily made in response to changing business needs.
Tester’s Dilemma
Testing has always been a weak link in Agile. Traditionally, testers analyze requirements and determine what and how to test while developers are coding the requirements. With Agile, there are no formal requirements and there is no period of down-time while testers wait for testable functionality. In an Agile environment, testers have learn to work from user stories—brief descriptions of how users envision working with the software—and they need to figure out what and how to test pretty quickly.
Share on Technorati . del.icio.us . Digg . Reddit . Slashdot . Facebook . StumbleUponTransitioning from current development methodologies to Agile can be very difficult for testers. Software managers need to provide the leadership needed for testers to apply their craft in an environment where change is constant. This webinar will explain how both testing and the role of testers change in an Agile development environment, and how managers can help testing teams adapt to those changes and consistently deliver quality software.
Share on Technorati . del.icio.us . Digg . Reddit . Slashdot . Facebook . StumbleUpon
When I’m consulting with a client—usually a large business where bloated, traditional Waterfall-style software development processes are the norm — someone inevitably asks about tracking percent complete. They’re pretty shocked when I tell them that tracking percent complete is an utter waste of time.
Unfortunately, many otherwise good project managers are taught that tracking percent complete on a software development project somehow adds value. Often, tracking percent complete is part of the organization’s “standard” PMO process, making it a mandatory metric for all projects. Many project managers track this metric because they don’t know any better — or they know better but are not able to confront the issue within the organization. Any resistance is usually countered with “we’ve always done it this way.”
I know because I have been managed by these traditional-thinking project managers and have also, in my early years, managed projects this way.
Continue reading…
What does it take to be an Agile Jedi? Seapine’s own Padawan is about to find out.
Katie Hankins is a software engineer on the Surround SCM team, and she’s learning and applying Agile methods as a member of a team developing commercial enterprise software. Come along as Katie, full-time developer and part-time Agile student, embarks on her journey to become an Agile expert.
Share on Technorati . del.icio.us . Digg . Reddit . Slashdot . Facebook . StumbleUponAt the Software Test Professionals conference this week, Kent Beck, the creator of Extreme Programming, gave one of the most eye-opening keynote talks I have heard. It was on agile development, except that it never used the word agile. Instead, he focused on what it would take for an organization to deploy software more quickly. Specifically, he looked at what would have to change in the processes to move from deploying software annually to quarterly, quarterly to monthly, monthly to weekly, weekly to daily, and daily to hourly.
He was speaking to the wrong audience. Actually, it was the right audience, in that a good part of the processes he described as having to change were quality and testing ones, but the audience wasn’t particularly receptive to his message. I suspect it was because he advocated breaking down barriers that most don’t want to see broken down.
Beck noted that one of the primary barriers to increasing the frequency of deployments is the distance that communication has to travel in an organization. The focus of agility is to reduce the distance communication has to travel.
Share on Technorati . del.icio.us . Digg . Reddit . Slashdot . Facebook . StumbleUponIn the Are We There Yet? Doneness Criteria eBook, I talked about how to define Done for your team and how a one size fits all approach is next to impossible given the variation across organizations and projects. However, I did promise some actionable ways of determining what “Done” means for your organization or project.
Share on Technorati . del.icio.us . Digg . Reddit . Slashdot . Facebook . StumbleUpon
