Testing Times from the Credit Crunch

« Obama's CTO | Main | Microsoft gets on to the Cloud with Azure Services Platform »

I had a task flag to take a look at the proceedings from the annual International Conference for Software Process Improvement, ICSPI 2008, but on visiting their site I was pretty amazed to find this message. Due to severe cuts in education and travel budgets across most organizations, the International Conference on Software Process Improvement (ICSPI) 2008, which was scheduled to take place October 20 th -24th , is regretfully being postponed until October, 2009. Yup a casualty of the credit crunch it would seem.

Okay maybe this isn’t one of the biggest events around, but it has been a good ‘working’ event by the people involved in the topic for the people who are involved in the topic, but maybe that’s been its downfall, no big names and publicity just the kind of good feedback and discussions we all feel the need for from time to time. The major reason I was interested was in the ‘how’ software development processes can be improved. It’s part of my own feelings that development tools are improving, but on the other side of the fence smaller, faster, is likely to be the way increasingly, and this, particularly in ‘tough times’ is likely to put pressure on time which all to often means quality suffers.

So if the credit crunch is changing the projects what about the testing side? After all testing tools are expense, often expansive, and their use can be complex, all of which seems to be going in the opposite direction to the trend towards smaller simpler better defined projects where presumably the risks are also better clarified. Sure enough there are some companies out there who have recognised the opportunity with single user testing suites.

Actually the real question that has been occupying my thoughts is if the new generation of ‘services’ as opposed to monolithic applications is the beginning of a real shift to doing development in a different manner. Better tools, smaller and less complex dependencies, etc. all should mean a simplification in the development side. The challenge for testing has always been exactly what do you test, with the traditional robust discussion between the developers and the testers on this topic. But if you shift to Agile Development, and focus on small two week development ‘sprints’ for focussed requirements then the costly time consuming testing phase at the end of a project is considered by many to be cut right back, some even claim all, but avoided.

If I add all these pressures together; credit crunch demanding cost reductions, tougher markets demanding new products and smart services, buying and selling across the Web for better business, internal decision support and collaboration, then it all seems to favour driving experimentation towards changing the development and testing methods away from those that were fundamentally built to handle big enterprise application programmes.

However I am not sure that I am right in this as when I caught sight of a list of the ten skills said to be most recession proof in the UK IT industry it seemed to suggest that the old world was still dominating when it came to skills! The software tester is right up there at number two which suggests that there is a feeling that testing is actually going to be more important, - seems strange if there are less big projects – whilst developers are down at number seven. So who is at number one? Security Professionals! And at number three we have network engineers, so my own view is that testing may be changing even more than just in tune with development methods.

Back to the question; what needs to be tested? Well increasingly it isn’t only the quality of the code; it isn’t even just enough to test for conventional security flaws, no it will need to be checked for support to a wider, and increasing, range of security and standards compliance. Mmm – may be that’s why testing professionals rate a number two position, the demand is still there, but what needs to be tested is changing?

Posted by Andy Mulholland on November 10, 2008 in Methodologies :: Software Engineering | Digg this | Seed Newsvine

TrackBacks

TrackBack URL for this entry: http://www.capgemini.com/cgi-bin/blog/mt-tb.cgi/656

Comments

# on November 10, 2008 10:35 AM, David Chassels said:

Andy
Why do we still need coders and code testers for business logic? This is the old "IT". The title credit crunch should be about just how we found ourselves in such a mess. Even the Queen asks why no one saw this coming. Even before this challenge to the capitalist system questions where being asked about the state of IT. Some suggesting IT should be confined to the history book. Now we have CEO and founder of Forrester Research George Colony making comment about the need to move to focus on Business Technology "BT" to quote him in a recent dialogue
“If we don’t get from IT to BT we’re going to have more disasters like our present mortgage meltdown. Why? Because IT creates impenetrable systems that human beings can’t manage. BT is about human beings back in control"
IT is truly in the spot light and in business it is time for radical change and that means remove the coder for business logic and nurture the real technical skills of the delivery architects. You have raised the BT issue in past blogs now the reality of IT’s failure to deliver suggest the time has come for change as you allude to in your final comments

# on November 10, 2008 1:30 PM, andy mulholland said:

Hi David

I think the term is 'when in a hole stop digging because you are making it worse'. And in the way we continue to develop many systems into something they were never meant to be your comments ring true. The challenge is, as i know that you know fustrating well, that people are going to keep right on doing the thing that they know, and are trained for, unless a serious and deliberate effort is made to break them out of it.

May be tougher budgets will be the lever, may be it will be the business itself demanding reform, and may be it will be in answer to the users taking this into their own hands in implementing new things on new technology.

last two times - 1991 and 2002 - it was a mixture of all three, and i reckon that will happen again this time.
regards
andy

# on November 13, 2008 3:00 PM, Andrew Harmel-Law said:

Hi Andy,

Quick clarification. Testing in an Agile Development does not need to be an impossibility. In fact, many developers relish the closer relationships with BA's and Developers as well as faster feedback that Agile techniques bring. They definately should be a member of an Agile team.

Furthermore, Testing can be integrated into an Agile approach quite simply. Integration and System Testing can be added to a feature's definition of "Done" and more time consuming so the tester becomes the "signoff guy". More involved testing activities (i.e. acceptance testing) can be run in a "sprint after the sprint" model as described by Henrik Kniberg: www.crisp.se/henrik.kniberg/ScrumAndXpFromTheTrenches.pdf

# on November 13, 2008 4:34 PM, andy mulholland said:

Hi Andrew

mmm once again been caught for not making my thoughts clear enough! i believe that properly applied Agile does lead to better code with tests as a part of the process.

however to me there is a bigger picture, what i would call an enterprise approach to what must be tested and how to ensure enterprise scale integrity. my point is that i think as we increase the speed and effectiveness of Agile builds then we may see budget cuts reflected in reducing an enterprise level testing and integrity activity.

so up for the idea that Agile means better and tested if done probably - nervous that this will lead to a reduction in the need for an enterprise level management of the framework for test requirements.