As part of my on-going series on Agile for Testers – see this month’s article on People and Practices, I wanted to include the data I collected Agile development and testing and give you a chance to view them.
|Have you been trained in Agile Development?|
The fact that more than half of the respondents answered “no” here is troubling in many ways; let’s just stick to the Practices issue. It is clear some of these organizations are calling themselves “agile” with no reality attached. Whether you want to call them “ScrumButts” or refer to them as Lincoln’s 5-legged dog, calling yourself “agile” without implementing practices and training on what this is all about is just not agile! Attempting to be agile without training all the team in the why and how of these practices will fail.
|Since your move to Agile Development, is your team doing:|
|More Unit Testing?||50%|
|Less Unit Testing?||6%|
|The Same Amount of Unit Testing?||28%|
|I have no idea?||16%|
Ideas to take from this are many: That more “unit” testing is happening in 50% of the responding organizations is a good thing! That more “unit” testing is happening at only 50% of the organizations is a problem. More troubling to me is that 16% have no idea! This is un-agile on so many levels — a lack of communication, no transparency, misguided test efforts — a lack of information on test strategy, test effort, test results — and a lack of teamwork!
|Does your team have an enforced definition of done that support an adequate test effort?|
This is encouraging. Hopefully the 30% without a good Done definition are not “ScrumButts” and will be implementing a useful definition of done very soon!
|What percentage of code is being unit tested by developers before it gets released to the test group? (Approximately)?|
I won’t respond again about the No Idea answer, as that was covered above, but it’s important to know that most agile purists recommend 100% unit testing for good reason. If there are problems with releases, integration, missed bugs, and scheduling, look first to increase the percentage of code unit tested!
The overriding result is that the current testing practice is quite diverse! There is no single test practice, no one way to test, and no single preferred developer/tester ratio. Everyone’s situations were different and even some similar situations had very different ideas about their product quality, work success and job satisfaction!