Let's face it: Software testers are constantly in a state of warfare, figuratively speaking. There's a tug of war between resources and the amount of work that needs to be done. We struggle against time. We juggle between finding defects and validating fixes. In short, we are warriors, and it's the high performing testers who are successful in battle. In this article, I will consider Sun Tsu ancient strategies in his book The Art of War and apply them to the realm of the high performing software test engineer. These same fundamental principles define our best means for success on the battle field, in the board room, or in the development labs.
Since the early 90s organizations have searched for ways to accelerate the development and implementation of new business systems. As it turns out, the ability for organizations to rapidly respond to changes in the marketplace, regulatory environment and demand of the customers is a critical competitive advantage. Over the last few years organizations have been experimenting with a new methodology that is thought to provide time savings when it comes to business systems development and implementation. Perhaps the most common methodology being considered is Agile. Agile refers to an approach for software development rather than just a methodology. It is a member of the same class o methodologies as Lean, RUP and Extreme Programming (XP).
Agile. Global. Development.
Think those three words don't go together?
My company, Macadamian Technologies, has been doing Agile global development for a couple of years now. We have permanent offices in Romania and Armenia, and we have long-term deals with developers in two other countries. Most of the projects we're doing now have some kind of global component.
Ah, but you're wondering, "Sure it's global, but how can it be Agile?"
Agile practices emphasize the value of bringing testing forward in the development process, but has anyone ever explained to you how to actually make that happen? Most likely not, at least from my experience. The fact is most teams lack the process and automation needed to get continuous visibility into the ongoing quality of their software releases.
This s the story about how an onsite/offshore team delivered a fixed-bid project using agile practices. The delivery effort was very successful. This article highlights our approach, challenges and successes.
James Bond, Mr. Creosote, and Don Corleone are just some of the personas Bryan Sullivan uses for security vulnerabilities. In this week's column, Bryan pays homage to the one vulnerability that gets the least respect, cross-site scripting (XSS), and calls it the Rodney Dangerfield of vulnerabilities. The problem is that XSS vulnerabilities are nothing to laugh at, and, as Bryan explains, you should start showing this vulnerability some respect before you get slapped by an XSS threat.
Bob Payne speaks to Rick Mugridge about ZeBreve, Fit, and the Agile 2007 conference.
Remember the last time you went grocery shopping without a list and you had your toddler, your mother, or spousal unit with you? Or when you stopped by the beer store and found yourself standing in the chip aisle, dazed and confused by the choices? Did you get what you needed? Did you spend as much money as you expected to? Mary Gorman discusses the value of starting out with clear requirements when shopping for commercial off-the-shelf software.
Teams practicing Agile Software Development value working software over other artifacts. A feature from the release plan is not complete until you can demonstrate it to your customer, ideally in a shippable state. Agile teams strive to have a working system ("potentially shippable") ready at the end ofeach iteration. Thus Release Management should be easy for an idealagile team, as agile teams, in theory, are ready to release at regular ntervals, and the release management aspect is the customer saying "ship it!."
In this article, Jurgen Appelo links science's complexity with agile software development. Jurgen attempts to show why there is no such thing as a best software development method, why managing scope is a too simplistic interpretation of the principle of "embracing change", why corporate standards for processes are a bad thing, and why you will never get things exactly right. The article includes comparisons to biology and other types of complex systems, several little nuggets of wisdom, and some personal experiences involving Jurgen's car.
Recommended Web Seminars
Agile Connection is one of the growing communities of the TechWell network.
|Featuring fresh, insightful stories, TechWell.com is the place to go for what is happening in software development and delivery. Join the conversation now!|