Q. What is a test strategy?
Answer:
A test strategy must address the risks and present a process that can reduce those
risks.
The two components of Test strategy are:
a) Test Factor: The risk of issue that needs to be addressed as a part of the test
strategy. Factors that are to be addressed in testing a specific application
system will form the test factor.
b) Test phase: The phase of the systems development life cycle in which testing
will occur.]
Q. When to stop testing?
Answer:
a) When all the requirements are adequately executed successfully through test
cases
b) Bug reporting rate reaches a particular limit
c) The test environment no more exists for conducting testing
d) The scheduled time for testing is over
e) The budget allocation for testing is over]
Q. Your company is about to roll out an E-Commerce application. It is not
possible to test the application on all types of browsers on all platforms and
operating systems. What steps would you take in the testing environment to
reduce the business risks and commercial risks?
Answer:
Compatibility testing should be done on all browsers (IE, Netscape, Mozilla etc.)
across all the operating systems (win 98/2K/NT/XP/ME/Unix etc.)]
Q. What’s the difference between priority and severity?
Answer:
“Priority” is associated with scheduling, and “severity” is associated with standards.
“Priority” means something is afforded or deserves prior attention; a precedence
established by order of importance (or urgency). “Severity” is the state or quality of
being severe; severe implies adherence to rigorous standards or high principles and
often suggests harshness; severe is marked by or requires strict adherence to
rigorous standards or high principles, e.g. a severe code of behavior. The words
priority and severity do come up in bug tracking. A variety of commercial, problemtracking/
management software tools are available. These tools, with the detailed
input of software test engineers, give the team complete information so developers
can understand the bug, get an idea of its ’severity’, reproduce it and fix it. The fixes
are based on project ‘priorities’ and ’severity’ of bugs. The ’severity’ of a problem is
defined in accordance to the customer’s risk assessment and recorded in their
selected tracking tool. A buggy software can ’severely’ affect schedules, which, in
turn can lead to a reassessment and renegotiation of ‘priorities’.]
41 comments ↓
How priority and severity are determined?
Are they only decided by the tester by his own or is there any fix criteria to decide it?
I mean if i found a bug i will assign it priority what i think is relative but for the same bug other tester can assign different priority and severity … so how should one maintain this as a standard?
Q. When to stop testing?
Answer:
a) When all the requirements are adequately executed successfully through test
cases
b) Bug reporting rate reaches a particular limit
c) The test environment no more exists for conducting testing
d) The scheduled time for testing is over
e) The budget allocation for testing is over
if we have multiple option question
then which of the above is most correct answer
I feel, none of above mentioned options are adequate to stop testing.
I could have been,
1. Raised defect status are of low priority having very less impace on system
2. Business agrees to stop the testing & is ready to bear all the risk
3. Atleast all the high priority requirement related test cases are covered.
give more examples for priority and severity defects
IN general the tester only assigns severity to the bug. The priority is assigned by the project manager. The priority of the bug might differ according to the release and hence the project manager will assign priority depending on how important that bug fix is for the release.
Please correct me if i am wrong.
-subha
Would like to know what is the difference between test plan and test stratergy.
severity means how serious the bug is?
pripority means a message to the developer what defect are taken first ,next and ;last for defect recttification
How to decide the priority and severity ?
your answer provide nice information ,but i have one
quiery that is
“can priority dependes on severity”?
please answer my quiery.
who decides the priority devloper or QA?
QA
Base on client requirements we decided the priority.
Means the importance of the client requirement we give the priority…
Can anyone give examples for all combinations of priority and severity like high priority and low severity,etc…
Hi all,
Can anyone tell me procedure for testing performance of web apps ?
I am single tester in my company. I want to do load /stress testing.
Please help me.
u all hvnt gve the live examples of severity and prioroty .so plkease try to gve the examples
Hi Meghmala,
can you please tell me which automation tool using for performance testing?
The process is depending on the tool!!!
Please get back on nvenkii@gmail.com
To decide the severity of the bug, tester has to follow the Bug categorization document designed by the Test architect in the company.
Different product or application have different severity based on the customer requirements.
Priority and Severity are subjective term both completely depends upon domain in which you are and phase in which your project is e.g If you are in banking domain then bug in spealing, logs will have less severity but if you in E-learning domain then spealing and logs, pictures will have high severity.So deciding severity and Priority is tester job but after haveing word with the Team lead or the Manager.
While creating the bug, severity has to be decided by the test engineer based on the Bug categorization document, and Priority has be decided by Software Developer or Project manager who is leading the project for which Testing is done by Software Quality Assurance(SQA) team.
Any questions, please write to me at aashwini.r@gmail.com
Correction in email id: please write to me at ashwinir@gmail.com
Severity: It is the seriousness of defect in terms of Functionality
Priority: The importance of defect to resolve w.r.t Customer/Client/User
Here are some definitions to keep in mind when submitting a bug in Bugzilla:
SEVERITY
Define defect severity value by Bugzilla default severity definition. The severity describes the impact of a bug.
Blocker: Prevents developers or testers from performing their jobs. Impacts the development process.
Critical: Crash, loss of data, corruption of data, severe memory leak.
Major: Major loss of function, as specified in the product requirements for this release, or existing in the current
Normal: Non-major loss of function.
Minor: Issue that can be viewed as trivial (e.g. cosmetic, UI, easily documented).
Enhancement: Request for software enhancement, or any non-defect task or work item.
PRIORITY
Define defect priority value by Bugzilla default priority definition. The priority specifies the level of urgency to be resolved for the defect.
P1-Urgent: defects are urgent issues.
P2-High: defects must be resolved in this release.
P3-Medium: defects would like to be fix, but won’t hold shipment for them.
p4-Low: defects are not as strong as desirable.
Bugzilla has many fields that provide additional information (e.g., environment details, found in version, etc.). Please provide as much information as possible when logging bugs.
dig it?
Hello Dear,
Can i get a job in QA where as i’m doing software testing course.
Is there any checklist available to decide the severity and priority of a bug?
Companies performing software development must look at error severity from a user’s point of view. What follows is a very useful system for classifying errors. Use it in your computerized M.R. system. An M.R., or modification request, is entered into a computer by any individual discovering an error in any software. The severity of the error is expressed as a number between one and four, and is defined as follows:
1 – An error which causes a program or system interrupt, or which causes program execution to abort. System personnel refer to this type of error as a “show stopper”. This error has the highest severity rating.
2 – A severe error which causes a program not to perform properly or to produce unreliable results. Normally, the user cannot find an appropriate “workaround” for this type of error.
3 – An error for which, while not minor, a “workaround” solution can be found for the user.
4 – A minor error, a cosmetic change, or an enhancement.
It should be the policy that, once a severity “1″ error is discovered, programmers and developers must work around-the-clock until the error is corrected. Software can never be released to customers with any severity “1″ or “2″ errors. Occasionally, a software release with some severity “3″ errors will be permitted. However, these errors are documented along with the actions to be taken by users when encountering them. Normally, severity “4″ errors would not delay a software release.
hello, can anyone please guide me about to write test cases and wanna to know about Bugzilla
hi frinds,
can any one give me the difference between
retesting and regression testing?
Retesting is testing the new code again with the same set of test cases. But Regression testing is testing the existing functionality to verify that the new code has not unearthed any new defects in the existing functionality. Simply, regression testing is to verify that that existing functionality works as expected.
Suppose u have the website “Google” and the home page is having two fields “Username” and “Password”.
Case 1: If the user try to login after entering the credentials and is not able to do so – High Priority High Severity.
Case 2: If the letter ‘o’ is missing from the website logo ‘Google’ hampering the organisation’s reputation but not affecting any of the functionality – High Priority Low Severity
Case 3: If the help option from the browser is displaying blank on clicking it – Low Priority High Severity (From functional point of view this error is sever but from a practical standpoint, not every one opening the browser will go for the help option)
Case 4: On logging into any website if the home page is not displaying a comma (‘,’) between two words which it should have displayed
(cosmetic issue) – Low Priority Low Severity.
Who decides the severity and priority for a bug?
severity — tester
priority– business; after the daily defect call, based on the testing schedule.
The examples shared by Abhijit(#29 ) are very good. Now i have some what clear picture of Severity and Priority. Thanks Abhijit
things explain by Abhijith # 29 is good,
SEVERITY :Impact of a bug in applications.
Blocker, Critical, Major, Normal, Minor
PRIORITY: Effect of a bug in the applications
P1-Urgent: defects are urgent issues.
P2-High: defects must be resolved in this release.
P3-Medium: defects would like to be fix, but won’t hold shipment for them.
p4-Low: defects are not as strong as desirable.
So priority and serverty, define by the tester and priority fixed by only current issue and depend upon that issue serverity fixed.
Partially i agree with Anjani.
When tester testing the application, if he detected a defect which affecting the functionality, he knows how badly it affecting the funct to go ahead.
so while logging he will assign the serverity.
But i dnt think, tester will assign priority aswell, why because.. once the defect is logged, Project manager/BOD(PM, PL)will review and decide, how fastly it should be fixed.
as u said, urgent, high, medium, low.
Really you explained very well.
Sorry i haven’t mention the name. Its for Abhijit
Can u pls let me make understand of priority and severity by giving more examples?
Priority :- How quickly we need to fix the bug? Or How soon the bug should get fixed?
Severity : – How much the bug is effecting the functionality of the application?
Eg:-
High Priority —Low severity
High Priority — High Severity
Low priority —High Severity
Low priority — low severity
(1) High Priority and Low Severity
If a company logo is not properly displayed on their website.
(2) High Priority and High Severity
Suppose you are doing online shopping and filled payment informations, but after submitting the form, you get a message like “Order has been cancelled.”
(3) Low Priority and High Severity
If we have a typical scenario in which the application get crashed, but that scenario exists rarely.
(4) Low Priority and Low Severity
There is a mistake like “You have registered success” instead of successfully, success is written
severity tells us about the impact of defect on the application or software where
priority tell about its appearance to solve or it tell us when we have to solve that defect
Nice explanation swetha. Wishes…!!
Leave a Comment