My (as a tester) definition of agile project and testing in it.
Submitted by Ainars Galvans on Tue, 14/02/2006 - 11:04.
agile
I am not big fan of XP, SCRUM, etc. At least not as silver-bullet. I'm used to Gate process. And still I love projects who are Agile. I define project to be Agile if the project is capable to balance among quality and scope . It is only possible if testing provides continuous evaluation of quality though the project life-cycle. And only if Testing progress is measured in the same terms as development progress.
Not-agile projects just implement all the planned features, test for defects and try to fix as much as they can within given time-frame.
Details
Project is balancing competing needs among schedule, cost, scope and quality. In waterfall schedule and scope is defined at requirements phase. If we assume that quality goal is to pass user acceptance tests which are based on the requirements and according to VV model is created just after the requirements phase, then also the quality is fixed even before coding and even the design is started. No wonder the schedule is the one which is typically extended.
Off-topic. I know IT is typically compared to construction industry. All my argues are applicable to this industry and still they survives. How? I don't know about world-wide but as much as I've seen this industry is typically late on schedule.
So it's time to remember the agile ideas. First of all I refer to agile as the industry movement vector not as the new agile Methods. Iterative development, JUnit tests, adding testability features, exploratory tests, close interactions with business people and much more are practices in a lot of companies even if they don't call themselves agile and don't implement XP, SCRUM, but improve their own practices. Even if they have formal gate process, which is based on waterfall ideas, they say they are prioritizing features, this way the scope may change during the project iteration. They could flag this iteration to be “limited availability” (beta or something) reducing quality requirements. They have found ways to control all items of project: scope and quality as well as schedule and cost.
There are one issue though. While prioritizing features they say we will implement as much as time permit. They balance features. They could at the end of iteration (or close to it) say quality is low, this will not be general available release. What they can't do is to balance BETWEEN features and quality. Well... only few of them can't. Those who could I call to be agile. For me as a tester I believe project to be agile need only to be able to balance among those two project attributes. And this dictates how the testing differs in agile project.
It means testing need to provide continuous evaluation of the quality. I've seen a lot of projects where this end up with creating small number of test cases to be executed extremely frequently. I don't know why, perhaps it is because of luck of understanding of the testing and still it is typical practice that test manager/lead reports those numbers of test cases passed/failed/not executed/not ready. Do you think this is what the project manager wants to know? Project manager wants to forecast how much time/resource he still have to spend to implement the quality: to fix the bugs. It means he want to know how much bugs are there yet. The issue is simple – he want to know not only how much bugs we have detected already but how much we will yet find, including those who are not yet implemented or are hiding. He may drop some feature implementation if the number is high and reallocate resources to bug-fixing. Or he could start negotiating schedule changes.
Not-agile projects just implement all the planned features, test for defects and try to fix as much as they can within given time-frame.
Details
Project is balancing competing needs among schedule, cost, scope and quality. In waterfall schedule and scope is defined at requirements phase. If we assume that quality goal is to pass user acceptance tests which are based on the requirements and according to VV model is created just after the requirements phase, then also the quality is fixed even before coding and even the design is started. No wonder the schedule is the one which is typically extended.
Off-topic. I know IT is typically compared to construction industry. All my argues are applicable to this industry and still they survives. How? I don't know about world-wide but as much as I've seen this industry is typically late on schedule.
So it's time to remember the agile ideas. First of all I refer to agile as the industry movement vector not as the new agile Methods. Iterative development, JUnit tests, adding testability features, exploratory tests, close interactions with business people and much more are practices in a lot of companies even if they don't call themselves agile and don't implement XP, SCRUM, but improve their own practices. Even if they have formal gate process, which is based on waterfall ideas, they say they are prioritizing features, this way the scope may change during the project iteration. They could flag this iteration to be “limited availability” (beta or something) reducing quality requirements. They have found ways to control all items of project: scope and quality as well as schedule and cost.
There are one issue though. While prioritizing features they say we will implement as much as time permit. They balance features. They could at the end of iteration (or close to it) say quality is low, this will not be general available release. What they can't do is to balance BETWEEN features and quality. Well... only few of them can't. Those who could I call to be agile. For me as a tester I believe project to be agile need only to be able to balance among those two project attributes. And this dictates how the testing differs in agile project.
It means testing need to provide continuous evaluation of the quality. I've seen a lot of projects where this end up with creating small number of test cases to be executed extremely frequently. I don't know why, perhaps it is because of luck of understanding of the testing and still it is typical practice that test manager/lead reports those numbers of test cases passed/failed/not executed/not ready. Do you think this is what the project manager wants to know? Project manager wants to forecast how much time/resource he still have to spend to implement the quality: to fix the bugs. It means he want to know how much bugs are there yet. The issue is simple – he want to know not only how much bugs we have detected already but how much we will yet find, including those who are not yet implemented or are hiding. He may drop some feature implementation if the number is high and reallocate resources to bug-fixing. Or he could start negotiating schedule changes.