It is an odd situation to be in. You have a product schedule, and in this schedule, you end up with your feature development work at a certain stage, and then reach a stage where the entire activity involves testing of the product. If you define this in more detail, it is the classical waterfall development model. First there is the requirements phase, followed by the design phase where the requirements are converted into design and architecture followed by the actual coding where the design is converted into code by the development team. This code is then tested by the quality team to detect defects in this code, which follows a process of detecting defects by the testing team, getting them fixed by the development team and re-testing, and so on, till the defects have been detected to a high degree, at which the product is deemed fit to release.
You can have different development methodologies, whether these be Waterfall, iterative or Scrum, or any other. In my experience, as you move towards getting more and more functionality being coded and available to the testing team, there will come a point in the schedule where all the functionality has been built in and the team has the whole product available to do testing. It is hard to visualize a schedule where the product is being built with more and more functionality being built right till the last stages of the release.
As you have more and more parts of the product being available, you need time to do testing of the product with all the pieces connected, all the workflows being available and so on. You can have features being tested part by part as they are being built, but there will always be workflows which are not possible to test until all the pieces have been connected together.
So, in a typical development cycle, you do an estimation of the time needed for the development phase vs. the time needed for testing post development, with a lot of this estimation being done based on historical records and information, and bake this into the schedule. Accordingly, you plan for the phase where the fresh development activity has to come to and end, and plan for getting this done in your schedule.
Once you reach that stage, it means that your team has completed all the development activity for building in the features needed in the product, and post this stage, you will only have testing and defect fixing. Seems fine, right. Unfortunately, it could be that you have done a much better job at code review, unit testing and other such activities, which resulted in your code being of a better quality than normal. What this results in is an embarrassing situation where you defect timeline is actually projected to come to an end before the due date; and this is where the manager asks the question about the team actually allocating too much time for testing and less time for feature development; since with these statistics, it is pretty clear that you could have done more feature work.
You can resolve this, although it is hard to squeeze in a new feature after you have completed testing; instead, you need to spend time reassuring the team and the manager that they have done a perfect job, that it is not a shame if you ended up completing the work before the actual timeline (although you need to incorporate this entire situation for the post-mortem and for future planning). Further, there are always important features that you were not able to plan for the current cycle, so it would make sense to actually get a head start on such features after branching the code.
You can have different development methodologies, whether these be Waterfall, iterative or Scrum, or any other. In my experience, as you move towards getting more and more functionality being coded and available to the testing team, there will come a point in the schedule where all the functionality has been built in and the team has the whole product available to do testing. It is hard to visualize a schedule where the product is being built with more and more functionality being built right till the last stages of the release.
As you have more and more parts of the product being available, you need time to do testing of the product with all the pieces connected, all the workflows being available and so on. You can have features being tested part by part as they are being built, but there will always be workflows which are not possible to test until all the pieces have been connected together.
So, in a typical development cycle, you do an estimation of the time needed for the development phase vs. the time needed for testing post development, with a lot of this estimation being done based on historical records and information, and bake this into the schedule. Accordingly, you plan for the phase where the fresh development activity has to come to and end, and plan for getting this done in your schedule.
Once you reach that stage, it means that your team has completed all the development activity for building in the features needed in the product, and post this stage, you will only have testing and defect fixing. Seems fine, right. Unfortunately, it could be that you have done a much better job at code review, unit testing and other such activities, which resulted in your code being of a better quality than normal. What this results in is an embarrassing situation where you defect timeline is actually projected to come to an end before the due date; and this is where the manager asks the question about the team actually allocating too much time for testing and less time for feature development; since with these statistics, it is pretty clear that you could have done more feature work.
You can resolve this, although it is hard to squeeze in a new feature after you have completed testing; instead, you need to spend time reassuring the team and the manager that they have done a perfect job, that it is not a shame if you ended up completing the work before the actual timeline (although you need to incorporate this entire situation for the post-mortem and for future planning). Further, there are always important features that you were not able to plan for the current cycle, so it would make sense to actually get a head start on such features after branching the code.
No comments:
Post a Comment