Comments for RBCS blog http://www.rbcs-us.com/blog.html Fri, 26 Apr 2013 15:01:34 -0400 http://wordpress.org/?v=2.8.6 hourly 1 Comment on Testing Metrics: Useful or Not? by Rex Black http://www.rbcs-us.com/blog/2013/04/23/testing-metrics-useful-or-not/cpage/1.html#comment-33400 Rex Black Fri, 26 Apr 2013 15:01:34 +0000 http://www.rbcs-us.com/blog/2013/04/23/testing-metrics-useful-or-not/#comment-33400 Ken, I totally agree. Something I always say during my discussions about metrics is that project, product, and process metrics must not be mistaken for people metrics. I'd say that many of the "failed/bad" metrics stories I see as a consultant/trainer and/or encounter as a test manager have as their root cause this mistake: misusing metrics to measure people. Ken, I totally agree. Something I always say during my discussions about metrics is that project, product, and process metrics must not be mistaken for people metrics. I’d say that many of the “failed/bad” metrics stories I see as a consultant/trainer and/or encounter as a test manager have as their root cause this mistake: misusing metrics to measure people.

]]> Comment on Testing Metrics: Useful or Not? by Kenneth Katz http://www.rbcs-us.com/blog/2013/04/23/testing-metrics-useful-or-not/cpage/1.html#comment-33398 Kenneth Katz Fri, 26 Apr 2013 14:42:33 +0000 http://www.rbcs-us.com/blog/2013/04/23/testing-metrics-useful-or-not/#comment-33398 Metrics can be useful up to, and not one millimeter beyond, the point where they are used for rewards and punishments. Because any metric can be gamed by people smart enough to develop, test, analyze and manage software, and if the metrics are used for rewards and punishments, they will be gamed to maximize rewards and minimize punishments, rather than move projects forward. Metrics can be useful up to, and not one millimeter beyond, the point where they are used for rewards and punishments. Because any metric can be gamed by people smart enough to develop, test, analyze and manage software, and if the metrics are used for rewards and punishments, they will be gamed to maximize rewards and minimize punishments, rather than move projects forward.

]]> Comment on Risk-based Testing, but Not Enough Stakeholders by Rex Black http://www.rbcs-us.com/blog/2013/02/18/risk-based-testing-but-not-enough-stakeholders/cpage/1.html#comment-29515 Rex Black Sat, 23 Feb 2013 00:58:23 +0000 http://www.rbcs-us.com/blog/2013/02/18/risk-based-testing-but-not-enough-stakeholders/#comment-29515 I'm glad that the recordings are proving useful. Risk-based testing can be used in Agile projects as well; we have helped a few clients get started doing that. You have to adapt the technique so that you do a lightweight quality risk analysis at the start of each sprint. I’m glad that the recordings are proving useful. Risk-based testing can be used in Agile projects as well; we have helped a few clients get started doing that. You have to adapt the technique so that you do a lightweight quality risk analysis at the start of each sprint.

]]> Comment on Risk-based Testing, but Not Enough Stakeholders by Shoshannah http://www.rbcs-us.com/blog/2013/02/18/risk-based-testing-but-not-enough-stakeholders/cpage/1.html#comment-29495 Shoshannah Fri, 22 Feb 2013 12:35:24 +0000 http://www.rbcs-us.com/blog/2013/02/18/risk-based-testing-but-not-enough-stakeholders/#comment-29495 Thank you for your feedback, Rex. I have been listening to more recordings from your library and I am finding them very informative! One thing I did not mention in my communication above, was that although our long term goal is to move toward using agile methodologies, this project was developed using waterfall methodology. Testing was considered the last step of development before shipping the software. Testing more creatively and thoroughly were the primary objectives. By the time we testers became involved, the design and most of the coding was complete. In addition, the risk analysis from the design and programming stakeholders, as well as upper management, were already documented in the specs and included in the design. The customers' requests were already documented as well. Based on my evaluation of this test process, I hope to promote risk analysis, test planning and testing earlier in the development life cycle to promote collaboration of all stakeholders. This will hopefully prevent some of the last minute redesign hurdles, etc. that came about during testing. Thank you for your feedback, Rex. I have been listening to more recordings from your library and I am finding them very informative! One thing I did not mention in my communication above, was that although our long term goal is to move toward using agile methodologies, this project was developed using waterfall methodology. Testing was considered the last step of development before shipping the software. Testing more creatively and thoroughly were the primary objectives. By the time we testers became involved, the design and most of the coding was complete. In addition, the risk analysis from the design and programming stakeholders, as well as upper management, were already documented in the specs and included in the design. The customers’ requests were already documented as well. Based on my evaluation of this test process, I hope to promote risk analysis, test planning and testing earlier in the development life cycle to promote collaboration of all stakeholders. This will hopefully prevent some of the last minute redesign hurdles, etc. that came about during testing.

]]> Comment on Estimation of Review Effort by Danny Faught http://www.rbcs-us.com/blog/2012/10/26/estimation-of-review-effort/cpage/1.html#comment-19034 Danny Faught Fri, 26 Oct 2012 16:07:09 +0000 http://www.rbcs-us.com/blog/2012/10/26/estimation-of-review-effort/#comment-19034 Why not combine task 1 and 2? Then you don't have to explicitly state that your source documentation is expected to have poor quality, until someone asks why the estimate is high. Why not combine task 1 and 2? Then you don’t have to explicitly state that your source documentation is expected to have poor quality, until someone asks why the estimate is high.

]]> Comment on Some Questions, and Answers, on Advanced Software Testing Topics by Amol P http://www.rbcs-us.com/blog/2012/08/10/some-questions-and-answers-on-advanced-software-testing-topics/cpage/1.html#comment-18059 Amol P Thu, 20 Sep 2012 11:32:46 +0000 http://www.rbcs-us.com/blog/2012/08/10/some-questions-and-answers-on-advanced-software-testing-topics/#comment-18059 Thanks Rex for your valuable comments, it would help us.. Thanks Rex for your valuable comments, it would help us..

]]> Comment on Some Questions, and Answers, on Advanced Software Testing Topics by Rex Black http://www.rbcs-us.com/blog/2012/08/10/some-questions-and-answers-on-advanced-software-testing-topics/cpage/1.html#comment-17990 Rex Black Tue, 18 Sep 2012 12:35:19 +0000 http://www.rbcs-us.com/blog/2012/08/10/some-questions-and-answers-on-advanced-software-testing-topics/#comment-17990 Hi Amol. As a practical matter, these terms are used interchangeably in industry. To the extent that there are any differences in meaning, they are defined within individual organizations. For example, some organizations use "smoke test" to refer to automated tests run by the build/continuous integration framework, while "sanity tests" refer to manual tests run by test teams before starting a major cycle of testing. However, I have also seen the situation exactly the reverse. So, call these tests whatever you like, provided you are clear on what they comprise and what they accomplish. Hi Amol. As a practical matter, these terms are used interchangeably in industry. To the extent that there are any differences in meaning, they are defined within individual organizations. For example, some organizations use “smoke test” to refer to automated tests run by the build/continuous integration framework, while “sanity tests” refer to manual tests run by test teams before starting a major cycle of testing. However, I have also seen the situation exactly the reverse. So, call these tests whatever you like, provided you are clear on what they comprise and what they accomplish.

]]> Comment on Some Questions, and Answers, on Advanced Software Testing Topics by Amol P http://www.rbcs-us.com/blog/2012/08/10/some-questions-and-answers-on-advanced-software-testing-topics/cpage/1.html#comment-17988 Amol P Tue, 18 Sep 2012 11:31:43 +0000 http://www.rbcs-us.com/blog/2012/08/10/some-questions-and-answers-on-advanced-software-testing-topics/#comment-17988 Hi Rex, Could you please tell us the difference between Smoke and sanity Testing in details as you have mentioned in you ISTQB foundation level certification book smoke and sanity are same but what i have observed on some internet sites that they have differences, could you please guide us. Thanks, Amol P Hi Rex,

Could you please tell us the difference between Smoke and sanity Testing in details as you have mentioned in you ISTQB foundation level certification book smoke and sanity are same but what i have observed on some internet sites that they have differences, could you please guide us.

Thanks,
Amol P

]]> Comment on Software Testing Evidence by Rex Black http://www.rbcs-us.com/blog/2011/02/27/software-testing-evidence/cpage/1.html#comment-16262 Rex Black Fri, 27 Jul 2012 20:13:00 +0000 http://www.rbcs-us.com/blog/2011/02/27/software-testing-evidence/#comment-16262 Hi Mark-- It seems that this is a common struggle. Short of annotations inserted on the screenshot--as you indicated--I'm not aware of other solutions. Anyone else? Hi Mark–
It seems that this is a common struggle. Short of annotations inserted on the screenshot–as you indicated–I’m not aware of other solutions. Anyone else?

]]> Comment on Software Testing Evidence by Mark E. DeVault http://www.rbcs-us.com/blog/2011/02/27/software-testing-evidence/cpage/1.html#comment-16261 Mark E. DeVault Fri, 27 Jul 2012 19:46:52 +0000 http://www.rbcs-us.com/blog/2011/02/27/software-testing-evidence/#comment-16261 We are struggling with the need for screenshots as well. We are a hospital system implementing new software replacing and expanding legacy systems for multiple hospitals. I great deal of our design and build is new to the organization, and, must be built manually in each testing domain and/or production (when the time comes). We are requiring screenshots that not only document that a test met the expected outcomes, but also that there is an indication on the screenshot on where to look. QA, auditors, and business owners who review the testing to ensure compliance do not necessarily know the exact place to look on what is many times are very busy screenshot to see the evidence. Has anyone found ways to pinpoint the area on the screenshot short of arrows, circles, etc? We are struggling with the need for screenshots as well. We are a hospital system implementing new software replacing and expanding legacy systems for multiple hospitals. I great deal of our design and build is new to the organization, and, must be built manually in each testing domain and/or production (when the time comes). We are requiring screenshots that not only document that a test met the expected outcomes, but also that there is an indication on the screenshot on where to look. QA, auditors, and business owners who review the testing to ensure compliance do not necessarily know the exact place to look on what is many times are very busy screenshot to see the evidence. Has anyone found ways to pinpoint the area on the screenshot short of arrows, circles, etc?

]]>