Manual Testing Complete Material

MANUAL TESTING

CLASS - 1  

Introduction:

Software:

It is a set or instructions or programs grouped to Performa specific task for the end user.

It is categorized into 2:

A)     System software:

It is Also called as operating system software, which works as an interface between the 
application and the hardware components.

It sets a platform to work with any application software.

Ex: windows, Linux, UNIX, Solaris

B) Application software:

Which is developed to work as an interface between the end user and the database.

m

Ex: ms office, google, gmail, hotmail, calculator....

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

Testing:

It is the process of identifying the defects in the software system constructed.

Or

It is a verification and validation process to ensure the completeness and correctness of the system.

Or

It is the process of identifying the unidentified defects the system.

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

Manual testing:

Human interacting with the developed system to check it's completeness and correctness is called 
as manual testing.

Defect:

Is considered as deviation from the expectation (customer requirements)

Any defect identified should be reported to the development team for it's rectification.

Benefits of testing:

1. Will improve the quality of the software that is constructed.

2. Will improve the customer satisfaction

3. Will reduce the cost and efforts .

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

Testing objective:

The objective of testing is to identify the defects in the software system constructed.

Quality:

A software application which is relatively maximum bug free and which is developed in the specified
 time and cost limits and meets the customer expectations, then that software is called as a quality software.

The factors affecting the quality are;

A) meeting the customer requirements or expectation

B) time

C) budget/cost

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

Software engineering:

It is the process of developing/constructing a software application by implementing/following
 different stages is collectively called as software engineering.

Software development life cycle( SDLC ):

It is the collection of various stages in implementing a software application.

It is otherwise called as a general model, which is a

Combination of 6 stages:

1. Requirement collection:

It is Also called as as requirements gathering, where a group of experts will visit the customer's
 site and analyze the business performed and will collect the documents & requirements.

People involved are like project and test analysts or leads

There can be two types of requirements collected and documented.

A) Business Requirements:

It is the collection of all the business processes or business transactions performed.

All the high level activities captured and document along with the business rules framed by the
 customer is called as "business requirement specification"(BRS)

B) Functional Requirements:

These are otherwise called as system or software requirements.

It is a detailed document which describes every individual transaction that is documented in BRS document.

It is consists of all the functional and non functional components that are required in constructing
 the current system.

It can be a combination of flow charts and dataflow diagrams as well as use cases.

All the above would help in understanding the requirements better.

The functional requirements are inputs for any type of an activity performed in constructing the system.

2.     2. Feasibility analysis:

3.      

Feasibility: it is the possibility of implementing/developing the software.

It is Also called as business commit, where the customer and the vendor will commit a business or 
come to an agreement in constructing the software.

As part of business commit, the project managers and the business analyst would be involved in
 getting the base requirements of the business performed by the customer and the project managers
 would be involved in analyzing the

Following things:

A)     Domain:

It is the common set of features or functionalities performed in a business grouped together is 
called as a domain

Ex: banking, finance, retail, telecom, logistics, health care, stock, networking, web, investments...

The study is made on the business performed by the customer.

B) technology:

A detailed technical study is made in analyzing the technology required to implement the software

Ex: programming language and database skills

C,c++,vc++,java, ejbs, struts, .net, asp, along with sql.....

C) resources:

There are three kinds of resources:

I)hardware resources:

The system configurations along with network and server resources, which are required are analyzed.

Ii) software requirements:

The software required to implement the application

Ex: operating system, database

Windows, linux... Oracle, sql server....

Iii) human resources:

The man power required to implement the software is also analyzed with the sufficient
 experience and the technical skills.

D) time and budget:

The total time and the amount of cost that would be incurred in implementing the software.

All the above are analyzed and documented which are considered as project proposals or estimates
 and would be sent to the customer for evaluation.

If customer approves the proposal, then business commit is considered to be completed and the
 implementation phase will be started.

3. Design:

Designing the architecture as well as the interfaces and database is called as design.

This is carried by the design architects, which is done in 2 phases after the requirement collection.

A) HLD ( high level design ) :

It is Also called as architectural design, where the complete application or system architecture is designed.

B) LLD ( low level design ) :

It is Also called as detailed design, where both the interface(user interface), as well as the
 database components are designed.

As part of the interface, the components or the unit in a screen or a page are designed.

As part of back end, the tables required, data types, constraints and relations between the
 tables are designed.

4. Coding:

It is Also called as implementation phase where the set of instructions or source code is 
developed based on the requirements and the design documents.

This is where the static application is converted to dynamic, it is responsibility of a programmer
 to develop the logic(source code)

5. Testing:

After the application is constructed, it should be validated for it's completeness and correctness, 
and the process of doing it is called as testing, where a test engineer, developers, clients, third party
 people are involved.

6. Release and maintenance:

Release:

Is the process of delivering the software constructed and tested to the customer by the vendor 
for further usage is called as release

This is otherwise called as go-live or production.

Maintenance:

It is the support that is extended by the vendor's team, in helping the customer if customer 
faces any challenges in accessing the software for a specific time frame as per the

Initial agreement is called as maintenance.

Cost of defect repair graph:

The cost of fixing the defects will be increased stage by stage, if they are identified early the cost is minimal.

CLASS - 2  -- SDLC Models

• Development life cycle models or process models:

• Based on the customer and the requirements, there can be different approaches in implementing
•  a software application, the approach is know as a model. There are several models proposed, 
• and they can be categorized into two Types:

• One iteration model Or Sequential Model:

• Where all the stages in SDLC are implemented once.

• Waterfall model
• V-model

• Iterative models Or Incremental Model :

• In this all the stages in the SDLC are implemented multiple times in constructing a software application.

• RAD model
• Prototype model
• Spiral model
• Agile model

• One iteration model Or Sequential Model:

• Waterfall model:

• It is Also called as linear sequential model, which was proposed by "royce" in 1970s'

Phases	Who Involved
Requirements Gathering And Analysis (BRS , SRS , FRS )	Business Analyst
Planning (Project Planning & Test Planning )	PM / PL TM / TL
Design ( HLD & LLD )	System Analyst
Coding ( SW-Application )	Developer
Testing ( Bug Tracking & Reporting )	Test Engineer
Delivery & Maintenance	Production Support Team

• All the stages in waterfall model are independent, every stage will commence only after
•  it's previous stage is completed and there is no overlapping between the stages.

• Testing starts only after coding is completed.

• Advantages:
• It is simple and easy to maintain
• It is less expensive
• It Works well if the requirements are static.

• Disadvantages:
• It will not support large applications and the    dynamic requirements.

• V-Model

• In This Model Also All Implementation Activities Will be Carried out one after Another For the Whole Application 
• .This is suitable for small Projects where the requirements are not clear .As the requirements are not clear
•  both static testing and Dynamic Testing are applicable for these model Projects.

• As the Flow of Activities Look like a V Shape it is Titled as “V-Model”. 

• V stands For Verification & Validation

• Phases

• User Requirements
• System Requirements
• HLD
• LLD
• Coding
• Unit Testing
• Integration Testing
• System Testing
• UAT ( User Acceptance Testing )

• Note : 

• 1)we are Conducting Static Testing on 
• User Requirements
• System Requirements
• HLD
• LLD
• 2)we are Conducting Dynamic Testing on 
• Unit Testing
• Integration Testing
• System Testing
• UAT

• Iterative models Or Incremental Model:

• These Models are Recommended Only For Big Projects , Where the Application Development Will be 
• planned Cycle By Cycle.

• RAD ( Rapid Application Development ) model:

• It is also an iterative model, but there would be only one release for all the iterations performed.

• This is preferred for large or complex applications which has to be developed in shorter span of time.

• The application will be split into modules and all the individual modules will be constructed and tested
•  independently for their stability and then grouped(integrated) to form a system.

• Advantages:
• It is used in implementing complex applications in shorter span of time.

• Disadvantages:
• It will not support dynamic requirements
• It requires lot of human resources in implementation
• Defects in integration might take lot of efforts and cost to rectify, as there would be lot of
•  dependency between the features or modules.

• Prototype model:

• Prototype:
• It is structure or the static images or screens which are developed with one or tow features implemented.

• This is also an iterative model
• The prototypes developed by the vendor's team.

• After the feasibility and requirement collection, there would be a prototype developed and it should be
•  evaluated by the customer, if customer approves the prototype, then actual software will be implemented,
•  tested and released to the customer, else the prototype should be redesigned and it should be evaluated 
• by the customer again ,
• This is a continuous process.

• Advantages:

• Probability of high quality software as there would be customer interaction with the
•  s/w before it is constructed.

• Accepts dynamic requirements.

• Supports both projects and products.

• Project:  If You Develop an S/W  Application According to a Client Requirements That Application
•  is Called Project .

• Product :  If You Develop a S/W  Application According to Market Requirements That Application
•  is Called Product.

• Disadvantages:

• Might be expensive in designing multiple prototypes.
• Time consuming factor if multiple prototypes have to be designed.

• Spiral model:

• It is an iterative model, which consists of "risk analysis" phase where a detailed study would
•  be conducted by the "domain" and "technology" experts, in analyzing the risk in implementing 
• the software.

• Risk analysis can be done only after the complete requirements are collected and documented.

• Risk analysis phase will decide whether to continue with further implementations or not.

• Advantages:
• It supports huge complex and mission Critical projects, in which domain and 
• technical implementations are very complex

• It supports dynamic requirements.

• Disadvantages:

• 1. It is a very huge time consuming and    expensive process.
• 2. The success rate of the project is completely    dependent on the risk analysis phase.

• 4)Agile Model or Extreme programming:

• In This Model Requirements Will be Given to the Tester First and Later to the Developer. 
•  Tester Prepare test Prefer ability Automation Test , Soon After a Requirement is Developed. 
• Then test it with the help of already Prepared Test Cases immediately . Based on tester feedback Developer
•  Modify the Requirements if Needed. Then it will be given to the Customer For User Acceptance Testing.

• Rules framed for agile process:

• there should be a build deployed for testing from 1 day to max of 4 weeks.

• B) Every single feature implemented should be  tested, if approved only the new   
•  implementation should be carried out.

• team size should be often between 2 to 6

• D) the development and test teams should be    closely associated and should be effective  
•   communication between the teams.

• Advantages:
• Very widely used in products or multiple release applications.
• Probability of high quality software, due to rigorous testing and effective defect
•  removal at the initial stages of the implementation.

• Disadvantages:
• It is tidies job to perform.
• Very strict deadlines and should be met.
• 3. No chance of proper documentation, due to    strict targets (dead Lines).

CLASS - 3 --

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.

CLASS -- 4

White Box Testing Techniques :

                        Developers will use the Fallowing Two Techniques to Ensure 100% Code Coverage During White Box Testing. They Are

1)Statement Coverage

2)Path /Branch/Condition Coverage

Statement Coverage

                                                            The Percentage Of Statements Exercised During White Box Testing is Called Statement Coverage.

 Statement Coverage = (No.. Of Statements Exercised / Total No.. Of Statements)*100%

Ex 1:

                                    READ A

                                    READ B

                                    IF A>B THEN

                                                PRINT  “A is Big”

                                    END IF

One TC that is a=10,b=5 is Enough to Ensure 100% Statement Coverage For The Above Example. (3/3*100%=100%)

Ex 2:

                                    READ A

                                    READ B

                                    IF A>B THEN

                                                PRINT  “A is Big”

                                    ELSE

                                                PRINT  “B is Big”

                                    END IF

Minimum 2 TC Required ( a=10,b=5 ; a=5,b=10 ) to Ensure 100% Statement Coverage For The Above Example. (3/4*100%=75%)

Path /Branch/Condition Coverage :

                                    The Percentage Of Path Exercised During White Box Testing is Called Path Coverage.

Path Coverage = (No.. Of Path Exercised / Total No.. Of Paths)*100%

Minimum 2 TC Required ( a=10,b=5 ; a=5,b=10 ) to Ensure 100% Path Coverage For The Above Example. (1/2*100%=50%)

Note : 100% Path Coverage will Automatically Ensure 100% Statement Coverage But it is Not Vice Versa.

TC 1 – mon<1      ( Ex – 0 )

TC 2 – mon>12  ( Ex – 15 )

TC 3 -  ( 1 to 12)   ( Ex – 5 )

100% Path Coverage will Automatically Ensure 100% Statement Coverage But it in the above example Try to do  100% Statement Coverage That will not Cover 100 % Path.

Conclusion : As the Path Coverage will Automatically Ensure Statement Coverage , It is the Best Technique to Ensure 100% Code Coverage .

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

Testing Life Cycle Process Implementation:

It Is Categorized Into Two Major Activities

A) Test Design  ( All Black Box Testing Techniques will Cover )

B) Test Execution

Test Design (TC Preparation And Test Data Preparation):

Designing The Test Activities Before The Actual Testing(Dynamic Or System Testing) Is Carried Out.

All The Test Team Members Would Be Involved In Test Design Activities.

As Part Of That The First Activity Performed Is

I) Requirements Analysis:

Which Is Otherwise Called As Requirement Study

Requirement Analysis Is Understanding The Complete Requirements Of The Customer.

During This Stage The Project Requirements Like Business Requirement Specifications(BRS) And The Functional Requirement Specifications(FRS) Are Published In The Project Server, From Where The Team Would Access The Documents.

There Would Be A Knowledge Sharing/Transfer Session Conducted By The Experts(Sme: Subject Matter Experts), For A Better Understanding On The Requirements.

Incase Of Any Clarifications Or Queries Or Conflicts During The Study, These Clarifications Can Be Documented And Posted To The Functional Team Or The Manager Or The Customer For Further Clarification.

Benefits Of Requirements Study:

1. A Complete And Thorough Understanding On The    Requirements By The Team Would Reduce The Risk And Reduce Generating The    Invalid Tests, Which Would Reduce The Risk Of Ambiguity In Test Execution.

2. Will Ensure The Complete Test Coverage With    Respect To The Requirements.

Test Design Techniques:

Techniques Are The Fundamentals In Designing The Tests For Testing A Feature Or A Functionality In An Application.

These Are Predefined And Also Are Called As Black box Test Design Techniques

There Are 5 Techniques Defined For The Test Design In Black box Testing, They Are:

A) Boundary Value Analysis(BVA):

It Is Used to Save the time in Length Testing.

Length Testing : In Length Testing we Have to Test How Many Characters You can Enter Into a Field .

Implementation Of Boundary Value Analysis:

1) Identify The Boundary(S)

2) Every Boundary Generate Three Conditions

   a) Boundary Value

   b) Boundary Value-1

   c) Boundary Value+1

Any Value Or Condition Outside The Boundary Should Be Invalid.

Ex : In Login Page User Name Length Should Be Minimum 4 Characters And Maximum 8 Characters. 

B) Equivalence Class Partitioning(ECP):

It is Used to Save the Time in Value Testing .

Value Testing : In Value Testing we Have To Test What values We Can Enter into Field .

Ex : In Login Page User Name  Should Accept Only

Alphanumeric in Lower Case. 

C) State Transition Testing :

                        Every S/W Application will have various States (User Interfaces or Screens ) . An Application State will Changes From One state to Another Based on Input Data and Operations You Carryout on the System . State Transition Testing Help Full to Check All Possible States of the Application .

Ex :

Prepare TC to Check A Customer Account Access Functionality in ATM Software Using State Transition Testing.

TC1 : Check Customer Account Access By Inserting a Valid Card and Entering Correct Pin at 1^st Try.

TC2 : Check Customer Account Access By Inserting a Valid Card and Entering Wrong Pin at 1^st Try and Entering Correct Pin at 2^nd  Try.

TC3 : Check Customer Account Access By Inserting a Valid Card and Entering Wrong Pin at 1^st  and 2^nd Try and Entering Correct Pin at 3^rd Try.

TC4 : Check Customer Account Access By Inserting a Valid Card and Entering Wrong Pin at 1^st  , 2^nd and 3^rd Try.

TC5 : Check Customer Account Access By Inserting a Invalid Card.

D) Decision Table Testing :

                        It is Help Full to Determine Defects Because of Mistakes Committed While specifying the Logical Operators in Code.

                        Decision Table Testing is Help Full to Ensure 100% Test Coverage when a Functionality is Depending on Multiple Inputs. According to Decision Table Testing Number of TC You Prepared to Ensure 100% Coverage in 2ⁿ Where n is number of Inputs.

As Per Decision Table Testing You Can Derive the Fallowing TC to Check Login

TC1 : Check Login with Valid username And Valid password.  

TC2 : Check Login with Valid username And Invalid password.

TC3 : Check Login with Invalid username And Valid password.

TC4 : Check Login with Invalid username And Invalid password.

Decision Table For Login

Inputs	Cond 1	Cond 2	Cond 3	Cond 4
User Name	Valid	Valid	Invalid	Invalid
Password	Valid	Invalid	Valid	Invalid
Results	Display Inbox	Display Error	Display Error	Display Error

E) Use case Based Testing:

The Tests Developed Based On The Use Cases. In A Usecase A Functionality Or Feature Would Be Described With Both Primary Flow(Positive Flow) Of Events And The Alternate Flow(Negative Flow) Of Events.

For Every Possible Positive Flow And Negative Flow, There Should Be A Test Defined.

Note: Often We Perform Use case Based Testing If The Use cases Are Available.

Use Case:

A Use Case Is A Sequence Of Steps With The Complete Set Of Primary Flow Of Events Along With The Alternate Flow Of Events Documented For A Given Requirement.

                                                                       

( It is a Brief Description Of Actor Actions and System Responses )

Use cases Can Be Part Of Functional Requirement Specifications, Use case Are Prepared By The Requirement Collection Team.

Benefits Of Use Cases:

1. Use case Gives A Complete Understanding On The Functionality Or A Requirement

2. They Are Considered To be The Powerful    Sources For Designing The Test Cases

3. Complete Coverage In Testing Can Be Achieved    Based On The Use Cases.

Use case Template:

Use case Number:

 It Is An Unique Identifier Of The Use Case

Ex: Uc 1.0

Use case Name:

Ex: Payments

Actor:

The User Involved In Performing That Feature Or Functionality On The System

Action Performed:

The Operation Performed On The System By The User

Ex: Enter User Name In Login Page

Primary Flow:

All The Positive Set Of Events In Performing The Above Identified Transaction, It Consists Of The Complete Navigation With A Proper Start And End Positions In Achieving That Functionality Along With The System Responses And Validations.

Alternate Flow:

The Negative Set Of Events In Performing That Functionality.

Error Conditions:

The System Responses For The Alternate Flow Of Events Performed.

Author:

The Person Responsible For Designing The Use case

Priority:

It Defines The Importance Of The Use case, Generally It Is Categorized Into Three:

High, Medium And Low

The Tests Are Designed Based On The Priority Of The Use Case.

Date:

Date On Which The Use case Is Derived.

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

Test Scenario:

It Is Low Level User Requirement Or A Test Condition Or A Lowest Component Of A Requirement Which Cannot Be Split Any Further.

Test Scenarios Are Documented In A MS Word Or An Excel Document, Where Every Test Engineer Is Involved In.

Test Scenarios Are Identified After The Requirement Study In The Test Life Cycle Process Implementation.

The Inputs For Identifying The Test Scenarios Are Business And Functional Requirement Specifications.

Benefits Of Test Scenarios:

1. Will Ensure The Test Coverage With Respect To The Requirements.

2. Will Give An Estimate Of Number Of Tests To be Derived For A Given Feature Or Functionality.

CLASS -- 5

STLC

Phases	Description
Test Planning	Prepare Test Strategy & Test Plan ( Prepared By Project Manager or Test Manager )
Test Analysis	Study BRS & SRS ,If Any Questions Documented in RCN (Requirement Clarification Note) Send To BA  or SME
Test Design	Identify Test Scenarios & Prepare TC  And Prepare Traceability Matrix
Test Execution	Dev will Release Build to Testers, TE will Execute TC on Build  & any defects Found Then Send It to Dev, Dev Fix The Defect and Modified Build Released To Testers
Test Closure	Test Lead or Test Manager Prepares  Various Test Summary Reports which has to Be Submitted to the Client.

Test Planning :

                                    Once a Project is Initiated For Testing at First a Project Manager will Define
 a High Level Plan And Approach For Testing

The Application Called Test Strategy. From The Test Strategy a Detailed Plan and Approach will Be 
Derived By Test Lead Or Test Manager is Called Test Plan.

Test Analysis :

                                    In This Phase Testers will Study Various Customer Requirement and
 Project Specification Documents to Understand the Business Requirements of the System. While
 Analyzing The Requirements if There is Any Questions that will be Documented in RCN 
(Requirement Clarification Note) it will Be Send To Domain Experts or BA To Get The Clarifications.

BA Will Give Clarifications For the Posted Questions And Send it Back to The Testers.
 You Can Also Initiate For Walk Through, If Still There are Queries.

Test Design :

                                    In This Phase Testers will Identify What are all the Various Functionalities 
To Be Tested Called Test Scenarios and Document The Same. Then TC and Test Data Prepared
 For Identified Test Scenarios , These TC will Be Send To Lead For Review and Also To Prepare 
Traceability Matrix .      

Test Execution :

                                    In This Phase at First Developer will Release Build To Testers And
 It Will Be Deployed in Test Environment . On The

Deployed Build Testers Will Conduct Testing And Defects Identified Will Be Recorded 
And Send It to Developer . Now Developer Fix The Defects Then The Modified Build Will Be Release
To Testers For Retesting , Now Testers Will Conduct Retesting To Confirm Bug Fixing And Also To
 Determine The Side Effects . If Any New Defects Are Identified , That Defects will Be Documented
 And Reported To Developer. These Cycles Will Be Continued Until All Major Defects Are Fixed And Closed.

Test Closure :

                                    It is The Last Phase In STLC where a Test Lead Or Test Manager Prepares Various Test Summary Reports which Has To Be Submitted To The Client. Now The Project Will Be Delivered To Customer For User Acceptance Testing. Once The UAT is successful , Then Project Enters Into Maintenance Phase where Production Support Team Takes Care Of Project Maintenance.  

CLASS -- 6

Environment:

It Is A Collection Of Resources, Like Hardware, Software And The Network Resources.

Architecture:

It Is The Interfaces Or Layers With Which A System(Software) Is Constructed.

There Are Different Architecture:

A) One Tier Architecture:

In This Case The Application And The Server Resides In The Same System.

These Are Generally Considered As Desktop Based Applications.

Ex: Ms Office, Windows Calculator, Media Player, Web Browsers..

Advantages:

1. They Are Fast And Reliable.

2. Security Is High.

Disadvantages:

1. Resources Cannot Be Shared In These Types Of Applications.

B) Two Tier Architecture:

In This The Server Is Split From The Client Machine And There Are Two Layers, Application/Business
 Layer And Database Layer

There Can Be Multiple Clients Connected To A Server Machine In A Network Generally With 
LAN(Local Area Network)

They Would Be Connected With A Topology Which Can Be Star, Bus, Mesh, Tree, Token Ring....

These Systems Are Often Called As Windows Based Applications Or Client/Server Applications

Ex: Oracle, Sql Server, Visual Source Safe...

Advantages:

1. Sharing Of Server Resources Is Improved.

2. Performance Is Good.

3. Security Is Good As No New Terminal Would Be Accessing The Server

Disadvantages:

1. Larger Networks Are Not Possible

2. The Complete Network Is Dependent On The Server Machine.

C) Three Tier Architecture:

These Are Latest Applications Where The Complete system Is Split Into Three Layers.

1) Interface Layer: First Layer Where The User Will Be Interacting With The Application

2) Middle Layer: This Is The Application Server Where The Application Logic Or Business Logic
 Is Present And Which Works As An Interface Between The Front Layer And The Database Layer.

3) End Layer: Which Is A Database Layer.

In The Interface Layer, There Should Be A Client Program(Web Browser), Installed To Interact
 With The Application, All The Requests Would Be Sent In The Form Of Http(Hyper Text Transfer Protocol).

To Process These Requests There Should Be A Web Server Installed, Which Acts As An Interface 
Between The Application Server And The Client.

Ex: Web servers:

      IIS(Internet Information Server)

      Tomcat, Apache, Web sphere,...

Advantages:

1. Sharing Of Resources Across The Networks

2. It Can Have Very Large Networks.

Disadvantages:

1. Security Is A Concern In Web Based    Applications

2. There Can Be Performance Issues In Web Based

D) N-Tier Architecture:

It Is An Extension To The Web Based Application, Having Multiple Apps Servers And The Database
 Servers To Balance The Increasing Loads.

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

There Can Be Three Environments For Any Given Application:

1) Production Environment:

This Is Otherwise Called As Live Or Client Or Customer Environment, Which Is The Regional 
Environment Based on Which Two Other Environments Are Created

2) Development Environment:

The Environment That Is Created With The Same Set Of Resources Of The Customer Environment
(Which Is Closely Simulated To Customer Environment), For The Development Activates.

3) Test Environment:

Otherwise Called As Demo Or Stage Or QA Environment, Which Is Also A Closely Simulated Environment 
To The Production Environment, Where The Testing Activities Are Carried Out.

Deployment:

The Process Of Moving The Build From Development Environment To The Test Environment For
Further Testing.

Development Team Is Responsible For Developing The Build And Also For The Deployment Process.

Note: Test Lead Might Be Part Of The Deployment Process.

Deployment For Desktop/Client-Server Based Applications:

In This Case The Application Code Is Converted Into An Executable File And The Setup File Be
 Placed In The Project Server Of Test Environment, Where The Test Engineers Will Access And
 Install The Application In Every Individual Machine.

Deliverables:

SRN(Software Release Notes)

DD(Deployment Document)

Installation Document

Unit Test Report

Deployment For Web Based Applications:

The Application Logic/Source Doc(Files) Will Be Merged In The Apps Server Of The Test
 Environment Form The Development Environment.

The Test Team Will Access The Application Based on The "Url" That Is Provided By The Deployment Team.

Deliverables:

SRN(Software Release Notes)

DD(Deployment Document)

Unit Test Report

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

Test Environment Set Up:

Setup Of The Hardware And Software Needs By The Test Team To Accept The Build For Further Testing.

As Part Of This Testing Team Have To Ensure The Software Requirements Like O/S, Browsers, 
Databases, Other Tools And The Access Privileges To All The Servers.

Test Execution Plan Has To be Prepared By The Test Lead On The Build That Is Deployed, Like 
Planning Of Resources, Time Required, Features To be Tested And The Template Or Rafts For The
 Test Execution Reports.

Test Set: It Is A Collection Of Test Cases, Which Has To Be Done, Based On The Build That Is
 Deployed For Testing.

Test Plan:

It Is A Planning Document That Is Prepared At Very initial Stage Of The Test Process Implementation.

A Test Plan Defines The Scope For Testing, Objective, Resources Required, Timelines To be Followed 
Along With The Test Management Documentation.

Test Plan Is Generally Prepared By The Experienced Person Or Team Like Test Lead, Analyst Or Test Manager.

The Inputs Required For Test Plan Are Requirements And Project Plan.

This Can Be Drafted In A Word Document Which Should Approved Prior To Implementation Of Any 
Test Activity In A Given Project.

Contents of Test Plan:

1.0 Objective

2.0 Scope

                        2.1 In-Scope

                                                - Features To Be Tested

                        2.2 Out Scope

                                                - Features Not To Be Tested

3.0 Approach

                        3.1 Test Analysis Approach

                        3.2 Test Design Approach

                        3.3 Test Execution Approach

                        3.4 Test Management Approach

4.0 Resources

                        4.1 Hard Ware Resources

                        4.2 Software Resources

                        4.3 Human Resources

                                    Ex :

                                               

Id	Resource	Role
1	Ramesh	TM
2	Suresh	TL
3	Kiran	TE

  

5.0 Schedules

                                   

Id	Task Item	Responsible	Planned Hours
1	TC Design For Login	Suresh
2	TC Execution For Login	Kiran
-- --	------- -------	------- -------	------- -------

6.0 Risks & Mitigation (Solution)

                                   

Id	Risk	Mitigation
1	Resources May Take Off / Leave Organization	Minimum 30% Bench Resources Should Be Available
2	Resource May Not Have Sufficient Knowledge On Project Domain	They Should Be Taken Training Sessions .
-- --	------- -------	------- -------

7.0 Entry Criteria & Exit Criteria

                        7.1  Entry Criteria

                                    Ex ( Entry Criteria For System Testing )

                                                1) 100% Unit And Integration Testing Should Be Success Full

                                                2) All Customer Requirements Should Be Based Line.

                                                3) TC Prepared Should Be Review And Approved.

                        7.2  Exit Criteria

                                    Ex ( Exit Criteria For System Testing )

                                                1) All Major Defects Should be Fixed And Closed.

                                                2) All Test Cases Should Be Executed successful And Passed

CLASS -- 7

BRS Template

1.0      Introduction

1.1          Customer/Client  Introduction

1.2          Project Introduction

2.0          Existing System

3.0          Draw Backs in Existing System

4.0          Proposed System

5.0          System/Project Architecture

6.0          Business Requirements

Req  Id	Req Description
Req 1	Login
Req 2	Customer Registration Deposits , with Draws….

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

FRS Template

1.0          Over View

2.0          Prototype

3.0          Page/Form Elements

Id	Element Name	Element Type
1	User Name	Text Box
2	Password	Text Box
3	Submit	Button

4.0          Input Validation & Error States Business Rule

Id	Element Name	Validation	Error State
1	User Name / Password	1.Mandatory 2.Alpha Numeric Only 3.Min 4 Char & Max 10 Char	Blank : Unm/Pwd Should Not Blank Invalid : Invalid Unm / Pwd

5.0          Use Case Diagram

                                                Enter Valid Username and PWD                        

Enter URL-->Display login page---------------------------------->Display input box page.

6.0          Use Cases

Id	Actor Action	Sys Response
1	Enter URL	Display Login Page
2	Enter Unm / Pwd & Click On Submit	Display Inbox

 CLASS -- 8

Requirement Clarification Note (RCN)

It is a Process Template Where You Record Your Questions And Quires While Analyzing The Requirements.

RCN Template

Requirement Clarification Note
Project Name			SOMS
Module Name			Sales
Prepared By			xxxxxxxx
Prepared Date			xx/xx/xxxx
#	Requirement Spec..Ref	Clarification Required		Clarification Provided	Clarification Provided By	Clarification Provided Date
1	SOMS_Sales_ SRS_V1.1/pgNo 40/4.2 Business Validations	Discount % For Sales Order If Below 1000 Rs		Discount % is Not Applicable	<Name of Author>	<xx/xx/xxxx>
-- --	------ ------	------ ------		------ ------	------ ------	------ ------

CLASS -- 9 Test Scenarios:

Test Scenario

it is  a Functionality To Be Tested In The Application Is Called Test Scenario.

Test Scenario Template

Test Scenario
Project Name		SOMS
Document Reference		Use Case
Author		Jyothi		Reviewed By		Test Lead.
Prepared Date		xx/xx/xxxx		Reviewed Date		xx/xx/xxxx
Test Scenario Id	Module		Requirements		Test Scenario
TS00.1 TS00.2 TS00.3 TS00.4 TS00.5 TS00.6 TS00.7	Agent Agent Agent Agent Agent Agent Agent		Agent Login Booking a New Ticket Updating a Ticket Deleting a Ticket Send Fax Agent Order Report Order Graph		Verify Agent Login Verify Booking a New Flight Ticket For A Passenger From Various Origins To Various Destinations. Verify Modification Of Number Tickets Or Passenger Name Or Class… For a Booked Ticket. Verify Cancellation Of a Ticket Verify Sending Fax Verify Agent Order Report Verify Order Graph
-- --	------ ------		------ ------		------ ------

CLASS - 10 TEST CASE

Test Case

A Test Case Is A Set Of Steps Or Sequence Of Steps With The User Actions Performed And The
 Response From The System Documented To Validate A System.

Test Cases Are Derived From The Requirements And Use Cases.

Test Engineers Are Responsible In Deriving The Test Cases After The Test Scenario Identification.

Test Cases Are Often Prepared Or Documented In Word Or An Excel Document.

Qualities Of Good Test Case:

1. Every Test Case Should Be Simple , Clear And    Understandable.

2. Every Test Case Should Be Unique ( No Redundancy)

3. Every Test Case Should Follow A Naming Convention.

4. Every Test Case Should Have A Proper Start And End Positions.

5. Every Test Case Should Be Consistent And Should Be Documented In The Standard Template

6. Every Test Case Should Be Traceable To The Requirement.

7. There Should Not Be Any Missing Links In A Test Case.

Fields in Test Case Template:

1. Project

2. Module

3. Created By

4. Created On

5. Reviewed By

6. Reviewed On

7. Documents Referred

8. Test Case Id/Name:

It Is The Identifier For The Test Case, It Should Be Unique and It Should Follow A Naming Convention.

Ex: Tc01_Project_Module_Functionality

9. Test Case Description:

It Describes The Objective Or Purpose Of The Test Case

Test Case Id And Test Case Description Are Unique For The Entire Test Case.

10. Step Name:

It Is A Step Identifier, Which Is Unique For Every Operation Performed.

It Is A Collection Of At least One Action Performed And The Subsequent Response From The System.

Ex: Step1

    Step2

    Step3...

11. Step Description:

It Is The Action Performed By The User On The System

12. Test Data:

It Is The Input Required To Perform The Operation On The Current Step.

In Test Case, We Identify The Data Required To be Generated To Execute The Test Case.

13. Expected Result:

It Is The Expected Behavior Of The System Based On The Operation Performed As Per The Requirements.

14. Priority:

It Defines The Importance Of The Test Case, This Is Derived Based On The Complexity Of The 
Functionality, Which Is Often Categorized Into Three,

High, Medium And Low

Note: The Test Execution Process Is Carried Out Based On It's Priority, All High Priority TC Should 
Be Executed First Then Medium And Then Low.

15. Review Comments:

The Deviations Or Changes That Were Identified During The Review Phase By The Reviewer.

CLASS -- 11

Smoke Testing : It is a Kind Of Quick Test Conducted On Diployed Build To Determine
 Does The Application Is Eligible To Continue Test Or Not.

   Smoke Testing Is Also Called Build Acceptance Testing (BAT) And Also Build Verification
 Testing (BVT)

Sanity Testing : A Quick Test Conducted At Production Environment To Determine Does 
The Application Is Testable By End User or Not For UAT.

Patch : After Smoke Testing If The Application is Failed Then Developer Will Modify 
The Application , That is Not A New Build , It is Called Patch.

Formal Testing : Testing Conducted On The Application By Fallowing Systematic 
Procedures Is Called Formal Testing.

Retesting : Testing a Functionality Redundantly Or Testing A Functionality Again 
And Again Is Called Retesting . Retesting Is Also Called Confirmation Testing .

Retesting Comes In Fallowing Scenarios :

1)      Testing A Functionality With Multiple Inputs.

2)      Testing A Functionality After Bug Fixing .

3)      Retesting Starts Right From The 1^st  Build

Regression Testing: Re-Running Or Re-Executing The Selective TC For The Dependent
 Functionality On Modified Build Is Called Regression Testing.

                             Regression Testing Is helpful To Determine the Side Effects Because
 Of The New Functionality Added In The Modified Build .

Note:

1)     Regression Testing Also a Part Of Re Testing

2)     Re Testing Starts From 1^st  Build

3)     Regression Testing Starts From Modified Build.

Informal Testing Or Adhock Testing : If You Test A Application With Out Fallowing 
Any Procedures ( As You Wish ) Then It Is Called Informal Testing.

Informal Testing is Helpful To Determine Tricky ( Zigzag ) Defects From Application 
And Also To Conduct Testing If Their Is No Time To Develop TC

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

 

Special Testing Tags In Functional System Testing :

1)      Exploratory Testing : Exploring The Application And Adding Or Modifying TC For Better 
Testing Is Called  Exploratory Testing.

Exploratory Testing Is Applicable If The Existing TC are Not Helping In Finding Good Defects.

2)      Error Guessing : With The Prior Knowledge And Experience The Testers May Guess 
The Error In Application Which Is Called Error Guessing .

3)      Mutation Testing : It is a Process Of Wantedly Injecting The Defects In Order To 
Confirming Does The Testers Are Properly Testing A Application Or Not.

4)      Monkey Testing ( Or ) Rattle Testing : Testing The Application With Zigzag Procedure
 Is Called Monkey Testing ( Or ) Rattle Testing.

5)       End To End Testing :

It Is A Process Of Verifying Overall Functionalities And Their Data Integration Right From
 The Beginning To The End.

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

Non Functional System Testing Types :

After completion of functional testing successfully, the testing team is concentrating 
on non-functional testing. During non-functional testing, the testing team is concentrating
 on customer expectations or software characteristics.

1)     UI Testing : Verifying The User interfaces Of The Application To Confirm Does The 
Application Looking Professionally Or Not Is Called UI Testing.

Check List For UI Testing   :

1)     Check For Availability Of Objects.

2)     Check Spelling Of Objects

3)     Check Alignments Of Objects.

4)     Check For Consistence in BgColor , Fore Color,Font Type, size………

2)     Usability Testing : Verifying How Well The End User Is Able To Understand The System
 and Use It Is Called Usability Testing. In Other Words Verifying The User-Friendliness Is 
Called Usability Testing.

3)     Security Testing :Verifying Does All Security Conditions Are Properly Implemented Or 
Not Is Called Security Testing.

Check List For Security Testing   :

1)     Check For Access Control (Authorization ) :

Verifying Does The System Is Having A Provision Of Defining Users And Setting
 Permission Is Called Authorization Testing

2)     Check For Authentication :

Verifying Does The System Is Able To Identify The Registered Users And Weather 
It Is Displaying The Right Info To Right User Is Called Authentication Testing .

3)     Check Does Critical Info Such As Unm , Pwd And Credit Card Numbers Are Getting 
Encrypted Or Not.

4)     Check  Direct URL Access.

5)     Check For Session Expiry .

6)     Check The Browser Navigation ( Back Or Forward Navigation After Session Out ).

4)     Performance Testing : Verifying Or Analyzing Various Efficiency Characteristics as A System
 Such As Response Time , Load , Resource Consumption …..

5)     Compatibility Testing : Verifying Does The Application Is Compatible With Different HW And 
SW Environments Such As OS Compatibility , Browser Compatibility Is Called Compatibility Testing .

6)     Recovery Testing : Verifying Does The System Is having A Provision Of Back Up And Restore
 Options Or Not , And Also Verifying How Does The System Is Handling Unexpected Situations 
Such As Power failures & System failures .

7)     Installation Testing : Verifying Are We Able To Install The Application Successfully Or Not
 As Per The Guidelines Provided In Installation Document.

8)     Un Installation Testing : Verifying Are We Able To Un Install The Application Successfully 
Or Not is Called Un Installation Testing .

9)     Globalization Testing : Verifying Does The System Is Having A Provision Of Setting Multiple
 Regional  Settings Like Multiple Languages , Date And Time Format And Currency … If It Is 
Designed For Global Users Then It is Passed in Globalization Testing .

10)   Localization Testing : Verifying Does The System Is Having A Provision Of Setting Multiple 
Regional  Settings Like Multiple Languages , Date And Time Format And Currency … If It Is
 Designed For Particular Locality Of Users Then It is Passed in Localization Testing .

          

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

Functional Testing: It’s a mandatory testing level, during this Test the testing team is 
validating a software build functionality in terms of below factors with respect to customer
 requirements.

   1. Behavioral / GUI:The changes in properties of Objects OR controls in a software is
 called behavioral or GUI.

   2. Input Domain: Whether the Objects are taking correct type and size of inputs or not?

   3. Error Handling: Whether our software is preventing wrong operations or not?

   4. Manipulations: Whether our software is generating correct output or not?

   5. Database Validity: Whether our software front end screens operations are correctly
 impacting on database of the software or not?

   6. Sanitation: Finding extra operations in a software with respect to customer requirements.

The above factors checking on a software is called as functional testing. During this checking the testers are using black box testing techniques or closed box testing techniques.

Bug life Cycle

                                                          Soon After a Tester Identify The Defect ,It Will Be Recorded in a Bug Report Template Or Bug reporting Tool with The Status New. All New Defects Will Be Reported To Developer , Now Developer Will Analyze Defect For Conformation . If Reported Defect Is Invalid Then Developer Assign The Status As Rejected . Rejected Defects Will Send Back To Tester .If Reported Defects is Valid Then Developer Will Set The Status as Open .If Defect Information Is Not Clear Then Developer Assign The Status as Hold and Communicate To The Tester To get More Info About Defect .If a Defect is Postponed To Next Phase Then Developer Assign The Status as Differed . If The Defect Is Already Reported Then Developer Assign The Status as Duplicate . Once The Defect Analysis Is Made Developer Starts Fixing Defects Based On Defect Priority . Soon After a Defect Is Fixed Developer Assign The Status as Resolved .Once All Major Defects Are Fixed Then Modified Build Release To Tester For Re-Testing . If The Defect Is Properly Fixed In Modified Build Then Tester Specify Status As Closed , If not  Properly Fixed Then Tester  Will Re-Open The Defect And Send Back To Developer . If A New Defect Is Identified In Modified Build It Will Be Recorded with The Status New And The Same Cycle Will Be Continued .    

CLASS -- 12

Defect / bug Report

Defect / bug Report Fields :

Project Name :

Date Of Closure :

Defect Id

Defect Description

Reproducible ( y/n )

Reproducible Steps

Defect Severity

Defect Priority

Defect Status

Detected By

Detected Date

Detected In version

Fixed By

Fixed Date

Defect / bug Report Template

Project Name

Date Of Closure

Defect   #

Defect Desc

Reproducible   (Y / N )

Reproducible Steps

Defect Sev

Defect Pry

Defect Status

Detected By

Detected Date

Detected In Version

Fixed By

Fixed Date

  

Reproducible : If Defect Is Occurred Every Time Or If You Are Able To See A Defect Every Time Then 
It is called Reproducible Defect. If a Defect Is Reproducible , Specify The Steps To Produce The Defect 
Which Helps Developer For Analyzing And Fixing Defect.

                                    If A Defect Is Not Reproducible The Capture The Screen Shot Of the Defect And
 Send To Developer.

Defect Severity : The Impact Of The Defect Or How Serious The Defect is in The System Is Called Defect Severity .

Different Defect Severities :

Org1	Org2	Org3	Severity Description
S0	Fatal	Very High	Run Time Errors And Show Stopper Defects .
S1	Major	High	A Defect Which is Non Conformance To Requirement.
S2	Minor	Medium	A Minor Problem Which May Not Have Much Impact On Business
S3	Low	Low	UI / Usability Defects & Suggestions .

  

Show Stopper Defects  : A Defect Which Will Not Permit Us To Continue The Test .

Note : Defect Severity Will Be Assigned By Tester .

Defect Priority : the Order In Which The Defect has To be Fixed Called Defect Priority.

Different Defect Priorities :

Org1	Org2
P0	Very High
P1	High
P2	Medium
P3	Low

Note : Defect Priority Will Be Assigned By Development dept

( Generally Project Lead will assign Defect Priority ) 

Note : In Generally Defect Severity And Priority Propositional To Each Other. In Some Situations Low 
Severity Defect Takes High Priority And High Severity Defect Takes Low Priority.

 

Ex For Low Severity Defect Takes High Priority :

In Correct Logo Or In Correct Company Title.

Ex For High Severity Defect Takes Low Priority :

A Serious Defect In Future Release Module.

Defect Status : It Indicates the Current Status Of The Defect in Defect Life Cycle .

Defect Age : The Time Interval Between Date Of Detection And Date Of Closure In Other Words How Long
 A Defect Is Exist In Bug Life Cycle Is Called Defect Age .

Data Base Testing

Note : It is a Functional Testing

Verifying Of Various Operations Such As Additions , Modifications And Deletions Performed In Front End And 
Back End . Verification Of Database Design Such as Data Type , Field Lengths , Constraints And Also Verifying 
SQL Scripts Such As Stored Procedures And Triggers Is Collectively Called DB Testing.

Necessity Of DB Testing :

In General A Tester Will Confirm The Functionality By seeing The Appropriate Messages Displayed By ( AUT ) 
Application . 

If The Application Is Displaying a Successful  Message Then Tester Assumes That The Functionality Is Justified In 
The System.

But This Message is A Programming Technique Not a Conformation From The DB . So It Is Not a Guarantee That
 The Data Is Really Storing At DB , In order To Confirm That DB Testing Is Required .

Software Configuration Management Tools

VSS ( Visual Source Safe ) – Product Of Microsoft

CVS ( Concurrent Version System ) – Product Of Sun Micro System

Common Repository : A Dedicated Centralized Computer System Where You Can Store And Manage Various
 Project Resources Such As Test Plan , BRS , SRS , TC , Test data , Build … Is Called Common Repository.

Software Configuration Management :

Recording And Managing All Project Resources in Centralized System And Managing The Versions Based 
On Changes Made To Them Is Called Configuration Management .The Most commonly Used Configuration
 Management Tools Are VSS , CVS .

Benefits Of Common Repository :

1)To Maintain Back up Of Project Resources .

2)To Share Info Among The Team .

3)To Maintain The Project Status .

To Maintain Version Controlling .

Test Management

Test Management Includes Requirement Management , Change Management , Version Controlling , 
Test Planning , Risk And Mitigation Planning And Defect Management .

1) Requirement Management : Soon After Business Requirements  Collected From Customer , 
All This Requirements Properly Documented With Unique Requirement Id And Appropriate Description . 
While Documenting The requirement We Have To Fallow The Documentation Standards ( IEEE829) ,
 And Also Every Document Should Fallow An Appropriate Naming Convention

“ ProjectName_MaduleName_DocumentName_VersioNumber”.

2) Change Management : If There Are Any Changes In The Business Requirement At First Changes Requested
 By The Customer Should Be Documented As Change Requirement And The Change -Requirement Should Be Sent 
To CCB ( Change Control Board ) . Once A Change Requirement Is Approve By CCB , Based On Change Requirement 
We Have To Modify The Existing Documents .

3) Version Controlling : Every Initial Draft Should Fallow The Version Number As 1.0 After Implementing 
The Change Requirement . You Have To Maintain The Appropriate Version Number . If There Are Minor 
Changes Increment The Decimal Number For Version Number , If Changes Are Major Increment The Integer Position .

4) Test Planning : It Includes Defining High Level And Detailed Plan And Approach In order To Test 
The Application To Meet The Objectives .

5) Risk And Mitigation Planning : Identifying The Possible Risk And Defining The Appropriate Mitigation 
To Handle The Risk For Smooth Running Of Test Execution .

6) Defect Management : Establishing A Set Of Procedures For Documenting The Defects Which Helps In 
Monitor Defect Status At Any Point Of Time .

        

Traceability Matrix

Mapping Between TC And Requirements Is called Traceability Matrix.

Traceability  :  The Ability Of Identifying A Batch Of TC Belongs To A Particular Requirement Is Called Traceability .

Traceability Matrix Template :

Traceability Matrix
Project		Project Manager
Prepared By		Reviewed By
Prepared On		Reviewed On
Last Updated On
Traceability Id	Requirement Id / Description	Use Case Ref	Test Scenario		Test Case Ref

 Advantages Of Traceability Matrix :

1)      A Traceability Document is Helpful To Determine The 100 % Of Test Coverage.

2)      To Declare A Group Of TC That Belongs To A Particular Requirement  Which Helps In Implementing 
The Change Requirement in Easy Way And Also To Select The TC That Belongs To a Requirement For 
Modified Builds Execution .

Manual Testing Concepts Introduction to Software Testing Software Development Life Cycle (SDLC) SDLC Models Levels of Dynamic Testing Dynamic Testing Approach or Methodologies Static Testing Technique Dynamic Testing Technique Black Box Testing Technique Software Testing Life Cycle (STLC) STLC Templates Test Case Preparation Bug Reports Data Base Testing Web Application Testing Bug Life Cycle , Cycle Test Management Software Configuration Management Test Management   

Quality Assurance Test Cases
Company Confidential                                Copyright @ 2006 MindQ Systems
Project name		E_BANKING
Module		ADMIN
Document References		FRS,TESTPLAN DOCUMENT
Author		Ramesh K
Test Case ID/Name	Test Case Description	Step Name	Test Data	Step Description	Expected Result	QCPath
TC001_E_banking_Admin_RanfordHomePage_Visitorlinks	This test case is to validate visitor links available in ranford home page	Step1	URL	Enter valid URL and click on go	system should display ranford home page	EBANK\RF HOMEPAGE\VISITOR LINKS
		step2		clicks on Home	System should display home page with login facility.
		step3		clicks on Personal Banking	System should display information and services offered for Personal banking.
		step4		clicks Corporate Banking	System should display information and services offered for Corporate banking
		step5		clicks About Us	System should display information about Ranford Bank.
		step6		clicks Customer Service	System should display Customer Service information
		step7		clicks Internet Banking FAQ’s	System should display the information about internet banking FAQ’s
		step8		clicks Privacy	System should display Privacy commitment of Ranford Bank
		step9		clicks Terms & Conditions	System displays information about online banking terms and conditions.
		step10		clicks Disclaimer	System displays the notice and copyrights of this site.
		step11		clicks site map	System displays site map about this site