47088Re: [scrumdevelopment] Is it ethical to test the software without testing the value behind it?
- Jun 3, 2010Kevlin,Your words make sense, I agree with you.Then, we need to target "what the customer really needs" regardless of the business value as it depends on other factors that are out of our hands.
--- On Thu, 6/3/10, Kevlin Henney <kevlin.henney@...> wrote:
From: Kevlin Henney <kevlin.henney@...>
Subject: Re: [scrumdevelopment] Is it ethical to test the software without testing the value behind it?
Date: Thursday, June 3, 2010, 8:21 AMOn 3 June 2010 11:48, Ahmed ALmahdy <ahmed_abogh@ yahoo.com> wrote:I believe that "testing" is not software testing only, but it should have a serious test to the value behind this software.This picture may clarify my point of viewI wonder, how can we test this value? I found an answer in Agile (scrum) which is sotry writing.Yes, the way of writing stories, I think we should use "so that" or "In order to" or similar templates but not sure if it is enough.Did you find any other practices that helped you to test the value behind the software from your client perspective ?Lately, we created a group for a focused discussion, I recommend it if you are interested.Looking at the aims of the group, I think it may be unethical to confuse business acceptance with the notion of business value :^)However, what you pose is not a question of ethics. Ethics enters into the claims you make about what you have: if you claim something beyond what you have demonstrated or something that you know to be false, that may be considered unethical. "This software works as promised, here are the tests" can be considered ethical in this sense, even if it turns out that we discover faults and misinterpretations. "We have no tests, so we don't know if this will work" is also ethical, although obviously unsatisfying. "This software works as promised, and is guaranteed to make us lots of money" cannot be demonstrated to be true at the time of the claim, and could be considered unethical as a result.What is actually of value to a business is not necessarily the same as what it accepts via testing, no matter how brilliant or well conceived the tests are or how good the dialogue with the business over the requirements. Confusing this matter further with technical practices seems like pursuing the wrong path.In most cases it is not possible to assess actual business value until after the fact. Yes, this can be tested, but it is not the same kind of test, nor is it from the same perspective, as practices such as Acceptance TDD.Being able to predict the business value of software is like predicting the financial markets. Like NP-complete problems, if you figure out how to predict either of these, you've solved the prediction problem for all of them. This, of course, has interesting implications for the notion of prioritising by business value. You can prioritise up front with respect to belief or perception or anticipation of value to a business, but rarely with respect to actual value to a business. Although well meant, we need to adjust our vocabulary a little to avoid such grand claims!Kevlin
____________ _________ ___
+44 7801 073 508
____________ _________ ___
- << Previous post in topic Next post in topic >>