We have thus far talked about quite concrete steps toward making quality a first-class citizen of the modern agile software development setting. Those will get us 80% there. But, as in any other process, the last 20% will require 80% of the total time, effort, and experience.

In the previous articles, we talked a lot about the increased technical demands on the Quality Assurance engineer when transitioning to a modern agile setting. These technical considerations are quite effective at paving the road, gaining access to all relevant forums. To reach the goal of becoming a first-class citizen, however, quality needs to be everywhere. This takes a lot of hard work and persistence. Team composition is also particularly important. Decent quality levels can only be achieved if the responsibility is shared.

When talking about transitioning from more traditional ways of testing, we tend to downplay the impact on the skills required from a Quality Assurance engineer. The fundamentals of test case design are, of course, the same. All the same methods applied when designing test cases, such as boundary value analysis, equivalence partitioning, etc., are still valid. However, the way of identifying the input to these methods is different. So is the implementation as automation is crucial. And this is where the technical demands often increase.

“Going Agile” is not just about organizing teams and learning Scrumish frameworks. Being Agile is about adopting to a specific mindset, enabling us to follow the constant and rapid flow of changes. Especially important tools supporting this mindset are continuous integration and continuous deployment. To be able to integrate with confidence and deploy with managed risks, having a quality focused approach is essential.

Looking back over the years, we can see that projects tend to use test efforts as Quality Insurance, rather than a part of the Quality Assurance efforts. Having well-designed test cases exercising relevant functionality from different perspectives are, of course, fundamental. If done right, it is probably the best way to determine if deliverables are designed to specification. This cannot, however, be viewed as an insurance policy put on the development process against any errors introduced along the way.