Automated Unit Testing is a process where developers programmatically test their code using test frameworks such as the XUnit framework. Code is not considered complete unless it is accompanied by a test case. Agile teams have embraced unit testing. Waterfall teams can also do so without disruption to their process.
Introduction
Agile software development teams have reaped significant benefits by adopting “Automated Unit Testing” as a part of the development process. For teams that are considering becoming more agile, adopting “Automated Unit Testing” would be a good start. It can be easily embraced without significant impact on the process. “Automated Unit Testing” is a process where programmers write test cases for their code using testing frameworks such as the XUnit framework. Ideally, the test cases are written first followed by the implementation of the production code. When all the tests pass, the implementation is complete.
Challenges in “Automated Unit Testing”
More than the impact on the process, the challenge is in getting teams to adapt to this process. In waterfall process, development teams typically provide the implementation and throw it over the wall for QA to test. Asking programmers to prove that the code works before handing it over to QA is a significant paradigm shift. Writing tests is also hard – especially if the code has not been written in a testable way. Developers may have to spend as much time writing the test cases as the production code itself. To most developers, this seems like a waste. However, this pays off in terms of producing code with fewer defects.
Better late than never
It’s never too late to write tests. Tests are most effective if they are written at the time the production code is being written. However, you could introduce them even as defects are being fixed for existing code. When a defect is fixed, insist that tests be written for it. This allows for an incremental creation of test suites. Test suites allow for your code to be flexible. Their presence lets you re-factor with confidence.
Conclusion
Automated Unit Tests are a pillar of agile teams. For teams that want to adopt agile practices, this is a great way of adopting one of its pillars without disrupting existing processes. It’s never too late to adopt Automated Unit Testing. Embracing it in Waterfall also sets the stage for adopting the other important aspects of the Agile methodologies.
Saturday, September 05, 2009
Sunday, August 09, 2009
Embrace Upstream Testing in Waterfall
Upstream testing is a process where developers and testers work together from very early in the development cycle - even as features are being built. This is a flavor of an agile development methodology that can be embraced even in a waterfall process.
Introduction
Agile software development teams have reaped significant benefits by adopting the methodology over the waterfall process. However, there are significant challenges in moving from waterfall to agile. Most teams that make the change adopt a home grown hybrid model eventually leading to a complete agile methodology. If you are in a team that is practicing waterfall and you want to be more agile, consider adopting “Upstream Testing” in your current process.
How testing is usually done in waterfall
In ideal waterfall, features are delivered to QA after they are completely built - in one fell swoop. More commonly, features are delivered in interim builds to QA for testing. QA tests the interim build and reports defects on them. These defects are triaged, prioritized and assigned to developers for fixing in future builds. This is usually a slow and expensive process. Often times, the developers have moved on to other features building, sometimes, on the existing defects. Fixing the defect now is more expensive and risky. Additionally, in many situations QA is not able to complete the testing of features developed in the build. As additional builds are delivered, QA is often behind in testing. The later a defect is fixed, the higher the cost. Unfortunately, since the risk of fixing is also higher with the passage of time, many defects are deferred to a later release – which is effectively a “death sentence” for the defect. The reality is that it will never get fixed, resulting in an inferior product to the customer.
Embrace Upstream Testing
What can waterfall organizations to do in the short term to improve the quality of their deliverables? Adopt “Upstream Testing” in your process. “Upstream Testing” is a flavor of agile testing methodology that can be embraced without causing major disruption in existing processes. Very often it can be done without even the involvement of senior management.
In this process, QA works with software development even as features are being iteratively developed. As the developers are checking in code, the QA resources are testing the functionality on daily builds. The daily builds are not formal builds that are handed off to QA with all the bells and whistles. Instead, it is a build that is used by development to test the validity of their integration and check-ins. QA and development work off the same build. The real differentiator in this process is what happens when QA finds an issue. The tester simply reports this to the developer without registering the defect in the corporate defect tracking tool. The developer and tester agree on a fix and it is implemented right away. The tester tests the fix and the developer moves on to other features confident that not only has he unit tested it but that it has even been approved by a tester. When the formal build is done and handed off to QA for intensive and regression testing across many platforms, there are no surprises to QA and quality is already very high.
Note that there aren’t any significant deviations from how development and testing is done. The QA and development teams continue to report to their respective managers. The organization hierarchy is preserved while still injecting agility into the process. Apart from the development and QA teams, hardly any other organization is functionally affected – in contrast to a full agile methodology which has a ripple effect throughout the organization.
Benefits of Upstream Testing
Since the tester and developer are working together, the quality of the deliverable is being monitored continuously – almost on a daily basis. Defects are found and fixed early. It is extremely cost effective to the organization to have this done without going through defect reporting, triages, defect assignment, Change Control Board’s and such ceremonies. Defects that might get deferred are actually fixed – because it is possible to do so. The result is a higher quality product, delivered earlier in a more cost effective manner. The social engineering aspects of “Upstream Testing” cannot be underestimated. The tester gets to understand the complexity of development and the developer begins to appreciate the value of the tester in making the developer look good.
Development and QA start beginning to look like a team working towards a common goal.
Operational Challenges in Upstream Testing
Many organizations are set up functionally. Thus, the QA and development teams report to different directors who may ultimately report to the VP of Engineering. The very nature of this organization sets up different priorities for QA and development. Very often, one of the metrics used to measure the performance of QA teams is the number of defects filed per release of a product. It is not unusual to see colorful graphs of defects found outside the QA director’s office while the development director’s office proudly displays the defects fixed.
In “Upstream Testing” the defects filed are far fewer – because they are caught and fixed informally. The management of QA and development need to arrive at an understanding of a more mature and relevant measure of performance. This can often be challenging and needs good understanding and common goals between development and QA managers.
Conclusion
Upstream Testing is an agile practice that can be fairly easily introduced to teams following waterfall. It is not disruptive and fits in well with waterfall processes. It allows for defects to be caught earlier resulting in cost efficiencies. Apart from higher quality deliverables, the effect of the social engineering it introduces between development and test teams is high. If your team is following a waterfall process and looking to adopt more agile processes, consider “Upstream Testing”. It is an enabler for moving towards full fledged agile methodology in the future, while solving real problems today.
Introduction
Agile software development teams have reaped significant benefits by adopting the methodology over the waterfall process. However, there are significant challenges in moving from waterfall to agile. Most teams that make the change adopt a home grown hybrid model eventually leading to a complete agile methodology. If you are in a team that is practicing waterfall and you want to be more agile, consider adopting “Upstream Testing” in your current process.
How testing is usually done in waterfall
In ideal waterfall, features are delivered to QA after they are completely built - in one fell swoop. More commonly, features are delivered in interim builds to QA for testing. QA tests the interim build and reports defects on them. These defects are triaged, prioritized and assigned to developers for fixing in future builds. This is usually a slow and expensive process. Often times, the developers have moved on to other features building, sometimes, on the existing defects. Fixing the defect now is more expensive and risky. Additionally, in many situations QA is not able to complete the testing of features developed in the build. As additional builds are delivered, QA is often behind in testing. The later a defect is fixed, the higher the cost. Unfortunately, since the risk of fixing is also higher with the passage of time, many defects are deferred to a later release – which is effectively a “death sentence” for the defect. The reality is that it will never get fixed, resulting in an inferior product to the customer.
Embrace Upstream Testing
What can waterfall organizations to do in the short term to improve the quality of their deliverables? Adopt “Upstream Testing” in your process. “Upstream Testing” is a flavor of agile testing methodology that can be embraced without causing major disruption in existing processes. Very often it can be done without even the involvement of senior management.
In this process, QA works with software development even as features are being iteratively developed. As the developers are checking in code, the QA resources are testing the functionality on daily builds. The daily builds are not formal builds that are handed off to QA with all the bells and whistles. Instead, it is a build that is used by development to test the validity of their integration and check-ins. QA and development work off the same build. The real differentiator in this process is what happens when QA finds an issue. The tester simply reports this to the developer without registering the defect in the corporate defect tracking tool. The developer and tester agree on a fix and it is implemented right away. The tester tests the fix and the developer moves on to other features confident that not only has he unit tested it but that it has even been approved by a tester. When the formal build is done and handed off to QA for intensive and regression testing across many platforms, there are no surprises to QA and quality is already very high.
Note that there aren’t any significant deviations from how development and testing is done. The QA and development teams continue to report to their respective managers. The organization hierarchy is preserved while still injecting agility into the process. Apart from the development and QA teams, hardly any other organization is functionally affected – in contrast to a full agile methodology which has a ripple effect throughout the organization.
Benefits of Upstream Testing
Since the tester and developer are working together, the quality of the deliverable is being monitored continuously – almost on a daily basis. Defects are found and fixed early. It is extremely cost effective to the organization to have this done without going through defect reporting, triages, defect assignment, Change Control Board’s and such ceremonies. Defects that might get deferred are actually fixed – because it is possible to do so. The result is a higher quality product, delivered earlier in a more cost effective manner. The social engineering aspects of “Upstream Testing” cannot be underestimated. The tester gets to understand the complexity of development and the developer begins to appreciate the value of the tester in making the developer look good.
Development and QA start beginning to look like a team working towards a common goal.
Operational Challenges in Upstream Testing
Many organizations are set up functionally. Thus, the QA and development teams report to different directors who may ultimately report to the VP of Engineering. The very nature of this organization sets up different priorities for QA and development. Very often, one of the metrics used to measure the performance of QA teams is the number of defects filed per release of a product. It is not unusual to see colorful graphs of defects found outside the QA director’s office while the development director’s office proudly displays the defects fixed.
In “Upstream Testing” the defects filed are far fewer – because they are caught and fixed informally. The management of QA and development need to arrive at an understanding of a more mature and relevant measure of performance. This can often be challenging and needs good understanding and common goals between development and QA managers.
Conclusion
Upstream Testing is an agile practice that can be fairly easily introduced to teams following waterfall. It is not disruptive and fits in well with waterfall processes. It allows for defects to be caught earlier resulting in cost efficiencies. Apart from higher quality deliverables, the effect of the social engineering it introduces between development and test teams is high. If your team is following a waterfall process and looking to adopt more agile processes, consider “Upstream Testing”. It is an enabler for moving towards full fledged agile methodology in the future, while solving real problems today.
Saturday, August 01, 2009
Embrace the daily stand-up in Waterfall
The Daily Stand-up meeting is the heartbeat of Scrum, an Agile methodology. This is a process that can be easily embraced by teams following the waterfall process.
Introduction
Agile software development teams have reaped significant benefits by adopting the Scrum methodology. However, there are significant challenges in moving from a Waterfall process to an Agile process. Most teams that make the change adopt a home grown Hybrid model eventually leading to a complete Agile methodology. It has been argued by many, that a swift change from one process to another is better than a gradual change. While there are merits to the argument, the reality is that most organizations and people take time to embrace change. It is better to take the time to win hearts and minds than to force adoption of a new methodology. Change that is willingly embraced is change that can be sustained.
Let’s say you want to adopt some Agile methodologies in your team that is currently following the waterfall process. What aspect of it should you adopt? My suggestion is to introduce the “Daily Stand-up” in your team. The “Daily Stand-up” is the heartbeat of the Scrum Agile methodology. See here for an explanation of this process:
http://www.mountaingoatsoftware.com/daily-scrum
Ask the team if they are willing to try this out for a couple of weeks. Also choose a time that is most convenient to them. Most teams will be willing to try this out. You can (and I recommend that you should) even offer the following incentives to the team, if it is in your power:
Cancel the weekly status reports
Most programmers dislike writing status reports. They’d rather write code. With the daily stand-up you probably don’t need weekly reports anymore. You are getting the status daily! You can use the information at the daily stand-up to update the project plan and produce a burndown chart to track progress.
See here for description of a burndown chart:
http://www.mountaingoatsoftware.com/release-burndown
Your team members will love you for canceling the weekly status report!
Cancel the status meeting
Most waterfall teams have weekly status meetings that last for an hour or more. Most programmers dislike long meetings. Since you are getting a daily update, you probably don’t need this meeting anymore. Cancel it.
Your team members will love you for canceling the weekly status meeting!
What’s the gain from the daily Stand-up?
As a Project Manager you have a daily update on the progress. This is better than the weekly update from the original status meetings. You have information early that you can act upon. There is less formality in a stand-up – programmers tend to like that. Information exchanged in a stand-up often results in offline warm & fuzzy communication.
Conclusion
The daily stand-up contributes heavily to the success of an Agile methodology such as Scrum. If the 80/20 rule were to be applied to Scrum, the daily stand-up would show up on the “20” side. It can be easily incorporated into the Waterfall process with all the resulting benefits. Embracing it in Waterfall also sets the stage for adopting the other important aspects of the Scrum Agile methodology.
Introduction
Agile software development teams have reaped significant benefits by adopting the Scrum methodology. However, there are significant challenges in moving from a Waterfall process to an Agile process. Most teams that make the change adopt a home grown Hybrid model eventually leading to a complete Agile methodology. It has been argued by many, that a swift change from one process to another is better than a gradual change. While there are merits to the argument, the reality is that most organizations and people take time to embrace change. It is better to take the time to win hearts and minds than to force adoption of a new methodology. Change that is willingly embraced is change that can be sustained.
Let’s say you want to adopt some Agile methodologies in your team that is currently following the waterfall process. What aspect of it should you adopt? My suggestion is to introduce the “Daily Stand-up” in your team. The “Daily Stand-up” is the heartbeat of the Scrum Agile methodology. See here for an explanation of this process:
http://www.mountaingoatsoftware.com/daily-scrum
Ask the team if they are willing to try this out for a couple of weeks. Also choose a time that is most convenient to them. Most teams will be willing to try this out. You can (and I recommend that you should) even offer the following incentives to the team, if it is in your power:
Cancel the weekly status reports
Most programmers dislike writing status reports. They’d rather write code. With the daily stand-up you probably don’t need weekly reports anymore. You are getting the status daily! You can use the information at the daily stand-up to update the project plan and produce a burndown chart to track progress.
See here for description of a burndown chart:
http://www.mountaingoatsoftware.com/release-burndown
Your team members will love you for canceling the weekly status report!
Cancel the status meeting
Most waterfall teams have weekly status meetings that last for an hour or more. Most programmers dislike long meetings. Since you are getting a daily update, you probably don’t need this meeting anymore. Cancel it.
Your team members will love you for canceling the weekly status meeting!
What’s the gain from the daily Stand-up?
As a Project Manager you have a daily update on the progress. This is better than the weekly update from the original status meetings. You have information early that you can act upon. There is less formality in a stand-up – programmers tend to like that. Information exchanged in a stand-up often results in offline warm & fuzzy communication.
Conclusion
The daily stand-up contributes heavily to the success of an Agile methodology such as Scrum. If the 80/20 rule were to be applied to Scrum, the daily stand-up would show up on the “20” side. It can be easily incorporated into the Waterfall process with all the resulting benefits. Embracing it in Waterfall also sets the stage for adopting the other important aspects of the Scrum Agile methodology.
Subscribe to:
Posts (Atom)