The Latest

As a test professional in waterfall, I was used to getting the code much later and buggier than I expected and being under tremendous pressure to finish my testing before the go-live date hit. Then one day, I found out that there was a better way. Testers could be involved much earlier in the lifecycle, they could participate in requirements and design decisions as they happened, and the code could actually be unit tested before I received it! Heaven? Nope, agile.

The author walks you through the details of actually implementing a continuous quality automation infrastructure. He builds up an example that addresses both the key principles and feedback cycles.

I begin this story by declaring up front that I am not an "Agilist" or process evangelist. I am the senior software development executive in a company responsible for delivering products to the marketplace. Like my peers across industries, I am fundamentally held accountable by my company for consistently delivering business results. Process and methodologies are important in delivering this value, but in the eyes of the company they are secondary to meeting the needs of the business.

Agile is a methodology that is seeing increasingly widespread adoption, and it is easy to understand why - especially if you consider the developer and user view-points. But, for the Test/QA professional an agile approach causes discomfort - In the ideal world they would have a ‘finished' product to verify against a finished specification. To be asked to validate a moving target against a changing backdrop is counterintuitive. It means that the use of technology and automation are much more difficult, and it requires a new approach to testing, in the same way that it does for the users and the developers.

As Agile software development practices mature and move into the mainstream, it is vital that organizations understand how Agile practices can help you deliver higher quality software. The Agile is a methodology for software development that promotes development iterations, open collaboration, and adaptability throughout the project life-cycle. Currently, the measures within many Agile projects focus on the successful delivery of software. We refer to these as process measures. Software is the end product and while these measures examine the progress through the delivery, there are other critical measures that need to be assessed. This collection of measurements we refer to as results measures. One critical measure that is often overlooked is called stability. That being said, the true measure of quality cannot be measured until after the project is done and the software is in production. I am not talking about improving the defect density.

Introducing Scrum can be fun, but can also be quite a challenge. There are numerous hurdles to overcome, new practices to master and problems to solve. In this article, we will present some of the mistakes we have seen made, or made ourselves when introducing Scrum at various companies. In this first article, we will discuss organizational learning, creating an environment of trust, and why Scrim should not be used as a quick fix.

Some things in life, like death and taxes, are a given. Software development teams face their own givens: Project schedules will always change and certain teams will suffer because of these changes. If that's to be expected, then why haven't most managers done anything to save their teams from undue stress and abuse? In this column, Dion Johnson explains that we've got to take care of our teams, or else we'll never see the end of team abuse.