There are a few areas to watch out for while pursuing an Incremental or Iterative model. For the purpose of this blog post, here are some of them. These are from experiences using a specific model – Scrum.
Incremental or Iterative models of development such as agile, have a fairly common theme – delivering an integrated, working system earlier in the life-cycle than would be possible when following a sequential model. The catch here being that only a part of the functionality and features would be available in the delivered builds and incremental addition of functions happen in chunks or increments. While having integrated and working systems available for testing early on does seem like a good idea, there are some areas to look out for.
The load on testing tends to increase after the first chunk or increment. The testing team is usually called upon to perform dual roles - help with on-going incremental testing (pair/buddy testing along with development counterparts as part of an agile team) while also ensuring that the entire integrated system is thoroughly tested too. After the first increment, testing team has to ensure that full regression test cycle is executed to test all features and functionality delivered in the previous increments. These regression tests (on the previous increment's deliverable) are executed by the team while also working in parallel to help with the on-going incremental test efforts for new features being developed in the current increment.
Scope for regressions increase. Typically in incremental development projects, the important & usually complex features and functionality are addressed at the start / initial increments. It is important to ensure that these priority functionality are not broken in subsequent increments. Given the nature of incremental development efforts, invasive changes to the code base often times necessitating changes that have wider impact cannot be ruled out and can be expected. In such a scenario, each new increment introduces a fair degree of changed and new code which increases the risk of regression.
Overlap of tasks across increments and bug handling – as discussed in earlier points, while the testing team is busy working on testing the last increment, development and others are working on developing for the current and subsequent increments. There is overlap of activities across increments. One of the challenges here is when testing finds many defects that need to be addressed by development. However, given that development has already begun work on the current increment based on their plans and information available at the start of the current increment, such new bug fix activity tends to get pushed out to subsequent increments (unless the defect is of a stopper nature). Also, work can quickly pile up on the plate of development if testing finds many bugs to be addressed. This would necessitate re-planning and even in some instances having to cut back on some features to accommodate bug fixes. For the testing team, bugs that are not show stoppers but still important, may get addressed much later on in the cycle. The amount of work to be done by the testing team (including verifying the fixes, checking regressions, etc) can easily build up nearing the end of the release cycle and requires active monitoring, planning and control.
Of course, the above are not barriers to adopting an incremental model and can be handled and managed while working closely with all constituents involved in the project or product development and delivery.
Incremental or Iterative models of development such as agile, have a fairly common theme – delivering an integrated, working system earlier in the life-cycle than would be possible when following a sequential model. The catch here being that only a part of the functionality and features would be available in the delivered builds and incremental addition of functions happen in chunks or increments. While having integrated and working systems available for testing early on does seem like a good idea, there are some areas to look out for.
The load on testing tends to increase after the first chunk or increment. The testing team is usually called upon to perform dual roles - help with on-going incremental testing (pair/buddy testing along with development counterparts as part of an agile team) while also ensuring that the entire integrated system is thoroughly tested too. After the first increment, testing team has to ensure that full regression test cycle is executed to test all features and functionality delivered in the previous increments. These regression tests (on the previous increment's deliverable) are executed by the team while also working in parallel to help with the on-going incremental test efforts for new features being developed in the current increment.
Scope for regressions increase. Typically in incremental development projects, the important & usually complex features and functionality are addressed at the start / initial increments. It is important to ensure that these priority functionality are not broken in subsequent increments. Given the nature of incremental development efforts, invasive changes to the code base often times necessitating changes that have wider impact cannot be ruled out and can be expected. In such a scenario, each new increment introduces a fair degree of changed and new code which increases the risk of regression.
Overlap of tasks across increments and bug handling – as discussed in earlier points, while the testing team is busy working on testing the last increment, development and others are working on developing for the current and subsequent increments. There is overlap of activities across increments. One of the challenges here is when testing finds many defects that need to be addressed by development. However, given that development has already begun work on the current increment based on their plans and information available at the start of the current increment, such new bug fix activity tends to get pushed out to subsequent increments (unless the defect is of a stopper nature). Also, work can quickly pile up on the plate of development if testing finds many bugs to be addressed. This would necessitate re-planning and even in some instances having to cut back on some features to accommodate bug fixes. For the testing team, bugs that are not show stoppers but still important, may get addressed much later on in the cycle. The amount of work to be done by the testing team (including verifying the fixes, checking regressions, etc) can easily build up nearing the end of the release cycle and requires active monitoring, planning and control.
Of course, the above are not barriers to adopting an incremental model and can be handled and managed while working closely with all constituents involved in the project or product development and delivery.
***
Liked this entry? Join my community of professional testers to receive fresh updates by email. Use this link to add your email address to the community. Rest assured, I will neither spam nor share your email address with anyone else. Your email id will remain confidential. Subscriptions are handled by Google's FeedBurner service.
