What a strange summer this has been! From Boston to London to Paris to Turin the weather has offered weekly and even daily reversals with continuous change from sun to rain, from hot and dump to cool and crisp. I missed a nice spring season.
Even today, from 35-38 degree Celsius (95-100 Fahrenheit) we just went to 22 Celsius (71 Fahrenheit) with a perfect storm! A continuous climate and sudden change, which is quite unusual in some of these countries. Certainly it is where the Azores Anticlone usually dominates from mid-late June to mid-late August offering a stable summer. How many times have you had to change plans because you discover weather is about to change!?
You might think what does this have to do with your AD&D blogging ?..It does, it’s about change. I am wondering if getting used in our daily lives to unexpected conditions and having to handle continuous change favours a mind-set where change is just something we have to deal with and not fight. A new mind-set very much needed given the change we see ahead in how we develop, test and deploy software!
My focus in this blog is about testing, although, the first change we need to get used to is that we can’t talk any longer about testing in an isolated fashion.! Testing is getting more and more interconnected in a continuous feedback loop with development and deployment (see my colleagues report Kurt Bittner on continuous delivery; I could not agree more with what Kurt says there!).
But as promised in part 1, here is the link to the latest research I just published around Agile testing “Navigating the landscape of Agile testing tools”. In the report you will find more focus on the changes I see happening to Quality and Testing.
The over 20 vendors and clients interviewed for that research add more “crunch” to why the testing centre of excellence (TCoE) as we know it can’t work going forward (especially when developing modern applications, with mobile, cloud, and analytics). Here are some of the points I make:
- Remote division of labour between those who develop and those who test slows test cycles: manual hand over creates opportunity for mistakes and more fixing, creating artefacts for the only scope of communication among people is a waste.
- Large volumes of manual test activities slow down delivery of agile teams: Test professionals develop test cases that cover as much functionality as possible, but that makes the velocity problem worse. There’s no way around the fact that manual testing is slow and time time-consuming, and eats up a lot of resources-intensive. Only more automation can fix that problem.
- Teams build up too much technical debt. One sure-fire killer of on on-time delivery is finding out late in the development cycle that your application has major quality problems late in the development cycle. Late discovery of defects lead to high rates of rework and waste.
- TCoEs don’t integrate well with modern continuous delivery practices. Segregating testers from developers makes it hard to integrate their work into a continuous delivery pipeline. Fast Fast-moving teams don’t build code and then hand it off to a testing organization; they build code, deploy the application, execute it, and immediately observe the results.
Testing is the crucial spot in the world of “continuous” and of more “automation”. If you’ve promised shorter cycles and faster speed to your business it cannot come only from some Agile PM introduction alone, you need to make your testing more agile, automate the downstream delivery and deployment and make sure tools integrate and facilitate the “continuity”. Continuous development, integration, testing and delivery is going to complete what you’ve started with your Agile journey (Link Holistic change), but your test bed to get there will be how you test.
The huge change of testing has an impact on all of the testing tools categories: from test management tools, to functional and non-functional automation testing, to performance and load testing, to security and test data management tools and finally to the new comers’ services virtualization for software testing tools. More than ever is there a need for a constant flow of information among BAs, developers and testers. As testing shifts more in the hands of developers, vendors need to adapt tools that easily plug into the developers integrated development environments (IDEs), while QA and other software professionals prefer tools that offer a higher level of abstraction and are easy to use. The pressure on tool vendors is to emphasize qualities like collaboration/communication, continuous, automation, simplicity and seamless integration.
What are you doing about your testing strategy? Are you feeling the need to turn your TCoE into a practice centre of excellence with fewer manual testers? Do you see a change in the tool strategy as a consequence? Or just a change in the way you use you’re testing tools?
I am interested to hear more...
Posted by Diego Lo Giudice