Manual Testing class - 03

S/W Testing Techniques

1)    Static Testing

2)    Dynamic Testing

Static Testing

Review             Informal Reviews                           ( Peer Review )             Technical  Review             Lead Reviews             Management Review                            Formal  Review                           ( Inspections & Audits )                         Walk Through

Approaches or  Methodologies of Dynamic Testing  

1)            White Box Testing

2)            Black Box Testing

3)            Gray Box Testing   ( Ex : Data Base Testing )

Dynamic Testing
White Box Testing             Or Structural Testing       Unit Testing       Integration Testing	Black Box Testing            Or Specification Based Testing      System Testing      UAT
Techniques 1)Statement Coverage 2)Path/Branch/Condition     Coverage * These Techniques are used to Identify the Dead Code or Dead Variables (That code or var not used at any Point of time) * Due to this Dead Code Memory Leakages will be Occur .	Techniques 1)ECP ( EC / EP ) 2)BVA 3)Decision Table Testing 4)State Transition Testing 5)Use Case Testing * BVA & ECP are used to Prepare Test Data. * 3 , 4 , 5 are used to Prepare Test Cases

Static Testing:

Static Testing Is Considered As Verification Of The Documentation.

It Is Also Called As Verification Testing, Which Can Be Part Of All The Stages In The Development Process And Which 
Starts At Very Initial Stage.

There Are 2 Techniques Followed In The Static Testing Process, They Are

                                                1) Reviews:

                                                2) Walkthroughs:

Ø  Reviews:

Reviews Are Part Of Static Testing Performed By The Quality Assurance Team.

Benefits Of Reviews:

1. Defects Are Identified At Early Stage Of The Development Process

2. The Defects In The Later Stages Can Be Prevented.

3. Time And Efforts In Fixing The Defects Would Be Reduced

4. Will Improve The Quality Of The  Product/Software/Application Constructed.

5. Will Improve The Customer Satisfaction.

There Can Be Five Types Of Reviews Performed In A Project Process:

A) Peer Review (Informal Review):

A Review Phase On The Documentation Prepared, Conducted By The Colleague With The Same Role Played In The Project.

B) Technical Review:

These Reviews will be conducted Among Technical Members to Decide The Best Approach of Implementation when ever 
there is a Technical Difficulty. 

C) Lead Review:

A Review Phase Conducted By The Leader Of The Team.

D) Manager/Customer Review:

A Review Phase Conducted By The Manager Or The Customer(If Customer Is Involved). This Is Considered To Be The 
Final Review Phase, If The Document Is Approved At This Level Then It Is Considered As Approved Or Signed Off

E) Inspections & Audits ( Formal Review ):

It Is Also Part Of Review, Which Is Verification Of Documentation.

It Is Considered As A Formal Phase Where The Activity Is Identified Along With The Time in Which It Has To be Conducted.

Inspection Might Have The Team With Following Roles:

1) Inspection Leader or Moderator :

Who Is Responsible For Initiating The Inspection Process, Who Is Also Responsible For Identifying The Team Activity 
On Which The Inspection Has To be Conducted Along With Time And The Venue For The Inspection.

 

Ex: Managers Or Analysts

2) Inspector or Reviewer :

The Person Who Is Responsible For Monitoring The Inspection Process And To Monitor The Progress Of The Inspection
 Process, Will Be The Leader During The Inspection Process.

3)Reader:

Is The Person, Who Is Actually Involved In Reading The Documentation, On Which The Inspection Process Is Conducted
 And Is Also Responsible For Identifying The Deviations Or Enhancements To be Done, Generally Called As "Anomalies"

4) Recorder or Scribe :

Is The Person Responsible For Documenting The Anomalies Or Deviations Or Enhancements Identified By The Reader.

5) Author:

Is The Actual Owner Of The Document, Who Is Responsible For Updating The Document, If Any Changes Or Comments Or 
Updates Documented By The Recorder.

Phases of Formal Review ( Inspection )

1)      Planning

2)      Kick off Meeting

3)      Preparations

4)      Review Meeting

5)      Re Work

6)      Follow Up

1)      Planning :

It is the First Phase of Formal Review Where the Author will send A Formal Request to Moderator . Now the 
Moderator will Perform a Entry Check to Confirm whether The Document is Eligible For Review or Not , If Eligible 
Moderator Prepares A Review Plan and Defines Exit Criteria.

a)      Entry Criteria / Entry Check / Entry Condition

A Set of Pre Conditions to Start an activity is called Entry Criteria

b)       Exit Criteria / Exit Check / Exit Condition

A Set of Pre Conditions to Stop an activity is called Exit Criteria

2)      Kick Of Meeting :

This Meeting is helpful For Moderator to Explain The Review Task and Also To Take The Time
 Commitment Form Reviewers.

3)      Preparation :

In This Phase All Reviewers will Start Reviewing The Job Individually. During This Review Questions
 and Defects will be Documented By Every Reviewer Individually.

4)      Review Meeting :

All Participants Of Review Process That is Reviewers , Moderators including The Author Will Assemble 
& Discuss About The Questions and Defects They Identified .The Accepted Defects Will be
 Documented Separately By a Person Called Scribe / Recorder .

5)      Re Work :

In This Phase Author will Rework on the Document to Fix Defects.

6)      Fallow Up : It is a Last Phase in Formal Review Where the Moderator will Fallow Up all Reviews to Ensure the 
Fulfillment Of Exit Criteria.      

Audits:

It Is Also A Technique In Static Testing, But In Audit, The Process In Implementing The Software Is Checked Rather 
Than The Functionality Inside The Application Constructed.

As Part Of Audit The Audit Team Will Be Held Responsible To Check The Following Things:

Checklist For Audit:

1. Are The Templates Used In All The    Activities are Valid As Per The Organizational Standards

2. Have The Naming Conventions Followed.

3. Are The Activities Carried As Per The Plan

4. Is Documentation Done For Every Single Activity Performed.

5. Are The Deliverables Prepared And Delivered    In Time As Per The Plan

People Involved Are Auditors, Any Deviations In The Audit Process Will Be Documented And Will Be Considered As

 "Non Conformance"(Nc), The Collection Of All The Ncs In A Project Is Called As "Non Conformance Report"(Ncr)

Audits Can Be Of Two Types:

Internal: An Audit Phase Conducted By The Team With in The Organization

External: An Audit Conducted By The Audit Team From Standard Bodies Like(Iso, Cmm, Sei...)

Ø  Walkthroughs:

It Is Also A Technique In Static Testing.

A Step By Step Presentation Conducted By Author About a Subject to Provide Common Understanding to a team is called
 Walkthrough.

( Knowledge Transfer Sessions are Called Walkthrough )

---------------------------------------------------------

Dynamic Testing:

It Is A Testing Phase Conducted On The Constructed/Developed System, By Providing The Inputs And Validating The Outputs From The System.

There Are 2 Major Levels Of Dynamic Testing Performed:

1) White Box Testing     Or    Structural Testing

                                                A) Unit Testing

                                                B) Integration Testing

A)Unit Testing:

It is Also Called As Component Testing.

In Which The Validation Is Done Based On The Knowledge Of The Internal Structure Of The System .

 B) Integration Testing:

Every Unit Or Module Tested And Stable, All The  Modules Are United To Form A System And The Process Of Combing The Modules Is Called As Integration, Checking The Integration Part Is Called As Integration Testing.

Stub : A Simulation Program That Replaces The Called Program Is  Called Stub .

Driver : A Simulation Program That Replaces The Calling Program Is  Called Driver .

Note : If There Are Any Incomplete Programs Then Instead Of Waiting Till All Programs Are Completed , Programmer Will Develop Stubs And Drivers To Carry Out Integration Testing .

  

2) Black Box Testing     Or    Specification Based Testing

                                                A) System Testing

                                                B) Acceptance

A) System Testing:

A System Is A Final Product, Which Is Integrated, Testing The Whole Application/Product Without The Internal Structural Knowledge Is Called As System Testing

Often Test Engineers Are Responsible In Conducting It.

B) Acceptance Testing:

A Testing Phase Conducted By The Customer For Whom The Software Is Constructed, To Accept The Application Is Called As "User Acceptance Testing"

 Testing Terminologies:                                                                                                           

Project:

Is A Software Which Is Developed For A Specific Customer.

Product:

A Software Which Is Developed For Multiple Potential End Users.

Vendor:

It is the Person Or A Firm, Who Is Involved In Developing The Software Or Providing The Services In Both Project And 
Product.

Client:

The Person Or A Firm For Whom The Software Is Constructed.

Customer:

Is The Actual Person Or A Firm Which Uses The Software Constructed.

Note: The Customers And Client Are The Same In terms Of A Project But Different For A Product.

Template:

It Is A Predefined Structure With One Or Multiple Fields.

Templates Are Organizational Level, Which Are Developed Based On The Inputs From The Standards.

Common Templates Should Be Used For Similar Type Of Activities In All the Projects.

Report:

It Is The Summary Of An Activity Performed.

There Can Be Different Reports Prepared At Different Levels, But There Are Two Important Reports Prepared, They Are:

 1) Status Report:

Which Specifies The Progress Of The Project, They Are Two Types:

A) Weekly Status Report:

A Report With The Progress During The Test Design Phase

B) Daily Status Report:

A Report With The Progress During The Test Execution Phase.

2) Defect Reports:

 A Consolidated Report Prepared With The List Of Defects Identified And Reported Along With Their Status.

Clarification Document (RCN):

It Is A Collection Of All The Queries Or Concerns For The Team While Analyzing Or Understanding The Customer
 Requirements.

Understanding Document:

A Document Prepared By The Team, With The Level Of Understanding The Requirements During The Requirement
 Analysis Phase.

Knowledge Transfer(Kt):

It Is Session Conducted To Make The Team Understand What The Requirements Are, This Is Carried Out By The
 Functional Expert.

Sme(Subject Matter Expert):

An Expert In The Domain Or Technology.

Build:

It The Portion Or A Complete System/Software/Application/Work product, Which Is Constructed And Ready For Testing.

Deployment:

It The Process Of Moving The Constructed System(Build) From The Development Environment To The Test Environment 
For Further Testing.

Deliverable:

The Document Or The Summary Of An Activity, Which Is Provided To A Team Or A Person Is Called As Deliverable.

Ex: Test Deliverables:

Test Cases, Test Data, Test Scenarios, Reports....

SRN ( Software Release Note ) :

It Is A Release Note Created By The Developer And Provided To The Test Team While Deploying The Build

DD ( Deployment Document ):

A Document Which Consists Of The Deployment Process

Installation Document:

An Installation Guide Prepared And Provided By The Developer To The Tester, While Deploying The Build

Unit Test Report:

It Is The Summary Of The Test Performed By The Developer.

Test Set:

It Is A Collection Of Several Test Cases To be Executed On Given Build

It can Be The Collection Of Manual Test Cases Or Automation Test Script Or Combination Of Both.

Test Cycle:

Executing All The Test Cases Documented In A Test Set On A Given Build For One Iteration Is Called As Test Cycle.

Issue Log:

The Problems Or The Challenges Faced By The Team During The Process Of Validating The System.

Every Issue Should Be Documented With The Completed Resolution Process.

Test Execution:

It Is The Process Of Validating The System Or

Build (Executing The Test Case).

In This The Status Of The Test Would Be -

Passed: If The Expected Is Matching With The Actual Response From The System

Failed: If The Expected Is Not Matching The Actual Response.

                                                                                                                                      

Note: Every Failed Scenario Is Considered As A Deviation And The Deviation Should Be Reported.

Traceability Matrix:

It Is Mapping Between The Test Cases And The Customer Requirements.

It Is To Analyze The Coverage of TC With Respect To The Requirements.