Bug Life Cycle-Definitions and different Severities and Priorities

New-Whenever a bug or defect is produced by the concerned stakeholder, a new bug is opened.

Assigned-The respected bug is assigned to the concerned developer

Fixed-Once the developer fixes the bug he marks it as fixed

Verified-Once the bug is fixed by the developer, the concerned Tester would verify whether the bug has been fixed or not.

Re-opened-In case the bug has not been fixed the bug would be marked as Reopened so that it would be assigned again to a developer and cycle would be repeated.

Closed-Once the Tester confirms that the bug has been fixed he would mark it as Closed.

Definition of Different Priorities:

-Priorities

P1-Cannot ship the product/project without this

P2-It is highly desirable and planned for this release but it would not stop the shipping of the build

P3-It is of interest but not planned for this release.

-Severity

Blocker- Prevents function from being used, no work-around, blocking progress on multiple fronts

Critical- Prevents function from being used, no work-around

Major- Prevents function from being used, but a work-around is possible

Normal- A problem making a function difficult to use but no special work-around is required

Minor- A problem not affecting the actual function, but the behavior is not natural

Trivial- A problem not affecting the actual function, a typo would be an example

Enhancement-Something that can be good to have but not necessary to be included in the current release

-Low Severity and High Priority:

UI issue on website, spelling mistake it is of low severity but of high priority as it affects the business

-High Severity and Low Priority:

If there is an application if that application crashes after multiple use of any functionality (E.g. :- save Button use 200 times then that application will crash)

Means High Severity because application crashed but Low Priority because no need to debug right now you can debug it after some days.

Quality Assurance Vs Quality Control

QA Vs QC

Quality is defined as meeting Customer's requirement in the first time and every time. Quality is much more then absence of defects, which allows us to meet customer's expectations.

There are five perspectives of quality:

Transcendent-I know when I see it

Product Based-Possesses desired features

User Based-Fitness for use

Development and Manufacturing based-Confirms to requirements

Value based-At an acceptable cost

Quality is most important factor affecting an organization's long term performance. Quality is the way to achieve improved productivity and competitiveness in any organization.

Quality Assurance:

QA is a planned and systematic set of activities necessary to provide adequate confidence that product and services will confirm to specified requirements and meet user needs.QA aims at building the confidence in the system so that probable client or Customer could be given an assurance that final product adheres to the set Requirements.

Quality Control:

QC is a process by which Product quality is compared with applicable standards and the action taken when non-conformance is detected. Quality control is line function and work is done within a process to ensure that work product conforms to standards and/or requirements.

What is Action In QTP?

Whenever we test any application we always divide that in some logical grouping based on different functionality.
In QTP also when it comes to automate any functionality it becomes easy to divide features and functionalities. So action can be defined as a scenario which forms small part of entire application, group of all these actions form entire application.
Action contains scripts for that particular scenario and based on test cases these scripts can be modified.

How to create a new Action:
-On Insert Tab select option Call to new Action
-Type in the name that you want to give to your Action
-Select check box Reusable Action if you want to create an Action which can be reused, if you don’t want this option then un-select this check box
-Select option At the end of the Test(Action would be added to the end of the Test) or After the current step(The action will be added after the current Step)
-Click OK

Call to copy Of Action:
Selecting this option would allow user to create a copy of some already existing Action to the current action.

Call to existing Action:
Call to Existing Action would allow user to Use any existing Action but in read only mode.

Types of Action:
1) Reusable Action: Reusable Action is one that can be called multiple times by the test with which it is stored (the local test) as well as by other tests.

2) Non reusable Action: Non-reusable action is an action that can be called only in the test with which it is stored, and can be called only once.

3) External Action: A reusable action stored with another test, external actions are read-only in the calling test, but you can choose to use a local, editable copy of the Data Table information for the external action.

Static and Dynamic Testing

According to one of the Testing Principles "Early Testing is very important" in SDLC. The important question that arises here is that when application or project is not even completed how one can start Testing.

This gives us an opportunity to understand the two major types of Testing:

-Static Testing

-Dynamic Testing

Static Testing

Static testing includes testing without execution of the application or running the test cases. Static Testing includes review of the documents that form the part of the development e.g. of such document include SRS (Software Requirement Specification).

Code review is also a part of Static Testing. On coding Level several static techniques can be used at initial stage

-Static Code analysis

-Coding Standards

-Code metrics

Review forms a major part of Static Testing:

On Broad level Review are of two types:

-Informal Review-Informal Review is the type of static testing which do not require any formal notification or documentation for review to take place .e.g. a developer writes a code and asks his Peer or colleague to have a look at it.

-Formal Review-Formal Review is a type of Static Testing which requires a proper notification and documentation before a review could actually start.

Types of Formal Review:

1) Walk through-

2) Technical Review

3) Inspection

Phases for a formal Review Process:

-Planning

-Kick Off

-Preparation

-Review Meeting

-Rework

-Follow up

Dynamic Testing

Dynamic Testing includes actual testing of the application under development, execution of the test cases form the integral part of this type of testing.

To design these test cases which would be used for execution some of the methods are:

A) Black Box Testing

-Equivalence Partitioning

-Boundary Value Analysis

-Decision Table

-State Transition

-Use case Testing

B) White Box Testing

-Decision Coverage

-Branch Coverage

C) Exploratory Testing

D) Experience Based Testing

QTP

Quick Test Professional is Test automation Tool which helps user to automate his Test Cases. The best candidates for Automation Testing are:

• · Smoke Testing

• · Regression Testing

Type of testing that cannot be done using automation:

• · Usability Testing

• · Adhoc Testing

Limitations of Automation Testing:

• · Maintenance of scripts

• · Only those applications can be automated which are stable

• · Automation can Cover only 60-70% of application under Test

Automation process:

• · Prepare-Prepare the actions based on the Scenarios and Test cases

• · Create-Create Object Repositories for the application under Test

• · Verify-Based on the Test cases use Check points and other features to customize the script

• · Integration-Joining all the actions to have one complete system(Not a mandatory step)

Pre-requisites of Automating any application:

• · System under Test should be stable

• · Functionality that need to be checked should be determined

• · Execution of Manual test cases should be done

• · Test data should be prepared

• · Initial and end conditions should be known

• · To Check if a system require any add in

What is the difference between Scenario and Test case:

• · Scenario-Conditions which are to be tested

• · Test Case-Detail description of Scenarios