PRIORITY VS SEVERITY

“Priority” is associated with scheduling, and “severity” is associated with standards and criticality.
“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. 

Exploratory Testing & Adhoc Testing

Exploratory testing is an approach to software testing that is concisely described as simultaneous learning, test design and test execution. Exploratory testing seeks to find out how the software actually works, and to ask questions about how it will handle difficult and easy cases. The quality of the testing is dependent on the tester's skill of inventing test cases and finding defects. The more the tester knows about the product and different test methods, the better the testing will be.

Ad hoc testing is a commonly used term for software testing performed without planning and documentation.

The tests are intended to be run only once, unless a defect is discovered. Ad hoc testing is a part of exploratory testing, being the least formal of test methods. In this view, ad hoc testing has been criticized because it isn't structured, but this can also be a strength: important things can be found quickly. It is performed with improvisation, the tester seeks to find bugs with any means that seem appropriate. It contrasts to regression testing that looks for a specific issue with detailed reproduction steps, and a clear expected result. Ad hoc testing is most often used as a complement to other types of testing.

REVIEW PROCESS

Review process

The different types of reviews vary from very informal (e.g. no written instructions for reviewers) to
very formal (i.e. well structured and regulated). The formality of a review process is related to
factors such as the maturity of the development process, any legal or regulatory requirements or the
need for an audit trail.The way a review is carried out depends on the agreed objective of the review (e.g. find defects, gain understanding, or discussion and decision by consensus).
Phases of a formal review
A typical formal review has the following main phases:
1. Planning: selecting the personnel, allocating roles; defining the entry and exit criteria for more
formal review types (e.g. inspection); and selecting which parts of documents to look at.

2. Kick-off: distributing documents; explaining the objectives, process and documents to the
participants; and checking entry criteria (for more formal review types).

3. Individual preparation: work done by each of the participants on their own before the review
meeting, noting potential defects, questions and comments.

4. Review meeting: discussion or logging, with documented results or minutes (for more formal
review types). The meeting participants may simply note defects, make recommendations for
handling the defects, or make decisions about the defects.

5. Rework: fixing defects found, typically done by the author.

6. Follow-up: checking that defects have been addressed, gathering metrics and checking on exit
criteria (for more formal review types).

Roles and responsibilities:

A typical formal review will include the roles below:

• Manager: decides on the execution of reviews, allocates time in project schedules and
  determines if the review objectives have been met.
• Moderator: the person who leads the review of the document or set of documents, including
  planning the review, running the meeting, and follow-up after the meeting. If necessary, the
  moderator may mediate between the various points of view and is often the person upon whom the success of the review rests.
• Author: the writer or person with chief responsibility for the document(s) to be reviewed.
• Reviewers: individuals with a specific technical or business background (also called checkers or inspectors) who, after the necessary preparation, identify and describe findings (e.g. defects) in the product under review. Reviewers should be chosen to represent different perspectives and roles in the review process, and should take part in any review meetings.
• Scribe (or recorder): documents all the issues, problems and open points that were identified
  during the meeting.

Looking at documents from different perspectives and using checklists can make reviews more
effective and efficient, for example, a checklist based on perspectives such as user, maintainer,
tester or operations, or a checklist of typical requirements problems.
Types of review:
A single document may be the subject of more than one review. If more than one type of review is
used, the order may vary. For example, an informal review may be carried out before a technical
review, or an inspection may be carried out on a requirements specification before a walkthrough
with customers. The main characteristics, options and purposes of common review types are:
Informal review
Key characteristics:

• no formal process;
• there may be pair programming or a technical lead reviewing designs and code;
• optionally may be documented;
• may vary in usefulness depending on the reviewer;
• main purpose: inexpensive way to get some benefit.

Walkthrough
Key characteristics:

• meeting led by author;
• scenarios, dry runs, peer group;
• open-ended sessions;
• optionally a pre-meeting preparation of reviewers, review report, list of findings and scribe (who is not the author);
• may vary in practice from quite informal to very formal;
• main purposes: learning, gaining understanding, defect finding.

Technical review

Key characteristics:

• documented, defined defect-detection process that includes peers and technical experts;
• may be performed as a peer review without management participation;
• ideally led by trained moderator (not the author);
• pre-meeting preparation;
• optionally the use of checklists, review report, list of findings and management participation may vary in practice from quite informal to very formal;
• main purposes: discuss, make decisions, evaluate alternatives, find defects, solve technical
  problems and check conformance to specifications and standards.

Inspection
Key characteristics:

• led by trained moderator (not the author);
• usually peer examination;
• defined roles;
• includes metrics;
• formal process based on rules and checklists with entry and exit criteria;
• pre-meeting preparation;
• inspection report, list of findings;
• formal follow-up process;
• optionally, process improvement and reader;
• main purpose: find defects.

Walkthroughs, technical reviews and inspections can be performed within a peer group –
colleagues at the same organizational level. This type of review is called a “peer review”.

Success factors for reviews:
Success factors for reviews include:

• Each review has a clear predefined objective.
• The right people for the review objectives are involved.
• Defects found are welcomed, and expressed objectively.
• People issues and psychological aspects are dealt with (e.g. making it a positive experience for the author).
• Review techniques are applied that are suitable to the type and level of software work products and reviewers.
• Checklists or roles are used if appropriate to increase effectiveness of defect identification.
• Training is given in review techniques, especially the more formal techniques, such as
  inspection.
• Management supports a good review process (e.g. by incorporating adequate time for review activities in project schedules).
• There is an emphasis on learning and process improvement.

Bug Life Cycle

In SDLC the bug has a life cycle. The bug should go through the life cycle to be closed. A specific life cycle ensures that the process is standardized.The bug attains different states in the life cycle. The life cycle of the bug can be shown diagrammatically as follows:

The different states of a bug can be summarized as follows:

1. New
2. Open
3. Assign
4. Test
5. Verified
6. Deferred
7. Reopened
8. Duplicate
9. Rejected and
10. Closed

Description of Various Stages:

1. New: When the bug is posted for the first time, its state will be “NEW”. This means that the bug is not yet approved.

2. Open: After a tester has posted a bug, the lead of the tester approves that the bug is genuine and he changes the state as “OPEN”.

3. Assign: Once the lead changes the state as “OPEN”, he assigns the bug to corresponding developer or developer team. The state of the bug now is changed to “ASSIGN”.

4. Test: Once the developer fixes the bug, he has to assign the bug to the testing team for next round of testing. Before he releases the software with bug fixed, he changes the state of bug to “TEST”. It specifies that the bug has been fixed and is released to testingteam.

5. Deferred: The bug, changed to deferred state means the bug is expected to be fixed in next releases. The reasons for changing the bug to this state have many factors. Some of them are priority of the bug may be low, lack of time for the release or the bugmay not have major effect on the software.

6. Rejected: If the developer feels that the bug is not genuine, he rejects the bug. Then the state of the bug is changed to “REJECTED”.

7. Duplicate: If the bug is repeated twice or the two bugs mention the same concept ofthe bug, then one bug status is changed to “DUPLICATE”.

8. Verified: Once the bug is fixed and the status is changed to “TEST”, the tester teststhe bug. If the bug is not present in the software, he approves that the bug is fixed and changes the status to “VERIFIED”.

9. Reopened: If the bug still exists even after the bug is fixed by the developer, the tester changes the status to “REOPENED”. The bug traverses the life cycle once again.

10. Closed: Once the bug is fixed, it is tested by the tester. If the tester feels that the bug no longer exists in the software, he changes the status of the bug to “CLOSED”. This state means that the bug is fixed, tested and approved.

While defect prevention is much more effective and efficient in reducing the number of defects, most organization conducts defect discovery and removal. Discovering and removing defects is an expensive and inefficient process. It is much more efficient for an organization to conduct activities that prevent defects.

STUB VS DRIVER

Both these terms, Stub and driver, are mainly used in Software integration testing.


->Stub is a piece of code emulating a called function, a driver is a piece of code emulating  a calling function.


-> Stubs are created integration testing like Top-down approach. 
    Drivers are created integration testing like bottom-up approach.

-> Stub: A piece of code that simulates the activity of missing component. 

    Driver: A piece of code that passes test case to another piece of code.

Example - For Unit Testing of ‘Sales Order Printing’ program, a ‘Driver’ program will have the code which will create Sales Order records using hard coded data and then call ‘Sales Order Printing’ program. Suppose this printing program uses another unit which calculates Sales discounts by some complex calculations. Then call to this unit will be replaced by a ‘Stub’, which will simply return fix discount data.

Also, check out Free ISTQB Training Material here

www.testing4success.com - Application QA/Testing     Mobile App QA/Testing     Web Testing     Training
Iphone App QA  Android App QA  Web QA

Suppose I have a workflow in which the code functionality flows from one system to the another and then to the third one, if the second system in the flow is down then we can use a simulator for that step which will act like a Driver. Similarly, if there was some xml response which we might have been receiving from the second system than that part will be called as Stub.