Software testing involves verifying and validating software to find bugs. There are different types of testing techniques including static testing, dynamic testing, black box testing, and white box testing. Black box testing focuses on functionality without knowledge of internal design or code. It involves techniques like error guessing, equivalence partitioning, and boundary value analysis. White box testing uses programming knowledge to test internal logic and structures. Common types of testing include unit testing, integration testing, and security testing.

1. SOFTWARE TESTING
Software Testing:-
•The verification and validation of a software is called software
testing.
•This is the process with the intent of finding a bug in a software.

2. Testing Types
Static Testing Technique(not executable part) (Executable Part)Dynamic testing Technique
Review Analysis Review Design Structural Testing Functional Testing
White Box Testing Black Box Testing
Testing on Internal Interface Testing On External Interface
Gray Box Testing

3. Black Box Testing(BBT)
• Back box testing is not a testing instead of that it is a testing strategy, which does not need
any knowledge of internal design or code etc.
• As the name black box suggests, no knowledge of internal logic or code structure is required.
• The type of testing under this strategy are totally based or focused on the testing for
requirements and the functionality of software application.
• In BBT the software is tested without bothering about its internal structure, data structure
used inside it, logic applied inside it, syntax used inside it, dynamic or static memory
utilization, only the software is checked for correct and complete specification. It is checked
whether it is reliable or not, it is checked it satisfies client’s all requirement or not.
• The base of BBT strategy lies in the selection of appropriate data as per functionality and
testing it against the functional specification in order to check for normal & abnormal
behavior of the system.
• In order to implement BBT strategy, the tester is needed to be through with the requirement
specification of the system and as a user, should know, how the system should behave in
response to particular action.
• BBT is also called Opaque/Functional/Closed Box/Behavioral testing.

4. White Box Testing(WBT)
The completion of design documents & corresponding reviews developers do
coding to physically construct software. After completion of coding the
programming knowledge people are testing internal logic of every
programs.
WBT is also known as clear box/glass box/open box/structural/program
phase testing.

5. WBT…
WBT classified into 3 types:-
1) Unit Testing or Micro testing
Execution testing
Operation testing
Mutation Testing
2) Module testing or Macro Testing
3) Integration Testing
Top Down approach
Bottom Up approach
Sandwich approach/Hybrid approach
Big bang approach

6. WBT…
1) Unit Testing:-
The every program testing is called Unit testing.
It is also known as Micro testing.
This is also classified into 3 types
Execution Testing
Operation Testing
Mutation Testing
Execution Testing:-
To check whether the program is able to run on developer platform or not is called
execution testing. Platform means that OS, browser, complier etc.
Here developers concentrate on below coverage
a) Statement Coverage
b) Condition Coverage
c) Loops Coverage

7. WBT…
Operation Testing:-
Run the program in customer’s expected platform to check whether this is
giving right output or not is called operational testing.
Mutation testing:-
It means that change in a program during the testing the programmers are
checking whether the program is given right output or not with respect to
change in a program.
2) Module Testing or Macro Testing:-
Conduct testing on couple of program is called module testing or Macro testing.

8. WBT…
3) Integration testing:-
During integration of main and sub module programmers are conducting integration
testing to insure inter connection of the system.
The different approaches are
a) Top Down approach(Customer req is clear n constant)
b) Bottom Up approach(Customer req is dynamic)
c) Hybrid approach(req is clear char of module is changing)
d) Big Bang approach(no of modules interconnected are less)

9. Testing Technique Used In BBT
1. Error Guessing Technique.
2. Error Detection.
3. ECP (Equivalence Class Partitioning).
4. BVA (Boundary Value Analysis).
1. Error Guessing Technique:-
* Hunting bugs on the most error prone area is error guessing technique.
* It is used in case of Input.
2. Error Detection:-
* In this technique testers have to detect bug from the most error prone area where
the possibility of finding bug are high.
* In case of test interface it is used.
* Error detection technique is used intentionally.

10. Testing Technique Used In BBT…
3. Equivalence Class Partitioning:-
* Collection of input and output data amongst which each and every data is going to
show same behavior on the application which called EC (Equivalence Class).
* The activity in which a class is divided into equivalence classes for the testing
purpose is called ECP.
4. Boundary Value Analysis:-
* To check the range of text box we use BVA or if the range is not defined then we will
not write BVA test cases.
* Maximum number of test case written is 6 and min is 2.
Min-1
Min+1
Max
Min
Max-1
Max+1

11. Types of BBT
Black Box Testing (BBT) is classified into four types
1. Usability Testing.
2. Functional Testing
3. Performance Testing.
4. Security Testing.
Core Level of
Testing
Advance Level
Testing

12. Types of BBT…
Usability Testing
User Interface testing Manual Support Testing

13. Types of BBT…
Functional Testing
Functional Requirement.
Input Domain Types & Range.
Compatibility/Portability.
Configuration/Input & Output Design.
Intersystem/End – To- End.
Comparative/Parallel.
Garbage.
Reliability & Recovery.

14. Types of BBT…
Performance or Scalability Testing
Load Testing Stress Testing Storage Testing Data Volume Testing
Security or Penetration Testing
Authorization Access Control Encrypt Decrypt Data Testing

15. Types of BBT…
1) Usability testing:-
In general a system testing starts with usability testing.
During this test, test engineers are checking whether the application build provide
user friendly screen or not.
A) User Interface Testing:-
During this testing test engineers are checking every screen in terms of
i) Understandability of screen
ii) Look and feel (attraction in software screen)
iii) Speed in interface (short time in navigation)
To validate above like factors test engineer follow 6 rules
i) Controls are INIT or not
ii) Ok, Cancel existence
iii)System menu existence
iv) Control must be visible
v) Control should be align
vi) Control should not be overlapped

16. Types of BBT…
Manual Support Testing:-
It is also known as help document testing.
During this testing test engineer validate the context sensitiveness of the
help document
2) Functional testing:-
i) Functionality Testing:-
During this testing test engg are validating every functionality in term of 6
coverage points
a) Behavior Coverage
b) Input domain coverage
c) Error handling coverage
d) Backend coverage
e) Calculation coverage
f) Scenario level coverage

17. Types of BBT…
ii) Input Domain Testing:-
In the above functionality testing the all coverage possible to do except
input domain coverage, due to this reason test engg are giving special
treatment to input domain coverage in terms of BVA and ECP
iii) Recovery or Reliability:-
During this test, test engg are validating whether the application which is
build is coming from abnormal state to normal state or not.
This is also known as reliability
iv) Compatibility:-
During this test, test engg are validating whether the application build is
supporting different platforms or not.
This is also known as Portability or Software Compatibility Testing.
Test engg check here Forward compatibility and Backward compatibility

18. Types of BBT…
v) Configuration Testing:-
During this testing, test engg validate that whether application build is
supporting different technologies, software devices or not.
This is also known as I/O device handling testing or Hardware Compatibility
Testing
vi) Intersystem Testing:-
During this test engg validate consistency with other existing software to
share common resource or not
This is also known as Inter operability testing or End to End testing.
vii) Comparative Testing:-
During this test engg are comparing company product with existing
product in market or same like previous product to estimate
competitiveness
This is also known as Parallel testing

19. Types of BBT…
Viii) Garbage testing:-
During this test engg are finding extra feature of application build with
respect to customer requirements
This is know as garbage testing.
3) Performance testing:-
After completion of Usability and Functional testing for one user the test engg test the
application with multiple user to estimate speed of processing
This is classified into 4 types
i) Load or Scale Testing:-
Run the build application in customer expected configuration under
customer load to estimate speed of processing is called load testing.

20. Types of BBT…
ii) Stress testing:-
Run the build application in customer expected load under with uniinterval
periods on different operation to estimate work continuation is called
Stress testing
iii) Storage Testing:-
Run the build application on customer expected configuration under huge
amount of resources to estimate memory capacity of application database
is called Storage testing
iv) Data Volume Testing:-
This is also used to estimate memory capacity of application database
during this test engg are calculating the no of records to be stored into
application database.

21. Types of BBT…
4) Security testing:-
To test privacy of application build engg are using this technique
Security testing is divided into 3 types
i) Authorization:-
During this test engg are checking whether a valid user is secure or not and
invalid user is unauthorized or not
ii) Access Control:-
Testers are checking during this test whether a valid user has a permission
to specific access or not
iii) E&D Testing:-
The code conversation between client process and server process to avoid
third party accessing is called E&D data testing

22. Gray Box Testing & UAT
Gray Box Testing:-
Combination of WBT and BBT is known as Gray Box Testing.
UAT or Green Box Testing:-
After completion BBT manager invites customer side people to the development site
to collect feedback on developed software.
This is also known as CAT(Customer acceptance testing) or UAT (User Acceptance
Testing)
There are 2 parts of UAT
i) Alpha Testing
ii) Beta Testing

23. Bug Life Cycle
Bug is deviation from the Expected Result to the Actual Result.
Life Cycle 1:
1)Tester finds a bug and report it to Test Lead.
2)TL verifies whether it is Valid/Invalid Bug.
3)TL finds it is an Invalid bug hence gives a status REJECTED to the bug.
Life Cycle 2:
1)As above
2)As above
3)TL finds bug a valid hence reports it to development team with NEW status.
4)Development leader & team verifies whether bug is valid or not.
5)They find bug is invalid hence gives a status “Pending/Reject” and send it back to
testing team

24. Bug Life Cycle…
Life Cycle 3: (Happy Path)
1)As above
2)As above
3)As above
4)As above
5)Development leader finds bug is valid hence gives a status OPEN to the bug and
assign it to developer for fixing the problem.
6)Developer solves the problem and send it back to development leader.
7)Development leader changes the status of bug as Pending Retest and send it back to
testing team.
8)TL changes the status of bug as RETEST and assign it to tester for retest.
9)Tester retest the bug and finds it is working fine so gives a status CLOSED to the bug.

25. Bug Life Cycle…
Life Cycle 4:
1)Step 1- Step 8 As above
9)Tester retest the bug and finds same problem persist in the software.
10)After getting confirmation from test leader, tester gives a status REOPEN to the
bug and send it back to development team.
Life Cycle 5: (In Gorilla Testing only)
1)Step 1- Step 4 As above
5)Development team fails to get the reason behind the problem so they ask help from
testing team.
6)Testing team also fails to regenerate the scenario hence development team gives a
status REJECT to the bug.

26. Bug Life Cycle…
Life Cycle 6:
Because of unavailability of data bug will be POSTPOND for indefinite time. this status
can be given by TL or development team.
Life Cycle 7:
If bug does not stand important it is DEFFERED bug. Like cosmetic bugs.

27. Bug Life Cycle…
Types of Bug:-
1) User Interface
a) spelling mistake
b) improper alignment
2) Error Handling
a) no error message pop up
b) complex meaning
3) Input Domain
not taking valid character or range
4) Calculation:-
final output is wrong

28. Bug Life Cycle…
5) Service Level/ Race Condition:-
system crash or deadlock
6) Load Condition:-
a) application is not supporting customer expected load
b) application is not supporting multiple users
7) Hardware/ Software:-
application is not supporting hardware or software
8) Version ID:-

29. Bug Life Cycle…
Bug Reporting/Tracking Format:-
This report is going to be prepared and maintained by testers.
1)Project ID
2) Module ID
3) Status
4) Assign to (Dev name)
5) Fixes on
6) Detected By (Tester name)
7) Reproducibility
8) Non reproducibility
9) Severity (by tester---high/medium/low)
10) Priority
11) Description
12) Test case ID

30. Capability Maturity Model
CMM was proposed by SEI of the Carnegie Mellow University of USA.
It was originally developed to access the US department of defense in software execution.
This model help in the organization to improve the quality of the software they developed and therefore
adoption of the CMM model head significant business benefits.
Many commercial org adopt CMM as a frame for their own internal improvements initiatives.
In simple words CMM is a reference model for inducting the software process maturity into different levels.
Optimizing
continuous Process Improvements
Managed
process control
Defined
process definition
Repeatable
Process discipline
Initial

31. CMM…
Level1/ Initial:-
A software development org at this level is characterized by ad hoc activities so very few or known
processes are defined and followed. Since software production processes are not defined, different
engineer follow their own process and as a result the development effort become CHAOTIC. The success
of project depends on individual effort.
Level2/ Repeatable:-
At this level the basic project management practices such as tracking cost and schedule or established size
and cost estimation techniques like function point analysis, COCOMO model are used. The necessary
process discipline is in place to repeat the earlier success on project with similar application.
Level3/ Defined:-
At this level the process for both management and development activities are defined and documented.
There is a common org – wide understanding of the activities, role and responsibilities the process though
defined. The process and the product quality are not measured.

32. CMM…
Level4/ Managed:-
At this level the focus is on software matrices. Two type of matrix are collected, product matrix and
process matrix. Product matrix measures the characteristic of the product being developed such as size,
reliability, time complexity and understandability. Process matrix reflect the effectiveness of the process
being used such as the average defect correction time, productivity etc.
Level5/Optimizing:-
At this stage the process and the product matrix are collected, process and project management data are
analyzed for continuous process improvments

33. Software Development Life Cycle
(SDLC)
• It is a period of time in which an application is conceptualized and expires at development
site. In this period we perform different activities.
The different phases of SDLC are:-
1) Requirement.
2) Designing
3) Coding
4) Testing
5) Release and Maintenance

34. SDLC…
The overall structure can be defined as:-
BDP(Business Development Process ) or BA (Business Analyst)
BRS (Business Requirement Specification)
URS (User Requirement specification)
CRS (Customer Requirement Specification)
FRS(Functional Requirement Specification)
Analyst Analysis SRS
SRS(System Requirement Specification)

35. SDLC…
HLD(High Level Design)
Designers Design
LLD(Low Level Design)
Programmers Coding Build(.exe file)
Testers Testing Functional and System Testing
Project Management Release and Maintenance

36. SDLC…
Requirement:-
Information Gathering:-
In general software development process starts with information gathering. In this
phase BDP/BA are developing the BRS/CRS/URS documents.
Analysis Stage:-
In this phase analyst people are developing SRS documents based on BRS.
SRS document consists of a functional requirement specification to be used in the
project and system requirement specification to be developed that functionality.
BRS User Name FRS/SRS
Password
ok cancel Help

37. SDLC…
Design:-
In this stage designing people are developing the required HLD and LLD with respect to
analysis document.
HLD or External Documents defines the overall structure of application functionality with
modules from root level to leaf level.
LLD or Internal documents define internal logic of every functionality in terms of ER Diagram
and DFD (Data Flow Diagram).

38. SDLC…
Coding:-
A physical Construct of a software is called coding.
1) A group of executable statement is called a program.
2) A group of program is called a module.
3) A group of modules is called a software.
4) A group of software is called PROJECT.
The developers create a BUILD here for testing.
Executable (.exe) form of all integrated module is called a BUILD.

39. SDLC…
Testing:-
After completion of build by developers before the build release to customer for
maintenance, testing people are performing functional and system testing to validate every
requirement in terms of completeness and correctness.
Release and Maintenance:-
After completion of testing phase the Project manager release the application to customer
for maintenance.

40. Software Testing Life Cycle (STLC)
• It is a period of which arranges all the testing activities right from beginning of testing until
testing stops.
• Phase of TDLC (Test Development Life Cycle):-
1) Test Requirement
2) Test environment setup/ Test bed setup
3) Test planning
4) Test design
5) Test automation
6) Test execution
7) Bug tracking and reporting
8) Retesting and Regression testing
9) Test closure

41. STLC…
1) Requirements extracted from SRS which are surely tested for test requirement
2) This is also called test bed setup. Initial s/w and h/w requirements are set for the testing
environment
3) Before real testing , planning for the test is done. Different types of test plans are made like
Master Test plan, System Test Plan, Acceptance Test Plan, Performance Test Plan, Integration
Test Plan, and Unit Test Plan is prepared.
4) Necessary documents for test design is SRS, FRS and Use Cases. If manual testing is selected
then test cases are designed where expected values are collected from requirement
specification.
5) If it is decided that functional, regression testing tool or any other tool will be used for
testing software then test scripts are prepared. Library files are also prepared according to
the framework decided by the company.
6) The prepared test cases or test scripts are executed on the received builds.
7) In the test execution phase if any test case or test script is failed then bug is detected by the
tester. If using automation tool then report bug using that tool or in manual then MS-Excel
8) Retesting or Regression Testing done.

42. STLC…
9) Test closure factors-
a) If all priority bugs are fixed
b) If threshold point is reached/ no new bug
c) if we are out of memory
d) if time is exhausted

43. STLC…
Types of Testing Life cycles:-
1) Fish Model
2) V model
3) PETT process
4) W model

44. STLC…
Fish Model
FRS SRS LLD HLD
LLD Analysis Design Coding Maintenance
BBT
Validation
Info Review Analysis Review Design WBT Testing S/w Clear
gathering
Verification
Fish model defines multiple development stages along with testing stages in above fig.

45. STLC…
V Model
Verification Validation
Requirement Acceptance Testing
if time left after preparation of acceptance test plan then Review (do acceptance plan/criteria) Detective
SRS System Testing
Review (System test Plan)
Architecture Integration testing
Design Review (Integration Test Plan)
Detailed Unit testing
Design Review ( Unit Test Plan) / (Module Testing)
Preventive Coding
Inspection
Review
Technical Review
Walk Through

46. STLC...
• Basic advantage of this model is parallel testing is going on.
• A product is called tested if both verification and validation is done.
• The initial SRS is draft SRS and after reviewing the draft SRS it becomes final SRS.
• Responsibility of preparing test plan is given to TL.
• In V model Unit Testing/ Module Testing is not done by developer in spite of that tester do it.
• Left side of V Model is called Static Testing and right side is called Dynamic Testing.
• Static testing is the testing in which we have to verify documents. We have to apply
preventive approach to detect error.
• Dynamic testing is the real testing which is performed according to the prepared plan on the
available builds. We proceed in dynamic testing from one level to another level.

47. Test Plan
• After completion of test initiation the PM finalize test strategy. That strategy is implemented
by test lead on project in terms of
1) What to test
2) When to test
3) How to test
4) Who to test
• This is called TEST PLAN
• Test lead category people are preparing system test plan and then they will delivering into
numbers of modules like test plan depending on project risk and team size.
• To develop test plan document TL follows below approaches
1) Team Formation
2) Indentify risk and mitigation
3) Preparation of test plan document
4) Review on test plan document

48. Test Plan…
1) Team Formation:-
Generally test plan preparation starts with team formation. In this test lead will go to finalize the testing team depending
on below factors
a) Availability of domain testers
b) Time duration
c) Resources / Tools
d) Project size ( number of modules )
2) Identify risk and mitigation:-
After completion of testing team formation test lead will identify possible problems with respect to selected testing team in
project.
Like problem and their respective solution.
3) Preparation of Test Plan Document:-
After completion of 1 and 2 test lead will go to prepare test plan document in IEEE format below
a) Test plan ID b) Introduction c) Test Items d) Features to be tested
e) Test approaches f) Features not to test g) Entry criteria h) Exit criteria
i)Test deliverables j) Test environment k) Staff & Training l) Responsibilities
m) Dates & Time n) Risk & Mitigation o) Approvals

49. Test Plan
Entry Criteria:- (When to start testing)
a) complete and correct test cases are in hand.
b) required test environment is there ( software & hardware)
c) Stable build from developers team
Exit Criteria:- (When to stop testing)
a) all modules testing done
b) all major bugs resolved
Deliverables:-
a) Test case design document
b) Test case review document
c) test case execution
d) test logs
e) Defect report format

50. Test Cases
• It is a document which contains testing objective, pre- conditions to test, expected result and
actual result.
• It depends on project as well as on domain type.
Object ( Prepare checklist Object+ property of object)
Test cases
Software
• To test a software or application we need 3 types of test cases to write
1) GUI Test Cases (here we can confirm appearance of the software)
2) Validation Test Cases (here we can check operational behavior)
3) Functional Test Cases (here we check functional behavior)

51. Test Cases…
1)GUI Test Cases:-
For GUI testing first prepare checklist and there will be object and their properties
Login
Agent Name
Password
ok cancel help
OBJECTS Properties
Login Dialogue Box a)location on desktop
Agent Name Label b)size
….. c)border color
….. d)active ……………….

52. Test Cases…
After preparing checklist for all the object now we are ready to write test cases on that.
Test Case ID Objective/Description Pre Required Input Expected Result Actual Result Result
TC 001 Verify login dialogue box AUT and PC click on AUT appear on appears on PASS
appearance on desktop link many time middle desktop middle desktop

53. Test Cases…
2) Validation Test Cases:-
a) we can test only in edit box, combo box, or in any input box
b) we write test cases where entry is possible
c) for writing test cases of validation we have to create test data
d) test data are of 2 types
1) Valid Data- known as +ve test cases
2) Invalid Data- known as –ve test cases
e) to create test data read specification
f) use BVA and ECP

54. Test Cases…
3) Functional Test Cases:-
a) functionality is always to be performed on commands
b) whenever we do functional testing we get a scenario or we use USE CASES
USE CASES
it is a pictorial representation of functional behavior of the system
it describes all the possible ways a user can interact with the system
ADMIN Transaction
New Ticket
CLERK Add Train
Delete
END USER View

55. Testing Matrix
When to stop testing is a testing matrix.
Traceability Matrix:-
To check the correctness of test cases
Mapping between requirement of client and the test cases
USE:-
a)write test cases for each and every requirement
b)do not write test cases that is not required
• In web based testing there is only link on the home page but in windows based there is only
object on the page
• In web based there may be a few object like search etc
• Internal Link------link of the same website
• External Link-----the new window should open it should not be there on home page
• Broken Link-------no page should open

56. Level of Testing
There are 5 level of testing:-
1) Level 0/ Unit Testing
2) Level1/ Integration Testing
3) Level2/ System Testing
4) Level3/ Acceptance Testing(alpha and beta testing)
5) Level4/Release Testing

57. Types of BUILDS
Initial Build
Sanity Testing
stable build
Test case exe
Retesting regression testing Modified Build
defect effected Build
fix and resolve
FSR (Complete Build)
Test Closure
PM/UAT Master Build
GOLDEN BUILD
SIGN OFF

58. AT A GLANCE
1) If all modules are working properly in integration then it is treated as a system then functional and non
functional behavior of the system is checked in SYSTEM TESTING.
2) Software may fall under project category or product category if there is a project then ACCEPTANCE
TESTING is done and if there is a product then UAT is done
3) If any testing is done informally or beyond the limit of test plan is called AD_ HOC TESTING
4) Sanity Testing:-
Here we do Cursory Testing. It is a subset of regression Testing in which cursory testing is done to
check that the major functionality is working as it was expected before the bug fixation
1) Smoke/BVT:-
This is the first testing applied after receiving a Build
The purpose for this testing is to check whether the build is stable or not meaning detailed testing
can be continued or not.
written test case are must in smoke testing or written test scripts