Bloggo back to the blog
G(r)ood testing 24: The need for Agile test strategies-->
While I am writing this blog I am sitting at Schiphol airport. I am waiting for an early flight to London where I will be speaking on the SIGIST autumn conference. At this hour the Airport seems to starting up and I have some time to go through my slides and think about the main message of the keynote I’ll be giving later today.
As I open my Powerpoint and scroll through the slides, I rethink the opening where I explain that there is a lot of change in the way we run our businesses and develop our IT. I will share some of my experiences, and tell how I filled in my role as overall test manager in some of my more recent projects. Aim of this exercise? The way I approach testing in these projects help us (and me) understand how projects have changed with the adoption of Agile, and what testing challenges come with it. They teach us what the fundamentals are of our profession that remain important regardless of these changes.
One obvious change is that testing is no longer the sole responsibility of the testers.
As Michael Sowers states it very well in his September blog: ”In agile, the accountability for the right level of quality delivered at the right time belongs to the collective team. The team should embrace the best skill sets of each contributor and plan for quality and testing at every step of the release and within each sprint.” This being said it might be a good opportunity to access the impact of this. For one thing I see a reduction in overhead and artifacts. I speak with many developers that seriously strive for a lightweight test approach. Although they take quality quite seriously, testers sometimes feel misunderstood when non-testers shortcut the methodic approach of testing. Within Agile we no longer do big upfront design (BUFD) and many tests are written just in time (JIT). This makes it hard to review the test set, and even harder to report on progress. I often act as overall test manager. In this role I want to lay test responsibilities within each team, but also want to ensure that its work is integrated with that of the other teams. In my keynote I will refer a situation where I had to explain to developers that just doing the right tests is not enough. I had to learn them that they needed to provide transparency about progress and dependencies and they needed to explain that they did the right tests as well (tell the testing story, provide the proof).
Al lot of organizations strive for CI/CD and want to shorten their release cycle. Testing needs to speed up accordingly and therefore will become more technical. Automation is key in both speeding up the test execution and reducing dependencies between systems. Stubbing and service virtualization are ways to test integration of a component in context with the other systems without being dependent on its availability. Great technical challenges lie here.
Another shift that I see is that the spread of testing becomes wider. I will not elaborate too much on non-functional testing like UX, Security and Performance, but rather share some experiences I had with acceptance management and embedding the testing in the development process. Especially in scaled agile projects that involve external suppliers, the testing question should not only focus on the technical challenge, but on the whole. What kind of test need to be done, who commits to these tests and how do the tests add up to a common understanding of progress, quality and bottlenecks? And what is needed to accept the solution with confidence.
With a growing emphasis on business value and systems thinking, testing should incorporate business tests also. So rather than testing in the integrated systems, we need to embed the systems in the organization. Organizational Readiness becomes a test topic as soon as we realize that a releasing a minimal viable product only yields business result when the organization can deliver the service, sell the product or support the process.
What do we need in order to make sure that the teams do the right tests, that integration is ensured even when it exceed team and organizational boundaries? How do we ensure that we have eye for the technical challenges but do not forget about the acceptance of the IT and embedding of the solution within operations? I think we should empower teams to do what they do best, respect them for their knowledge. They should be self-organizing and we should not prescribe every test they need to do. But, we need to maximize the synergy of the individual team effort. We need to ensure their tests add to a total package without gabs and we need to manage inter team dependencies. Although a lot has changed in the way we develop our software, some fundamentals remain vital. With so many test items to address at various levels. What are the changes that all individual team activities will mount up efficiently? Quality is not a coincidence, it’s hard work. Therefore there is still is a strong need for an agile test strategy.
The intercom suddenly comes alive: “All passengers for London, we start boarding …” I close my laptop and head for the gate.