Confirmed users
1,504
edits
QA/Execution/Web Testing/Continuous Deployment: Difference between revisions
Jump to navigation
Jump to search
QA/Execution/Web Testing/Continuous Deployment (view source)
Revision as of 01:35, 13 July 2011
, 13 July 2011→Assessment
| Line 70: | Line 70: | ||
==Assessment== | ==Assessment== | ||
Going forward, measuring quality can no longer be determined purely by numbers of bugs. Two bugs in a release with less than five fixes will give a much higher regression number compared to current releases. Of course if there are more regressions or patches needed, that is one signifier. Measuring the time between bugs filed and bugs resolved/released will become a better measure of quality. Continuous deployment will allow fixes to be released faster than our current process. | |||
We will need to trust the measurements of quality. Right now the new tools to measure and guarantee quality are already in production. They are being improved upon all the time. Data is already being collected and measured. The new tools will only expand on the depth of what can be measured. | |||
The benefits of continuous deployment are numerous. Bugs can be fixed for everyone as soon as the developer fixes them, rather than waiting for the next release date. Response to issues will be faster. Code will be tested at production scale. There will no longer be a dependence on QA or IT to be present for each release. | The benefits of continuous deployment are numerous. Bugs can be fixed for everyone as soon as the developer fixes them, rather than waiting for the next release date. Response to issues will be faster. Code will be tested at production scale. There will no longer be a dependence on QA or IT to be present for each release. | ||
==Resources== | ==Resources== | ||