On Thu, Sep 27, 2012 at 8:32 PM, Jim Henderson <hendersj@gmail.com> wrote:
Exactly my point. I know what I can do in an hour. I don't know what you can do in an hour. I don't know what my older brother (who has experience as an end-user of Macs mostly) could accomplish on a Linux box in an hour.
Perhaps your older brother would be willing to be a test subject for quantitative data on how much results can be expected from a "noob" user in a 1 hour period of time? If it takes him 4 hours to accomplish what you can in 1 hour then perhaps we could re-think the process in which the task to be executed to take 1 hour for a user at your brothers level? It sounds like an opportunity to do some very progressive and beneficial R&D work. On Thu, Sep 27, 2012 at 8:32 PM, Jim Henderson <hendersj@gmail.com> wrote:
On Thu, 27 Sep 2012 19:18:04 -0500, Rajko wrote:
We will not look task and estimate how many hours user has to spend on it, but the other way around. Take one hour limit and find tasks that fit in that time frame.
An hour by whose measure, though? In project management time estimation, the /best/ judge of how long it takes to do something is the person who is going to do the task.
That's not to say you can't estimate it (weighted averages as I mentioned before are often used - but even then, the best data comes from the person doing the task).
In professional world you have task and look how many man hours you need for it.
Right, and you ask the person doing the task - usually someone experienced or who has at least done the task before at the skill level of the person doing the task - makes the estimate.
As you know, working with people that donate their free time is different.
Exactly my point. I know what I can do in an hour. I don't know what you can do in an hour. I don't know what my older brother (who has experience as an end-user of Macs mostly) could accomplish on a Linux box in an hour.
We have a very wide userbase with a very large variety of experience levels who get involved in testing. So whose measure of "what can be done in an hour" is the benchmark?
What is goal of small tasks limited to 1 hour or lesser? It is the same goal that makes Wikipedia successful. Give a chance people with little time for openSUSE to contribute. That is majority of our users.
Yes and no - Wikipedia's entries grow somewhat organically. Work units on bug analysis are more discrete components. On Wikipedia, writing an article about elephants (for example), you have people contributing and building on the same base of information.
There's a sequence of tasks that need to be completed - so when breaking work units out, when you end up with a work breakdown structure that is sequential, you can't use the time to complete a discrete work unit as the estimate for the total time involved to complete that work unit.
If it takes me an hour to set up to get to where I can do the hour of testing for the task at hand, that has to be taken into consideration as part of the task.
If we try to make some sort of guarantee and it turns out that most people take more than an hour, then nobody's going to trust the estimates.
Thus, it's not a matter of simply guessing, but rather doing an actual estimate, using best case/worst case/likely case weighted averages - and that could end up taking more time to come up with for some tasks than the actual task itself would take.
Estimate is just that. We can tell that user that knows this and that will spend 1 hour or lesser. To learn "this and that" user will need additional hours, and to be honest we can estimate that too trough average reading speed vs. size of text, available help, etc.
Sure, but again that comes back to the question of what the expected level of experience is for those doing the tasks.
The solution is that when a task is being defined, ideally you should have the actual tester involved to try to provide a baseline for how long they think it'll take - best case, worst case, and likely case, and then use a weighted average to determine if the task is reasonable.
If it isn't, and it can't be further divided, then either more time is needed or a more experienced tester is needed.
... users skills can be taken out only with helper script that will offer interface with plain language and as output give file that is ready to upload, or even upload it, as smolt client does with hardware information.
There again, though, the time to create/debug the helper scripts (which I don't know how generic they can be) might take longer than having someone knowledgeable actually doing the task.
We are talking about scripts that will collect info.
Sure, and that is something that can help with predictability. If it's known that a script that does x, y, and z will gather the necessary information and it takes 10 minutes to understand how to run it, 5 minutes to run it and verify the collected data is valid enough, and 10 minutes to update the bug, then that's a reasonable approach.
I mentioned somewhere that we on IRC spend more time explaining how to get information needed to solve a problem, then solving the problem. Any script that will cut down on that is not wasted time.
Also, knowledgeable people are busy :)
Yes, which is why it's important to determine if it's a better use of their time to create a script or to just test the thing that needs to be tested.
It's also important that the tasks defined not be so scripted as to produce a result that's not valid for fixing the bug. If I write a procedure that ultimately misses the point of the bug, then we could end up with a lot of NABWAD resolutions (ie, "Not a Bug, Working as Designed") as a result of poorly written instructions - or poorly understood bugs.
Jim -- Jim Henderson Please keep on-topic replies on the list so everyone benefits
-- To unsubscribe, e-mail: opensuse-project+unsubscribe@opensuse.org To contact the owner, email: opensuse-project+owner@opensuse.org
-- God bless ! Scott DuBois www.ROGUEHORSE.com openSUSE -- To unsubscribe, e-mail: opensuse-project+unsubscribe@opensuse.org To contact the owner, email: opensuse-project+owner@opensuse.org