]Testing Tools
Software Testing : Testing is a process. During this testing
process tester can measure the quality of a software projects or products..
1.
Project : It is developed based on user requirements and it is used by single user.
2.
Product. It is developed based on user universal requirements and it used by multiple user.
Software Quality : The justification of the requirements of
users in the project or product as to produce the Customer satisfaction.
*Quality is defined by User. * Quality is measured by Tester.
* Measuring the quality is depending on three things a) User requirements.
b) Bug free. c) Time.
Importance of Testing :
1. During this this testing testing process Tester Tester can verify verify whether whether the functionality of an application working properly or not. 2.
This application satisfies the requirement of user or not.
Testing Objectives : 1.
Understanding the functionality of an application.
2. Understandin Understanding g the requirement requirement of an an user.
1. Manual Testing : Testing the application with the help of
man power is called manual testing. Advantages : 1. We can test any any type of applicatio application. n. 2. We can test any any type of testing. testing. 3. Low Low Cost Cost..
Draw backs : 1. Time consuming consuming procedure. procedure.
2. Low Low accu accura racy cy 3. Low reliab reliabili ility. ty.
Software Development Life Cycle (SDLC) :
By using SDLC model to we develop an application. 1. Waterf Waterfall all Model. Model. 2. Protot Prototype ype Model. Model. 3. Iterat Iterative ive Model. Model. 4. Fish Fish Model Model.. 5. V Mode Model. l. *.We can select any SDLC model depending on two things 1. Project Project Size Size i.e., i.e., Small Small or Large Large 2. User Requireme Requirement nt i.e., Constant Constant or Keep on Changing. Changing. We can select any model to common activities are 1.Information Gathering and Analysis. 2. Designing 3. Coding 4.Testing 5.Maintenance
1. Information Gathering and Analysis : In this phase Business Analyst or Domain expert will collect the information from use to prepare Business Requirement Specification (BRS)
BRS This document specifies Business look of an application 1.
In this phase Sr Analyst can analyze the collected requirements to prepare Software Requirement Specification (SRS) and Functional Requirement Specification (FRS) or Functional Specification Document (FSD).. (FSD)
Software Requirement Specification : This document specifies software and hardware components to develop an application.
Functional Requirement Specification : This document specifies total functionality of an application. It is baseline document used by both Developers and Testers.
Collected Requirements
Functional Requirement
Non Functional
Requirement
Functional Requirement Specifications (FRS)
2. Designing : In this phase Designer can design an application
and also prepare documents such as.
1. LLD (Low Level Designing) 2.HLD (High Level Designing)
1.LDD: This document specifics a) No of screens b) Data flow diagrams C)er_diagram (entity relation)
3. HLD : This document specifies how to combine all the components together in order to build a system.
3. Coding : Coding should be done by developer to implement
an application.
4. Testing : During this testing process Tester can measure the
quality of a software application.
5. Maintenance : a)Services to the customer b)We can enhance
the current application if user come up with new requirements.
1. Waterfall Model :
Requirements IG & Analysis Designing Coding Testing Mainte nance
All the phases in waterfall model are implemented in a sequential manner. One phase output should be the input for next phase. We can select this cycle model if project is small in size and user requirements are constant. It is also called as Classical Life Cycle Model or Linear Sequential Model.
Draw Backs : It is time consuming process. If any mistake is done in above phase same mistake will be repeated till the end of development process.
It doesn’t allow the new requirements of user in the middle of our development process.
2. Prototype Model :
Requirement IG &AnalysisBuild PrototypeTest PrototypeUser
Change in
- Build
Test Prototype User------------
If OK Requirement
Prototype
Designing Coding Testing Maintenance
We can use this life cycle model to over come the third draw back of waterfall model. We can select this life cycle model if project is small in size and user requirements are keep on changing.
Draw Back : Time consuming process. If any mistake done in designing phase same mistake will be repeated at the end of development process. It is expensive than waterfall model.
3. Iterative Model : E Seva -------------
A
D
C
T
M
A
D
C
T
M
A
D
C
T
M
M1 ------------M2 ------------M3
We can use this life cycle model to develop a project for module wise installation.
We can select this life cycle model if project is large in size and user requirements are keep on changing.
Draw Backs : It is time consuming process. If any mistake done in above phase same mistake will be repeated till end of the development process. It is expensive model.
4. Fish Model :
SDLC
Requirements
IG & Analysis
Designing
Coding
|
|
|
|
|
|
|
|
|
|
|
|
Review
Review
Testing
Maintaince
BRS
Test S/w change STLC
Unit Testing &
Integration Testing (WBT Done by Developers) Syste m Testing & Accep tance Testing (BBT Done by Testers) We can use this life cycle model to conduct review process at the end of each and every phase. We can select this life cycle model if project is large in size and user requirements keep of changing.
Draw Backs : Time consuming and expensive.
5. V Model :
Development
Testing
Activities
Activities
Requirements collection Requirement Testing IG &Analysis
Test
Plan ------------------------------------------------------------------------------------------Designing
Unit &
&Coding Integration Testing ---------------------------------------------------------------------------------S/w Build
System
Testing Acceptance Testing ------------------------------------------------------------------------------------Maintenance
Port Testing Test S/w changes
We can use this life cycle model to implement development activities and testing activities simultaneously. We can select this life cycle model if project is large in size and user requirements are keep on changing.
Draw Backs : It is expensive model.
Types of Testing :
Testing divided into two types 1.
White Box Testing
2.
Black Box Testing
1.
White Box Testing : Using programming knowledge
validating internal structure of an application “Source Code” is called White Box Testing. In general this testing is performed by programmers using design documents. Unit testing and Integration testing are examples of White Box Testing. This is also known as Structural Testing or Glass Box Testing. 2.
Black Box Testing : Without having programming
knowledge validating application functionalities with respect to client requirement is called Black Box Testing. System Testing, User Acceptance Test are example of Black Box Testing. This is also known as Close Box Testing or Behavioral Testing.
Note : The combination of WBT & BBT is called Grey
Box Testing.
1.
Unit Testing :
It is done by developers by using
white box testing technique. During this testing process developers can verify the correctness of single component or module. In this testing process developer can follow below three coverage’s 1.Basic path coverage 2.Control Structure coverage 3.Program Technique coverage.
1.Basic path coverage : In this coverage the programmer can execute the programme more than one time to cover all alternative paths of a corresponding programme.
2.Control Coverage : In this coverage the programmer can verify the correctness of input process and out put of an application based on designing.
3. Programmer Technique Coverage : In this coverage the programmer
can calculate the execution speed of a programme.
2. Integration Testing :
It is done by developers by using white box testing process. During this testing process developer can verify whether the connecting screens are working properly or not.
In Integration Testing, we use two testing techniques. i)
Top Down Approach
ii)
Bottom Up Approach
i) Top Down Approach : In this approach the developer can inter connecting main programme and sub of sub programmes. Stubs:- while doing top down approach if any modules are not created or Under Construction we will create temp modules it is know as stubs.
ii) Bottom Up Approach : In this approach the developer can inter connect the sub programmes without presence of main programme. Drivers:- while doing Bottom Up approach if any modules are not created or Under Construction we will create temp modules it is called drivers.
The Combination of Top Down approach and bottom up approach is called sandwich approach or Hybrid approach.
3. System Testing : It is done by tester by using black box
testing process. During this testing process tester can verify the correctness of a system
During this testing process tester can verify whether the system satisfies the user requirements or not System testing in divided into four types. 1.GUI Testing 2.Functional Testing 3.Performance Testing
4.Security Testing
1. GUI Testing : During this testing process tester can verify the on functional requirement of users. a. Back ground color of screen. b. Font style and size c. Controls are visible or not d. Alignment of controls e. Verify control should start with initial capital letter
2.Functional Testing : During this testing process tester can verify the functionl requirements of user by using below testing types.
1.
Functionality Testing
2.
Input Domain Testing
3.
Re Testing
4.
Recovery Testing
5.
Compatibility Testing
6.
Configuration Testing
7.
Inter-System Testing
8.
Parallel Testing
9.
Big-Bang Testing
10.
Exploratory Testing
11.
Regression Testing
1. Functionality Testing : During this testing process Tester can verify the default properties of an application. Ex :Minimization, Maximisation,close
2.Input Domain Testing : During this testing process tester can verify size or range and type of the input data
Here tester can implement positive testing and negative testing Positive Testing : Testing an application by giving valid
data. Negative Testing : Testing an application by giving invalid
data. 3.Re-Testing : During this testing process tester can re execute the test with different sets of input data(Valid & In valid).
4. Recovery Testing or Reliability Testing : During this testing process Tester can verify how well the application changes it status from abnormal state to normal state In general the applications are executed in normal state. The application changes its status from normal state to abnormal state due to power failures, system failures. Normal NormalState State
Abnormal State
Normal State
5.Compatability Testing : During this testing process tester can run an application under user required platform.
6.Configuration Testing : during this testing process tester can run an application on different plat forms.
Install/uninstall testing - testing of full,partial, or upgrade all/uninstall processes.
7. Intersystem testing : During this testing process tester can verify the co existenace of an new application with other applications which are already used.
8. Parallel Testing : During this testing process tester can verify the feature of a new application with features of a similar application which is already used to know the strengths and weaknesses of a new application.
9. Big Bang Testing : Bing Bang or Single level Testing : During this testing process tester can test the functionality of an application at once. When the functionality is easy to understand and when the project is small in size then we go for big bang test.
10 Exploratory Testing or Level by Level Testing : During this testing process tester can test the functionality of an application at different levels.
11. Regression Testing : During this testing process tester can re execute the test on modified build application. Reasons to perform Regression :
1. To identify whether all reported defects are resolved properly or not. 2.To Identify impacted area with coding changes.
3. Performance Testing : Performance means speed of processing. During this testing process tester can verify how well our application respond to a user request.
i)
Load / Scalability : In this test we verify whether the
application allows customer expected concurrent users on customer expected configuration system and we estimate average response time. ii)
Stress Testing : In this test we estimate peak limit of
load (at a time concurrent users) to operate application on customer expected configuration system. iii)
Soak Testing : In this test we estimate peak limit load
in terms of no of hours i.e., tester run the application
continuously along period of time to verify the stability of an application. iv)
Data volume Testing : In this test we verify maximum
storage capacity in application database in terms of records.
4. Security Testing : In this test, we verify the privacy to user operations in terms of authorization and access control. 1. Authorization / Authentication : 2. Access Control : Control of whole system under single person Ex: Database Administrator. 3. Encryption and Decryption: Change original form in non readable form is Encryption and change non readable for into readable form is called Decryption 4. Session Time or Page Expiry Time.
5. Acceptance Testing : After completion of system
testing we can conduct user acceptance testing. Here we can implement two types of acceptance testing like Alpha
Testing or Of-site Testing and Beta Testing or On-site Testing.
a.
Alpha Testing : During this testing process tester
can run an application in development enviroment. b.
Beta Testing : During this testing process user
can run a application on their own environment.
Other testing types a).Jump/ Monkey Testing : Due to lack of time we validate main activities of an application. In this approach, we collect high priority test cases those we execute on application. b) Adhoc Testing : During this testing process tester can test the functionality of an application without proper documentation. Note: In general small organizations are using adhoc testing. Some time large organization also using this testing due to lack of time. Motivation Testing:
Software Testing Life Cycle :
Testing process is common for both manual testing and automation testing
software testing life cycle has following stages. 1.
Test Initiation
2.
Test Plan
3.
Test Case Design
4.
Test Execution
5.
Defect Reporting & Tracking
6.
Test Closure.
1.
Test Initiation : In this phase we can prepare required
document that document is called test strategy. Test Strategy : It is organization level document prepared by quality analyst. This document specifies set of quality standards to be used in the testing process. This document is common for every project. This document is changed when the quality standards are changed.
2.
Test Plan : It is project level document prepared by
Test Lead. This document describes a) b)
What to test How to test
c)
Who to test
d)
When to test
Test Plan Document : It provides guidelines to the test engineer to perform testing activities. It contains following components.
Introduction : It describes brief description about test plan document and scope of testing.
Features to be tested : It describes which module and. requirement need to be tested in current application.
Features not to be tested : It describes which modules or requirements not required to test.
Ex: Those modules may be under construction or already tested that modules
Testing Approach : It describes testing level and techniques which we need to test Ex: Sanity Testing, Functional Testing, Integration Testing, Automation Testing.
Pass/Fail Criteria : It describes when to stop testing activities and when to continue test execution.
Suspension Criteria : When to stop test execution
e)
When the AUT is failed in sanity testing
f)
Whenever there is change request from client
g)
Delay in publishing the input documents like
FRS, Test Scenarios, Test Data etc., Resumption Criteria : When to continue test execution
a) Testing can be resumed after the patch is released for the rejected Build. b)
After input documents are published.
Test Deliverables : It describes which document we should prepare during execution time and which documents we should deliver to client after execution. a)
Test Execution Reports
b)
Defect Profile Document
c)
Test Summary Reports
Roles & Responsibilities : It describes list of Testing Team who is involved to test the application.
Schedule : It describes time line when to start and complete testing activities.
Resources : It describes test environment or configuration of the system required to test the application. EX: Software, Automation Tools and Hardware requirements.
Risks & Mitigates : It describes possible risks during testing time and remedies to solve those risks like training needs.
3. Test Case Design : Preparation of Test Data Document and Test Case Document is called Test Case Design.
A. Test Data Document : This document specifies input data to be used in the testing process. In order to prepare test data, we should know the size or range and type of input data. The types can be 1.
Uppercase (A-Z)
2.
Lowercase (a-z)
3.
Special Symbols (@,%,&)……)
4.
Digits (0-9)
Testing Techniques or Test Data Techniques : Below are the techniques to find the test data a)
Boundary Value Analysis (BVA)
b)
Equalence Class Partition (ECP)
a) Boundary Value Analysis : It is used to find the size or range of the input data.
b) Equivalence Class Partition : It is used to find the type of the input data
B. Test Case Document : This document specifies a sequence of actions performed by tester using Test Data.
Test Case Template : In general we prepare test cases in excel sheets with pre defined components where test case template contains following components. Project Name Module Name Test Name Test Scenario Test Procedure
Test Case
Step
Name/ TC ID #TC1 #TC2 #TC3
Test Step ----
Test
Expected
Actual Status
Data -----
Result -----
Result /Result
------------------------------------------------------------------------------------------Example : 1 Login User Name : Password :
Sign In
Cancel
Functionality : UN Given input data should be accept Password Given input data should be accept Sign In It should be verify the given UserName and Password if the data is valid it should navigate to next window, else it should display error msg. Cancel Close the login dialog.
Working : Test Data Table 1 UN BVA
ECP
Valid Data >=5 <=10 Lower Case Digits Combination of Lowercase &
Invalid Data <5 >10 Special Symbols Uppercase Combination of Special symbols and
Digits
Upper Case
Table 2 Password Valid Data >=1 BVA <=5 Digits
ECP
Invalid Data <1 >5 Uppercase Lowercase Special Symbols Combination of Special symbols, Uppercase and Lowercase
Test Scenarios :
Verify UN
Verify Password
Verify Sign In
Verify Cancel
Test Cases :
Test Case Name/
Test Case
ID
Description
Actual Test Data
Expected Result Login window should be
TC-01
Open Login window
As per the
displayed Given data should
TC-02
Enter valid UN
Table1
be accepted Error message
As per the
should be
TC-03
Enter Invalid UN
Table1 As per the Table
displayed Given data should
TC-04
Enter valid password
2
be accepted Error message
Enter Invalid
As per the Table
should be
Password Enter Valid UN,
2
displayed Next window
Password & click
As per the Table
should be
TC-06
Signin
1&2
displayed Login window
TC-07
Click Cancel Button
-
should be closed.
TC-05
Result Result
Test Case Review : After preparation of test cases to check the correctness and completeness of the test cases we conduct Test Case Review. Test Case Review conducted on two levels. 1.
Peer Review
2.
Test Lead Review
1.
Peer Review : It is performed within the test engineers
where they verify written test case correct or not. Test Lead Review : After Peer Review Test Engineers
2.
provide all the test cases to the Test Lead, where Test Lead verifies written Test cases are sufficient or not to verify the complete functionality of an application . In this process Test lead prepare traceability matrix. Using traceability matrix we can analyze gap between test cases and requirements. Test
Reviewed
Reviewed
Case ID
By
On
Designation Comments
Approval : Once TM has approval the test case. Then we will start to execute the test case.
C. Test Execution : After Test cases review if test lead felt written test cases are sufficient then he give the permission to execute those test cases.
D. Defect Reporting (or) Defect Tracking : During execution time of test cases if test engineer identify any mismatch then we call them as defects. Those defects we need to send to the development team is called defect reporting.
Defect Life Cycle or Bugler Cycle : 1. Defect Id : 2.
Detect for a defect :
3.
Identify a defect :
4.
Reproduce a steps :
5.
Report a defect :
6.
Detected by :
7. Detected on : 8. Defect Status : New, Re Open, Accepted, Rejected, Postponed, Close. 9.
Severity : (High s1,Medium s2, Low s3)
10. Priority
: (High p1, Medium p2, Low p3)
Defect Log Te
Defect
Detection
Fix
st Feature
ca
Issue
Reproduc
Reproduc
Defect
Date
Defe
Descript
se
Descript
eble
ible
Sever
Prior
b
dat
Bui
Resolut
b
dat
Bui
closu
ct id
ion
id
ion
[ Y/N ]
Steps
ity
ity
y
e
ld
ion
y
e
ld
re
Common Defects : In general during execution time of test case. We identify following defects. 1.
User Interface Defects (low severity): Defects concerned with non functional requirements of users. Ex : Spelling Mismatch, Color Mismatch, Labels etc.,
2.
Input domain defects (medium severity): Defects concerned with test data Ex: UN i) Un field accepts invalid data. ii) Un field reject valid data.
3.
Error message defects (Medium) : Defects concerned with error messages Ex : error Msg box is displayed without any text Error Msg box is displayed improper meaning of error.
4.
Calculation defects (High) : These defect may be either wrong or failure.
Wrong – unexpected behavior of an application. Ex : 1 +2 = 4 Failure – Application fails to implement the internal function Ex : 1 + 2 = no result.
5.
Load related defects (High) : Defects concerned with load of an application Ex : Application fails to allow multiple users. Application fails to allow user required load. Id control defects.
6.
Id Control defects (medium) : Defects concerned with screens Ex : Logo Missing, Wrong Logo Preparation, Copyright missing.
E. Test Closure : Which is also sign of criteria to close Test cases. It is performed by test lead after analyzing following factors.
•
When the functionality of an application is working properly.
•
When the application is bug free or defect free.
•
When all the test cases are executed.
•
When the test cases executed with certain % passed criteria.
•
When Project Dead lines are reached.
•
Budget depletion.
Manual Testing Process Vs Automation Testing Process :
1. Going through FRS we can
Going through FRS we can
understand functionality of
Understand the functionality of
application.
application.
2. Preparation of Test Plan
Preparation of Test Plan
(manually)
(manual)
