30
Quality Quality means satisfaction of the customer to define good quality of Software, the company people will concentrate on two (2) factors such as 1) Technical factor and 2) Non-technical factor. 1. Technical factor a. Customer requirements in terms of functionalities. b. Customer expectations (Look and feel, Ease of use, right output, speed of processing, security) 2. Non-technical factor a. Low cost to purchase b. Time to market. S.Q.A (Software Quality Assurance) It means monitoring and measuring the strength of development process. REQUIREMENTS GATHERINGS Business Development People / Business Analyst Business Requirement Specification (BRS) / User Requirement Specification (URS) / Customer Requirement Specification CRS ANALYSIS – Analyst (Software Requirement Specification) DESIGN Designers (Design Document) CODING (Programmers) PROJECT MANAGEMENT (Release and Maintenance) TESTING (Testers) FRS (Functional Requirement Specification) SRS (System Requirement Specification) HLD (High Level Design Document) LLD (Low Level Design Document)

Manual Testing Final Notes

Embed Size (px)

Citation preview

Page 1: Manual Testing Final Notes

Quality

Quality means satisfaction of the customer to define good quality of Software, the company people will concentrate on two (2) factors such as 1) Technical factor and 2) Non-technical factor.

1. Technical factor a. Customer requirements in terms of functionalities.b. Customer expectations (Look and feel, Ease of use, right output, speed of processing, security)

2. Non-technical factor a. Low cost to purchaseb. Time to market.

S.Q.A (Software Quality Assurance)

It means monitoring and measuring the strength of development process.

REQUIREMENTS GATHERINGS

Business Development People / Business Analyst

Business Requirement Specification (BRS) / User Requirement Specification (URS) / Customer Requirement Specification CRS

ANALYSIS – Analyst (Software Requirement Specification)

DESIGN – Designers (Design Document)

CODING (Programmers)

PROJECT MANAGEMENT (Release and Maintenance)

TESTING (Testers)

FRS (Functional Requirement Specification)

SRS (System Requirement Specification)

HLD (High Level Design Document)

LLD (Low Level Design Document)

Page 2: Manual Testing Final Notes

1) REQUIREMENT GATHERINGS

In general software development starts with requirement gathering. In this stage Business Development People (BDP) / Business Analyst People (BA)are preparing Business Requirement Specification Document (BRS) / User Requirement Specification Document (URS) / Customer Requirement Specification Document (CRS), after gathering all required requirements from the user / customer. Business Requirement Specification Document defines the requirement of the customer.

2) ANALYSIS

After completion of Business Requirement Specification Document , Analyst People are preparing “Analysis Document”. This document is also called as “Software Requirement Specification Document” (S/w RS). The document consists of (2) Sub documents such as FRS & SRS

(i) FRS - It means “Function Requirement Specification”. It defines the required functionality to be used in the project.

(ii) SRS - It means “System Requirement Specification”. It defines the required Hardware to develop that functionality.

3) DESIGN

After completion of Analysis Document, Designers are preparing Design Document. It consists of (2) sub documents, such as (i) HLD & (ii) LLD

(i) HLD (High Level Design Document)

It is also called as External Design Document. It defines the hierarchy of overall application functionalities in terms of modules from root level to leaf level.

(ii) LLD (Low Level Design Document)

It is also known as Internal Design Document. It defines the internal logic of every functionality or module in terms of ER Diagrams, Data Flow Diagrams.

Page 3: Manual Testing Final Notes

Note: A Project will have one HLD and Multiple LLDs

4) CODING

A Physical construction of Software is called as “Coding”.

Build: An executable form of all integrated module set is called “Build”.

Page 4: Manual Testing Final Notes

5) TESTING

In this stage, the testers are validating that developed Build with respective Customer requirements and customer expectations.

6) RELEASE AND MAINTENANCE

After completion of software testing the Project Management will deliver that software to customer for usage. During utilization of the software, if customer get any problem or if customer want to enhance the application, that can be handled by the company people.

Q1. What is the difference between Software Product and Software Application?

Answer:

Software Application

If the Software developed with respective particular client requirements or single client requirements that can be called as Software Application. Ex: Bank Applications, Hospital Applications.

Software Product

If the Software developed with respective multiple clients requirements, that can be called as Software Product. Ex: MS Office, VB, Operating System etc.

Q2. What is Error, Defect, Bug?

Answer:

Error: Any mistake in a programme is called “Error”.

Defect: Any mistake found by the tester during Testing can be called as “Defect”.

Bug: The reported defect is accepted by developer to resolve can be called as “Bug”.

Q3. SQC (Software Quality Control)?

Answer: It is a process of validating the Software.

Page 5: Manual Testing Final Notes

Q4. Why Software has Bugs?

(i) Poor requirements

(ii) Futurities (Customers requirements are frequently changing)

(iii) Miscellaneous Communication.

(iv) Unrealistic schedule

(v) Inadequate testing.

Solutions

(i) Solid requirements

(ii) Good communication

(iii) Realistic schedule

(iv) Adequate testing

(v) Gather / Stick to initial requirements as much as possible.

Page 6: Manual Testing Final Notes

TESTING MODELSFISH MODEL

Fish model defines the mapping between development stages and Testing

Diagram\

Reviews in Analysis

In general Software Development process starts with requirements gathering and analysis. In this, Business Development People are preparing Business Requirement Specification Document and Analyst people are preparing Analysis Document with respective to Business Requirement Specification. After completion of analysis document, the same category people conducting reviews in Analysis Document for completeness and correctness. During the review they are concentrate on the below factors.

i) Are they complete?

ii) Are they right requirement?

iii) Are they achievable?

Page 7: Manual Testing Final Notes

iv) Are they reasonable?

v) Are they testable?

Reviews in Design Document

After completion of Analysis document and corresponding reviews , designers are preparing design document which includes Functional Requirement Specifications and System Requirement Specifications .After completion of design document the same category people are conducting reviews in design document for completeness and correctness. During the review they concentrate on below factors.

1)Are they complete 2)Are they met right requirements?3)Are they understandable?4) Does they handle Errors or not?

White Box TestingAfter completion of deign document and correspondence reviews , programs with concentrate on coding to construct a Software Build. After completion of preparing all programs, Programmers are interconnecting them to a system. In this interconnection of programs to verify the programs and interface between programs or modules, programmers are conducting “White Box Testing ”White Box Testing classified as Two Types such as (I) Unit Testing(II) Integration Testing. Unit TestingIt is also called as Program Testing or Micro Testing. Unit testing means “Single Program Testing or Component Testing. Unit testing consists of below factors.a)Basic Path Testing.During this testing programmers are checking that whether the program is running or not? To perform this test they will follow below approach.1)Draw flow diagram of that program.2)Calculate number of independent paths in that program (Cyclometic Complexity) (The number of independent paths in the program)3)Execute the program more that one time to cover all independent paths in that program.b)Control Structure Testing In this testing the programmers will concentrate on corresponding program output. In this programmers will concentrate on every statement including, If conditions, For loops, Memory allocation etc.,c)Program Technique Testing In this testing the programmers are checking the execution speed of the program. If the execution speed of the program is not good, then programmers are performing changes in the structure of the program without disturbing functionality.d)Mutation Testing Mutation means changes in a program. In this testing programmers are performing wanted changes in the program and executing the program repeatedly. In this Test repetition

Page 8: Manual Testing Final Notes

Programmers are checking the completeness and correctness of the Test.

II)Integration TestingAfter completion of dependent program development and corresponding Unit Testing, Programmers are interconnecting to forma system. To estimate the interface between programs or modules programmers are conducting Integration Testing. They are (4) Types of approaches.a)Top-Down Approach.The verification of main module without coming to some of the Sub-Modules is called as Top-Down Approach.“Conduct test on Main module without conducting test on some of the Sub-Modules is called Top-Down Approach.”

main modul

Sub Modul-1 Sub Modul-2 Sub Modul-3

Stub

Temporary Program/ Called Program

In the above approach “STUB” is a Temporary Program, it works like as under constructive Sub Module, it is also called as Called Program.b)Bottom-Up Approach.The verification of Sub-Modules without coming from Main Module is called “Bottom-Up” Approach.“Conducting test on Sub-Modules without testing on Main Module is called Bottom-up Approach.

Main Modul

Driver/Calling Program

Sub-Modul-1 Sub-Modul-2 Sub-Modul-3

Page 9: Manual Testing Final Notes

In the above approach “Driver” is temporary program, it works like as under constructive Main Module. Driver is also known as Calling Program.

c)Hybrid Approach / Sand-witch Approach

The combination of Top-down Approach and Bottom-Up Approach is called as Hybrid Approach / Sand-witch approach

Bottom-Up Approach

Top-Down Approach

d)Big bang Approach.The verification of all modules after completion of all Modules development and corresponding unit testing is called as “Big bang Approach”. This approach is not suitable for large modules.

CASE STUDY Case 1: Top-down approach is follow able, when the customer’s requirements are constituent of clear. Case 2: Bottom-up approach is follow able, when the customer’s requirements are not clear or frequently changing.Case 3: Hybrid Approach is follow able, when the customer’s requirements are clear and the architecture structure of the system is changing. Case 4: Big bang Approach is follow able, when the application build consists less number of modules or less number of interconnections

Main Module

Driver/Calling Program

Sub-Module-2

Sub-Sub-Modul-2

Sub-Module-3

Stub

Sub-Sub-Module-3

Sub-Module-1

Sub-Sub-Module-3

Page 10: Manual Testing Final Notes

BLACK BOX TESTINGAfter completion integration of all modules to form a system, developers are sending that build to the separate Testing team. This separate testing team validates the Software build with respective customer’s requirements and expectations through “Black Box Testing” techniques. It is also known as “Close Box Testing” / “Functional & System Testing” It is classified as (3) types such as1)Usability Testing.a. User Interface Testing.b. Manual Support Testing.2)Functional Testing.a. Functionality Testing.b. Sanitation Testing.3)Non-Functional Testing.a. Recovery Testing.b. Compatibility Testing c. Configuration Testing.d. Intersystem Testing e. Comparative Testing f. Security Testing.g. Installation Testing.h. Load Testing.i. Stress Testing j. Data Volume Testing.k.Storage Testing. 1) Usability TestingAfter receiving build from the development people, testers are conducting usability testing to check whether the application build is providing user friendly screens or not. Usability Testing is classified into (2) Types such as (a) User Interface Testing (2) Manual Support Testinga. User Interface Testing

During this testing testers are checking the Look and Feel, Ease of use of application of build screen.Ex: The Microsoft (6) Rules for testing1) Controls are in it caps.2) Ok, Cancel existence.3) System Menu existence.4) Controls are not overlapped5) Controls should be visible.6) Controls must be aligned.

Page 11: Manual Testing Final Notes

b. Manual Support TestingIt is also known as “Help document Testing”. During this testing Testers are checking the context sensitiveness testing. Ex: Spelling Mistakes, Grammar mistakes, Word Missing, Line Missing etc. ,Case 1: Receive build from the developers. User interface testing. Functional & Non-Functional Testing Manual Support Testing.2) Functional TestingAfter completion of User Interface testing, Testers are conducting Functional Testing to validate customer requirements. Functional Testing classified into (2) Types (a) Functionality Testing (b) Sanitation Testing.

a) Functionality TestingDuring this Testing Testers are validating customers requirement in terms of (6) coverage.1) Behavioral Coverage.2) Input Domain Coverage.3) Error-Handling Coverage.4) Calculation Coverage.5) Back-end Coverage.6)Service level Coverage.

1) Behavioral Coverage.In this testing Testers are checking whether the objects are properly responding of not, with respective to Business Operation.2) Input Domain CoverageIn this testing Testers are checking whether the input objects /Input fields are taking right type and range of value or not. To perform this test we (Testers) are using (2) Types of Testing.(a)BVA (Boundary Value Analysis)(b)ECP (Equivalence Class Partitioning)

BVA(RANGE OF OBJECT)

RANGE EXPECTED ACTUAL RESULT

Min= Pass Min-1= FailMin+1= PassMax= PassMax-1= Pass

ECP(Defines Type Of Object)

Page 12: Manual Testing Final Notes

Valid Invalid

Pass Fail

Ex: A Login process allows User Name and Password from a User. In this User Name object allows “Alphabets lower case” Range from 4 to 8Characters long and Password object allows “Alphabets lower case” range from 6 to 10 Characters long. Prepare BVA and ECP for the above expected.

BVA & ECP for User Name

BVA

RANGE EXPECTED ACTUAL RESULT

Min=4char Pass

Min-1=3char

Fail

Min+1= 5 Char

Pass

Max= 8 Char

Pass

Max-1= 7 Char

Pass

BVA & ECP for Age

ECP

VALID INVALID

[A-Z] [A-Z]

[0-9]

ALL

SPECIAL

CHARACTER

Page 13: Manual Testing Final Notes

EX: Age object allows numeric range from 16 to 60.Prepare BVA and ECP for the above expected.

EX: Mobile No. object allows numeric 10digits only. Prepare BVA and ECP for the above expected.

BVA & ECP for Mobile No.

3)Error Error-Handling Coverage.

BVA

RANGE EXPECTED ACTUAL RESULT

Min=16 Pass

Min-1=15 Fail

Min+1=17 Pass

Max= 60 Pass

Max-1= 59

Pass

Min+1=61 Fail

ECP

VALID INVALID

[ 0-9] [A-Z]

[ a-z]

ALL

SPECIAL

CHARACTER

BVA

RANGE EXPECTED

ACTUAL RESULT

Max=10 Pass

Max-1=9 Fail

Max+1=11 Fail

ECP

VALID INVALID

[ 0-9] [A-Z]

[ a-z]

ALL

CHARACTER

Page 14: Manual Testing Final Notes

In this we are checking whether the objects are preventing “Negative Operations” or not.

4) Calculation Coverage

In this we are checking whether the functionality output is right or wrong.

5) Back-End Coverage.

In this testing we are checking whether the insert of front end operations on back end table context.

6) Service level coverage.

The order functionality.

b) Sanitation TestingIt is also known as “Garbage Testing”. During this testing , testers are finding extra functionalities in the build with respect to customer requirements.3)Non-Functional Testing

After completion of Functional Testing, testers are concentrating on Non-Functional Testing to validate extra characteristics of that build. They are divided into (11) Types.

a) Recovery TestingDuring this testing we are checking that whether the application Build is changing from Abnormal State (Crash / Hang) to Normal State or not. Abnormal State to Normal State

Abnormal State to Normal State

b)Compatibility TestingThey are (2) types of Compatibility Testing.During this testing we are checking whether the application build is able to run on different platforms or not. Platform means Operating System, Browsers, compilers and other System software’s.

During this testing we are checking whether the application build is able to run on different platforms or not. Platform means Operating System, Browsers, compilers and other System software’s.

c) Configuration Testing

Page 15: Manual Testing Final Notes

It is also known as “Hardware Compatibility Testing”. During this testing we are validating whether the application build is supporting different technologies input / Output devises or not.d) Intersystem Testing.It is also known as “Inter operability Testing”. During this testing we are checking whether the application build is coexistence with other existence to share common resource or not

e) Comparative Testing.It is also known as “Competitive Testing”. During this testing we are comparing the features of produce with some like previous produce (or) Existing produce in the market to estimate competitiveness. f)Security Testing.

It is also known as “Penetration Testing”. During this testing we are validating (3) types of factors such as

(i) Authorization.(ii) Access Control.(iii)Encrypt / Decrypt Data Testing.

(i) Authorization.In this testers are checking whether a valid user is accessible or not, invalid user is preventable or not.(ii)Access ControlIn this we are checking whether a valid user have permission to use specific features / Services or notiii) Encrypt / Decrypt Data Testing.

The code conversion in between client process and server process to avoid third party accessing.

g) Installation TestingIt is also known as “Deploying Testing”.During this testing we are validating below factors.

Page 16: Manual Testing Final Notes

CustomerExpectedConfigureComputer

Build and Supported

S/W

h) Load Testing.Run the application under customer expected configuration under customer load to estimate the speed of processing is called “Load Testing”.i) Stress Testing.Run the application under customer expected configuration under various loads from low to peak to estimate Stress capacity of the application build is called Stress Testing.j)Storage Testing.The execution of application build under customer expected configuration under huge amount of resources to estimate the storage capacity of the application database is called Storage Testing.k)Data Volume Testing.During this testing Testers are calculating the number of records to be stored into application database.

GRAY BOX TESTINGGray Box Testing is a combination of “White Box Testing” and Black Box Testing. UAT (User Acceptance Test)After completion of Software Testing, the Project Management / Project Manager will invite customer to collect feedback on one developed softwareThey are (2) types such as

Release Testing

Α - Test (ALFA TEST)

Software ApplicationBy Real customerAt development site

B-Test (BETA TEST)

Software Product.By Model customer.At customer site

Page 17: Manual Testing Final Notes

It is also known as “Port Testing”. After completion of User Acceptance Test” and corresponding modifications, the Project Management will establish Release Team with few Developers, few Testers and One (or) two Hardware Engineers. This release team will go to customer’s site to install the software on the customer’s environment. During this they will concentrate on below factors. a). Compact Installation. b). Overall functionality. c). Input device handling. d). Output device handling. e).OS Error handling. d).Secondary storage handling. e).Coexistence with other existence software.

After completion of above like factor observation the release team is providing required training sessions to the customers to understand about the project.

Maintenance

During utilization of Software by customers, the company people are receiving change request from them. To receive change request from the customers the Project Management establish “CCB” (Change Control Board) with few Developers, few testers and Project Manager.

CASE STUDY

Page 18: Manual Testing Final Notes

Challenges in Testing

Generally organizations are maintaining separate Testing for Functional and System Testing. This separate Testing team is also involving in Release Team and CCB. Some time this separate Testing team is also not able to conduct planned Testing or good testing due to some risksThe risks are1. Lack of knowledge on project domain.2. Lack of communication.3. Lack of resources.4. Lack of time.5. Lack of Test Data. To overcome above like risks, the people are following “Ad-hoc” Testing. Planned TestingA Tester conduct Test on application build with pre-planned procedure is calledPlanned Testing.(or)A Tester conduct Test on application build by following formal methods are calledPlanned Testing. Ad-hoc TestingA Tester conduct test on application build without Pre-planed is calledAd-hoc Testing.(or)A Tester conduct test on application build by following “Informal Methods” is called “Ad-hoc Testing”.They are classified as (4) Types.

(a) Monkey Testing.Due to lack of time, Testers are conducting test on major functionalities of the application build. This style of testing is called“Monkey Testing”. It is also known as Cheapening Testing.

(b) Buddy Testing.Due lack of time, Testers are grouping with programmers to conduct Test on application as early as possible. This style of Testing is called asBuddy Testing.Buddy means a group of Programmers and Testers.

(c) Pair Testing.

Page 19: Manual Testing Final Notes

Due to lack of knowledge on domain Junior Testers grouped with Senior Testers to share their knowledge. This style of testing is calledPair Testing.(d) Exploratory Testing.Due to lack of Test Data, Testers are conducting Test on application depending on available documents, discussions with other and get the requirements from customers. This style of testing calledExploratory Testing.

SOFTWARE DEVELOPMENT LIFE CYCLE (SDLC)

1) WATER FALL MODEL

In this Model next stage starts after completion of previous stage. There is no overlapping between two stages.ADVANTAGES i) it is less expensive.ii)It works well for small applications.iii)It is flexible when the customer requirements are constant. DISADVANTAGES i)Testing is a single stage starts after coding.ii)If any defect is found during Testing, the rectification of that defect would be difficult.iii)It is “not flexible” to have changes in the customer requirements during developing the software.

2) INCREMENTAL WATER FALL MODEL

Page 20: Manual Testing Final Notes

To overcome some of the limitations of Waterfall we can use Incremental Waterfall model.Incremental Waterfall Model can be used Software Produce Development.In this Model a set of requirements they would be one working product.

3) PROTOTYPE MODEL It is follow able when the customer requirements are not clear. “Prototype means a sample Model of application without functionality.

ADVANTAGES i)It is flexible when the customer requirements are not clear.

DISADVANTAGES

Page 21: Manual Testing Final Notes

i)It is expensive

4) Spiral ModelSpiral Model is follow able when the customer requirements are enhance able in terms of versions.n this Model we will start the process within complete requirements.

ADVANTAGES it is flexible for high risk based projects.

DISADVANTAGES It is expensive.

5) V-MODEL Like as Fish Model “V-Model” is also defines the mapping between Development stages and Testing stages. In V-Model V stands for “Verification and Validation”.VerificationTo check whether the people are developing right product or not.ValidationTo check whether the developed product is right or not.Software TestingThe “Verification and Validation” of a Software is called Software Testing.

Page 22: Manual Testing Final Notes

6) Agile Model It is a latest model which is used in Software produce development. In this model we can get build from the developers in very short time (1to 4 Weeks)In this model development process, testing process will be carried out parallelly. They are (2) methods such as (a) X-Tream Programming.(b)Scrum ADVANTAGES Any defect identified early, so that he rectification of the defect cost and time would be very less.ii) As the defect is identified early, the impact of the same defect is very less on subsequent features.

DISADVANTAGES

i) Documentation is very less.

Smoke TestingLike as Sanity Testing, Smoke Testing is also used to estimate the stability of the Build.

Page 23: Manual Testing Final Notes

Sanity TestingAfter receiving the build from the developers we people are conducting “Sanity Testing” to estimate stability of that build before start real testing. During this testing we will be concentrate on below factors.a) Understandable.b) Operatable.c) Observable.d)Controllable.e)Consistency.f)Automatable.g)Maintainableh)Simplicity. From the above (8) factors, Sanity Testing is also known as Build Verification Testing (BVT) or Tester Acceptance Testing (TAT) or Testability Testing or Oct-angle Testing.

Re-Testing.Case 1: The repeating of same test for more than one time with multiple data is called as “Re-Testing”. Case 2: The re-execution of failed tests on modified build to ensure bug fixing work is called “Re-Testing” Regression Testing.The Re-execution of selected test or modified build, to check is there any side effects occurred or not on dependent functionalities by modifying report add effects or by adding new requirements.

Types of BuildThey are (7) types of Build. They are

Page 24: Manual Testing Final Notes

(1) Initial Build(2) Stable Build(3) Defect effected Build(4) Modified Build(5) Complete Build(6) Master Build(7) Golden Build

Types of ProjectsMainly there are (3) Types of projects. They are (1) Traditional Project(2) Outsourcing Project (3) Maintenance Project

Page 25: Manual Testing Final Notes

MANUAL TESTING