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. b. Customer requirements in terms of functionalities. Customer expectations (Look and feel, Ease of use, right output, speed of processing, security)

2. a. b.

Non-technical factor Low cost to purchase 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 FRS (Functional Requirement Specification) SRS (System Requirement Specification) HLD (High Level Design Document) DESIGN

ANALYSIS Analyst (Software Requirement Specification)

Designers (Design Document)

LLD (Low Level Design Document)

CODING (Programmers)

TESTING (Testers)

PROJECT MANAGEMENT (Release and Maintenance)

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.

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.

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.

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.

TESTING MODELS
FISH 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? 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 Testing After 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 Testing It 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 Programmers are checking the completeness and correctness of the Test. II)Integration Testing After 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. main modul 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.
Stub

Sub Modul-1

Sub Modul-2

Sub Modul-3

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 BottomUp Approach.Conducting test on Sub-Modules without testing on Main Module is Main Modul called Bottom-up Approach.

Driver/Calling Program

Sub-Modul-1

Sub-Modul-2

Sub-Modul-3

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

Main Approach / Sand-witch Approach c)HybridModule

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

Sub-Module-1

Sub-Module-2

Sub-Module-3

Bottom-Up Approach

Stub

Sub-SubModule-3

Sub-SubModul-2

Sub-SubModule-3

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 customers requirements are constituent of clear. Case 2: Bottom-up approach is follow able, when the customers requirements are not clear or frequently changing. Case 3: Hybrid Approach is follow able, when the customers 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

BLACK BOX TESTING

After 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 customers 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 as 1)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 Testing After 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 Testing a. 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 testing 1) Controls are in it caps. 2) Ok, Cancel existence. 3) System Menu existence. 4) Controls are not overlapped 5) Controls should be visible. 6) Controls must be aligned.

b. Manual Support Testing It 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 Testing After 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 Testing During 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 Coverage In 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= Min-1= Min+1= Max= Max-1= Pass Fail Pass Pass Pass

ECP(Defines Type Of Object) 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 Min=4c har Min1=3cha r Min+1= 5 Char Max= 8 Char Max-1= 7 Char EXPECT ED Pass Fail ACTUAL RESULT VALID [A-Z] ECP INVALID [A-Z] [0-9] ALL SPECIAL Pass Pass Pass CHARACTE R

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

BVA RANGE Min=16 Min1=15 Min+1= 17 Max= 60 Max-1= 59 Min+1= 61 EXPECT ED Pass Fail ACTUAL RESULT ECP VALID [ 0-9] INVALID [A-Z] [ a-z] Pass Pass Pass Fail EX: Mobile No. object allows numeric 10digits only. Prepare BVA and ECP ALL SPECIAL CHARACTE R

for the above expected. BVA & ECP for Mobile No.

BVA RANGE Max=10 Max1=9 Max+1 =11 EXPECT ED Pass Fail Fail ACTUA L RESULT VALID [ 0-9]

ECP INVALID [A-Z] [ a-z] ALL CHARACTER

3)ErrorError-Handling Coverage. 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 Testing It 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 Testing During 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 Testing They 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 softwares. 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 softwares.

c) Configuration Testing 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 Control In this we are checking whether a valid user have permission to use specific features / Services or not iii) Encrypt / Decrypt Data Testing. The code conversion in between client process and server process to avoid third party accessing. g) Installation Testing It is also known as Deploying Testing.During this testing we are validating below factors.

Build and Supported S/W

Customer Expected Configure Computer

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 TESTING Gray 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 software They are (2) types such as

- Test (ALFA TEST) Software Application By Real customer At development site Release Testing

B-Test (BETA TEST) Software Product. By Model customer. At customer site

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 customers site to install the software on the customers 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

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 risks The risks are 1. 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 Adhoc Testing. Planned Testing A Tester conduct Test on application build with pre-planned procedure is called Planned Testing .(or)A Tester conduct Test on application build by following formal methods are called Planned Testing . Ad-hoc Testing A Tester conduct test on application build without Pre-planed is called Ad-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 as Buddy Testing .Buddy means a group of Programmers and Testers. (c) Pair Testing. Due to lack of knowledge on domain Junior Testers grouped with Senior Testers to share their knowledge. This style of testing is called Pair 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 called Exploratory 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 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 i)It is expensive 4) Spiral Model Spiral 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. Verification To check whether the people are developing right product or not. Validation To check whether the developed product is right or not. Software Testing The Verification and Validation of a Software is called Software Testing.

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 Testing Like as Sanity Testing, Smoke Testing is also used to estimate the stability of the Build.

Sanity Testing After 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)Maintainable h)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 Build They are (7) types of Build. They are

(1) (2) (3) (4) (5) (6) (7)

Initial Build Stable Build Defect effected Build Modified Build Complete Build Master Build Golden Build

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

MANUAL TESTING