TesterDays
Member
Reged: 06/19/07
Posts: 187
|
|
Quote:
The Customer has no idea about the schedule so why would they be impacted if they have no idea about what is coming? I don't really see that as valid.
Hi,
It depends on the project that you work , for example i was working in the project where rules set by the government of the country had to be implemented on the customers product directly so cases like these the customer will know and would be waiting for the release with the changes. Because it all about vitamin M (Money) at the end of the day 
Regards
|
michaeljf
Veteran
Reged: 09/17/01
Posts: 3527
Loc: Yankee Land
|
|
Quote:
where rules set by the government of the country had to be implemented on the customers product directly so cases like these the customer will know and would be waiting for the release with the changes
I don't see why general Customers would know what is coming in a future release and be severely impacted by that, if you think otherwise that's fine but I disagree with this. If you have an actual example you can share that's fine, but even with Government contracts and a schedule I don't see where someone is severely impacted by a future feature release.
--------------------
- M
Nothing learns better than experience.
"So as I struggle with this issue I am confronted with the reality that noting is perfect."
- Unknown
Now wasting blog space at QAForums Blogs - The Lookout
|
Peter Ruscoe
Veteran
Reged: 03/18/02
Posts: 6906
Loc: Tampa Bay
|
|
Interesting thread. Clearly, if everyone (testers, managers, etc.) are going to "speak the same language" then there is still a lot of work to be done.
In a former life, I managed a Test Department. One popular topic in our weekly meetings was priority and severity. But these folks had no problem understanding the extreme cases (such as this one). Maybe it was due to my education and leadership, maybe not.
If (and I address this to all of you, not just the original questioner) you want to get into risk-based testing, then you REALLY need to understand the difference between priority and severity.
And specifically to DenisJ - of COURSE you have to know your context. In one application, a bug may not even have impact on anyone except a tester. In a different application, the same (or similar) bug could cause instant and/or painful death. For an example, Google "death" and "Therac-25." (Several articles have a misuse of the term "race condition" but it doesn't alter the horror story at the Yakima Valley Cancer Center to which I am referring.) 99 out of 100 software testers care little or nothing about timing - at least for functional testing. In this case, ignoring it caused several people's deaths.
|
venky510
Member
Reged: 01/21/10
Posts: 34
Loc: Gujarat,India
|
|
hi,
Think about google search engine. Upon entering 100 characters of letters into the search engine the application starts crashing. It is a high seviority and low priority bug cause application crash is a high seviority and a less number of people will enter 100 characters so it is a low priority.
hope this will work for you...
--------------------
regards,
venkatesan
http://venkatesan-iyer.blogspot.com
Edited by venky510 (06/10/10 10:21 PM)
|
testerboy1
Member
Reged: 06/11/08
Posts: 69
|
|
Can you please provide exactly good example to this..
|
Ritesh_J
Newbie
Reged: 06/21/10
Posts: 1
|
|
Here's an example:
High Severity and Low Priority
Thanks.
--------------------
www.interview7.com
|
K_Suresh_K
Newbie
Reged: 04/07/09
Posts: 18
|
|
Hi,
In an application, if your are taking an yearly report and if you found any defect in the report, then you can raise it as 'High severity' and 'Low priority'.
If the defect is on a weekly report, then it can be raised as 'High severity' and 'High priority'
Regds,
K_Suresh_K
|
Previous
Index
Next
Threaded
Edit
Reply
Quote
