Comments on: Do testers goldplate too? http://pmstudent.com/do-testers-goldplate-too/ Helping new and aspiring project managers reach their career goals! Wed, 08 Feb 2012 14:16:34 +0000 hourly 1 http://wordpress.org/?v=3.3.1 By: Phil Ruse http://pmstudent.com/do-testers-goldplate-too/#comment-21128 Phil Ruse Thu, 11 Feb 2010 10:17:25 +0000 http://pmstudent.com/?p=3956#comment-21128 This is a good topic. I'd suggest that a good developer will take any "defect" raised, compare it to the requirements and then log/update accordingly. I've always liked the idea of testing beyond the plan (because no plan is perfect) but I can see the danger that a developer takes any "defect" at face value and proceeds to a "fix" without referencing the requirements! This is a good topic. I’d suggest that a good developer will take any “defect” raised, compare it to the requirements and then log/update accordingly. I’ve always liked the idea of testing beyond the plan (because no plan is perfect) but I can see the danger that a developer takes any “defect” at face value and proceeds to a “fix” without referencing the requirements!

]]> By: Phil Ruse http://pmstudent.com/do-testers-goldplate-too/#comment-25554 Phil Ruse Thu, 11 Feb 2010 10:17:00 +0000 http://pmstudent.com/?p=3956#comment-25554 This is a good topic. I'd suggest that a good developer will take any "defect" raised, compare it to the requirements and then log/update accordingly. I've always liked the idea of testing beyond the plan (because no plan is perfect) but I can see the danger that a developer takes any "defect" at face value and proceeds to a "fix" without referencing the requirements! This is a good topic. I’d suggest that a good developer will take any “defect” raised, compare it to the requirements and then log/update accordingly. I’ve always liked the idea of testing beyond the plan (because no plan is perfect) but I can see the danger that a developer takes any “defect” at face value and proceeds to a “fix” without referencing the requirements!

]]> By: Iain http://pmstudent.com/do-testers-goldplate-too/#comment-21115 Iain Wed, 10 Feb 2010 22:01:40 +0000 http://pmstudent.com/?p=3956#comment-21115 Jen, Good article, and raises some important points. There as an important tension here: As testers we SHOULD go beyond the verification of written requirements and into the realm of validation: Can the solution fulfill its underlying need? We SHOULD be raising any issues that prevent the solution from doing so, or that limit its value to any stakeholder who counts. BUT we must accept that our role is to provide information about product quality. It is the PMs role to manage scope and balance out time, cost and quality - and to negotiate the inevitable compromises with the customer. An effective bug management process is essential in doing so - when it comes to sorting out the must fixes from the enhancements and the can-do-laters. Jen,

Good article, and raises some important points.

There as an important tension here: As testers we SHOULD go beyond the verification of written requirements and into the realm of validation: Can the solution fulfill its underlying need? We SHOULD be raising any issues that prevent the solution from doing so, or that limit its value to any stakeholder who counts.

BUT we must accept that our role is to provide information about product quality. It is the PMs role to manage scope and balance out time, cost and quality – and to negotiate the inevitable compromises with the customer.

An effective bug management process is essential in doing so – when it comes to sorting out the must fixes from the enhancements and the can-do-laters.

]]> By: Iain http://pmstudent.com/do-testers-goldplate-too/#comment-25553 Iain Wed, 10 Feb 2010 22:01:00 +0000 http://pmstudent.com/?p=3956#comment-25553 Jen, Good article, and raises some important points. There as an important tension here: As testers we SHOULD go beyond the verification of written requirements and into the realm of validation: Can the solution fulfill its underlying need? We SHOULD be raising any issues that prevent the solution from doing so, or that limit its value to any stakeholder who counts. BUT we must accept that our role is to provide information about product quality. It is the PMs role to manage scope and balance out time, cost and quality - and to negotiate the inevitable compromises with the customer. An effective bug management process is essential in doing so - when it comes to sorting out the must fixes from the enhancements and the can-do-laters. Jen,

Good article, and raises some important points.

There as an important tension here: As testers we SHOULD go beyond the verification of written requirements and into the realm of validation: Can the solution fulfill its underlying need? We SHOULD be raising any issues that prevent the solution from doing so, or that limit its value to any stakeholder who counts.

BUT we must accept that our role is to provide information about product quality. It is the PMs role to manage scope and balance out time, cost and quality – and to negotiate the inevitable compromises with the customer.

An effective bug management process is essential in doing so – when it comes to sorting out the must fixes from the enhancements and the can-do-laters.

]]> By: Pawel Brodzinski http://pmstudent.com/do-testers-goldplate-too/#comment-21114 Pawel Brodzinski Wed, 10 Feb 2010 20:50:59 +0000 http://pmstudent.com/?p=3956#comment-21114 In short: I disagree. You don't want to turn your testers into machines blindly following specs/requirements. I turned my long response into blog post: <a href="http://blog.brodzinski.com/2010/02/dont-stick-to-specs.html" rel="nofollow">http://blog.brodzinski.com/2010/02/dont-stick-to-specs.html</a> In short: I disagree. You don’t want to turn your testers into machines blindly following specs/requirements.

I turned my long response into blog post: http://blog.brodzinski.com/2010/02/dont-stick-to-specs.html

]]> By: Pawel Brodzinski http://pmstudent.com/do-testers-goldplate-too/#comment-25552 Pawel Brodzinski Wed, 10 Feb 2010 20:50:00 +0000 http://pmstudent.com/?p=3956#comment-25552 In short: I disagree. You don't want to turn your testers into machines blindly following specs/requirements. I turned my long response into blog post: <a href="http://blog.brodzinski.com/2010/02/dont-stick-to-specs.html" rel="nofollow">http://blog.brodzinski.com/2010/02/dont-stick-to-specs.html</a> In short: I disagree. You don’t want to turn your testers into machines blindly following specs/requirements.

I turned my long response into blog post: http://blog.brodzinski.com/2010/02/dont-stick-to-specs.html

]]>