Regression
Testing, performed to validate the software following any code change, to
ensure the intent software functionality is working fine as expected after the
code change. It is basically re running the test cases after every software
build and before the software releases to the customer. Regression test cases
are best suit for the automation execution, since this test cases are executed
frequently.
Ad-Hoc Testing
Ad-hoc
Testing is unstructured and no formal test cases or documentation are needed to
test the software. This testing can be performed right after the software build
deployment to validate the very basic features of software, before we start the
formal testing. This testing will benefit to detect the defects at earliest.
Performance Testing
Performance testing is a type of software testing, which is
to verify the non-functional features of the software like speed & stability
of the system. The goal of this testing is to identify the performance of the
system.
Some types of the performance testing are,
- Load Testing
- Stress Testing
- Volume Testing
Load Testing:
Load testing is a type of performance testing, where it is to
test the application to identify its performance on normal & peak usage. The
goal is to identify the bottlenecks in the system by applying estimated load to
the system.
Stress Testing:
Stress testing is applying the load gradually to the system,
at some point the system will break with non responsive state for the request’s.
This state is considered as the breaking point.
Volume Testing:
Volume testing is storing a large volume of data in the data
base, to identify the overall performance of the system behavior. The goal is to
verify the system performance with different volume of data.
Shakedown Testing
Shakedown Testing is type of software testing, that is performed in the application to test basic functionalities are working fine without any issues. This testing is kind of entry criteria for the actual in-depth testing.
We cannot start the in-depth testing, if any major issues reported
during the shakedown testing.
As a simple example, we cannot start a actual in-depth testing, if we encounter a login issue to access the application, that was reported during shakedown testing
System Testing & Acceptance Testing
System
Testing is level of the software testing performed to test completely developed/integrated
software to verify and validate the end to end functional and non - functional behavior
of the software as per customer requirements.
To perform System testing it is not mandatory to have knowledge on the internal working
structure of the software and it is enough to have knowledge on the external
working of the software, due to this the system testing activities falls under
black box testing.
Acceptance
Testing:
Acceptance
Testing is usually done by the client or the end user to verify that it meet
the expectation based on the business requirements given to the software
company/vendors. In this testing, client verifies and accepts the software
product if it meet their criteria. This is also referred as UAT (User
acceptance testing).
Acceptance
testing is done once the system testing is completed successfully.
In the below case, assume the product school management
system is given to the software company for development. Once company develops the
product, it is pushed for the system testing. From the successful system
testing phase, further the software product is ready to deliver to the client
for the acceptance testing. In this level of testing, client validates the
software product based on the business requirements.
 |
| Acceptance Testing |
Software Testing and its Types
What is
Software Testing?
Software Testing is the process of executing or evaluating the
developed software, to maintain the software quality or verifying and
validating the software is working as per customer requirements/expectation.
Types of Software
Testing:
- White Box Testing
- Black Box Testing
- Gray Box Testing
- Functional Testing
- Integration Testing
- System Testing
- Acceptance Testing
- Performance Testing
- Load Testing
- Volume Testing
- Ad-hoc Testing
- Regression Testing
- Link Testing
- Compatibility Testing
- Web Testing
- Static Testing
- Dynamic Testing
- Alpha and Beta Testing
Black Box and White BoxTesting
Black box testing is a Software testing technique to test the
functionality of software without having knowledge on internal working
structure of the code. This kind of testing is done based on requirements of
application. For black box testing it is not mandatory to know internal working
structure of software and it is enough to have a functional knowledge of the
software.
For example:
Login Screen with user name and
password input field.
1) Provide valid input for user name
and password and verify we can able to login successfully.
2) Provide invalid input for user
name and valid password and verify we should not able to login.
In this case we don't know the
internal working structure of code, just tester should know knowledge on valid
input to login successfully and invalid input for unsuccessful authenticate.
White Box testing done based on analysis of internal working structure of software/program. It is also known as structure/clear/glass box testing. White box testing is performed based on the knowledge of how the system is implemented. Mostly developer may do this testing, because they are well known on the internal working structure of the program such as statement coverage, branch coverage and path coverage.
Black box design techniques
The below three are black box design
techniques:
o Equivalence Partitioning
o Boundary Value Analysis
o Error Guessing
Equivalence Partitioning:
Equivalence partitioning is the
black box testing technique.
This technique helps us to divide
the set of test condition into a partition that can be considered the same
condition.
Advantage of this technique is to
reduce required time by testing all the required coverage of the software with
fewer test cases than many test cases.
For
Example:
Assume, text box called ‘age’ exist
in software, as per function it should accept 1 to 100 as age limit, it should
not allow to accept less than 1 and numbers greater than 100.
|
Conditions
|
Without equivalence partitioning
|
Using equivalence partitioning
|
|
Should accept 1 to 100
Should not accept negative values
(-1,0)
Should not accept (> 100)
|
It’s required to write 100
+ test cases.
Test case 1 : To test input number
‘1’,
Test case 2: To test input
number ‘2’,
Test case 3: To test input
number ‘4’…. So on up to 100
Test case 101: For >100
Test case 102: For < 1
|
It’s enough to write three
test cases to test all the condition using equivalence partitioning.
Test case 1: One valid input from
1 to 100.
Test case 2: One invalid input
< 1.
Test case 3: One invalid input
> 100.
|
Boundary Value Analysis:
Boundary value analysis is a black
box testing technique is used to test the boundary values rather than testing
the interior values.
For
Example:
Assume, text box called ‘age’ exist
in software, as per function it should accept 1 to 100 as age limit, it should
not allow to accept less than 1 and numbers greater than 100.
|
Conditions
|
Without Boundary Value Analysis
|
Using Boundary Value Analysis
|
|
Should accept 1 to 100
Should not accept negative values
(-1,0)
Should not accept (> 100)
|
It’s required to write 100
+ test cases.
Test case 1 : To test input number
‘1’,
Test case 2: To test input
number ‘2’,
Test case 3: To test input
number ‘4’…. So on up to 100
Test case 101: For >100
Test case 102: For < 1
|
It’s enough to write three
test cases to test all the condition using equivalence partitioning.
Test case 1: Input Exact boundary
value 1 and 100.
Test case 2: Below the extreme
boundary edges of input value 0 and 99.
Test case 3: Above that extreme
boundary edges of input value 2 and 101.
|
Error Guessing:
Error guessing is the black box
design technique, which focuses on identifying the defects without having
formal documentation. This technique usually performed by the experience tester
with enough knowledge on functionality.
Spiral Model
Spiral model is the combination of waterfall and iterative model.
In this model each phases starts with requirements and ends with customer
evaluation. This model is old but useful for larger projects, where high risk
involved.
Different phases of Spiral model:
- Planning
- Risk analysis
- Engineering
- Evaluation
 |
| Spiral Model |
Planning Phase: In planning phase requirements (Software
Requirement Specification) are collected and documented.
Risk Analysis Phase: In risk analysis phase, a process is
undertaken to identify risk and different solutions. A prototype is
produced at the end of the risk analysis phase and if any risk is found during
the risk analysis then alternate solutions are suggested and implemented.
Engineering Phase: In this phase software is developed and tested as per requirements.
Evaluation phase: In this phase the customer evaluates the
functionality of the project before the project continues to the next spiral.
Advantages of Spiral
model:
- High amount of risk analysis is done; hence avoidance
of Risk is enhanced.
- Better option to use spiral model for large or long
term projects and critical projects.
- Strong approval and documentation control.
- Additional Functionality can be added easily.
Disadvantages of
Spiral model:
- Risk analysis requires highly experienced and specific
expertise.
- Costly Model to use.
- Project’s success is highly dependent on the risk
analysis phase.
- Not suitable for smaller projects.
Iterative Model
Develops
a partial implementation of software, slowly add increased functionality.
Subsequent release of the system merges function to the earlier release, until
all designed functionality has been implemented. The incremental model
prioritizes the requirements of the system and then implements them in groups.
The approach in this method is to develop the software through iterative
(repeated cycles)
 |
| Iterative Model |
Advantages of iterative
model:
- The software is developed and improved step by step;
this helps to track the defects in earlier stage, to avoid the defects to
the next iteration.
- Can get continuous feedback from the user in each
iteration. The user feedback from iteration 1 can be enriched/implemented
in iteration 2……iteration n +1.
Disadvantages of
iterative model
- Not all the requirements gathered at initial stage, so
design issues may get in every iteration based on the feedback.
- More resources may require and this suitable only for
larger projects.
Waterfall Model
Waterfall Model is sequential
design process, used in software development process. Water fall model consist
of five phase, each phase must be completed before starting the next phase.
Waterfall model is first development process introduced for software
development. Water fall model is very simple and easy to use.
 |
| Waterfall Model |
Advantages of Water
Fall Model:
- Requirements are well documented.
- Easy to manage.
Disadvantages of
Water Fall Model:
- Post Defect fixing is difficult, and expensive to fix.
- Difficult to design for larger projects.
- This model does not work smooth, if there are some
issues left at the previous step. It has to maintain perfect smooth and
sequential in step by step.
Requirements Traceability Matrix (RTM)
The Requirements Traceability Matrix (RTM) is a document that contains requirements of
the system and traces them throughout the system validation process. The need
of RTM is to ensure that requirements of the system is covered and tested
through validation or testing process.
RTM
will helps to identify the test coverage status and progress, with the help of
RTM we can identify the overall picture of system quality. It ensures 100% test
coverage as we trace the requirements and its expected results in the document.
 |
Ex: Requirements Traceability Matrix
|
Types of Software Testing
Software testing is the
process of executing or evaluating the developed software, to maintain the
software quality or verify and validating the software is working as per
customer requirements.
Types of Software
Testing:
- White Box Testing
- Black Box Testing
- Gray Box Testing
- Functional Testing
- Integration Testing
- System Testing
- Acceptance Testing
- Performance Testing
- Load Testing
- Volume Testing
- Stress Testing
- Ad-hoc Testing
- Regression Testing
Software Development life Cycle (SDLC)
 |
| SDLC |
Software Development life Cycle
(SDLC) is concept used in software engineering
to describe a process of planning, developing, testing and deploying the
software system. Following is the different phases of SDLC life cycle,
Requirement
Analysis Phase
Software
Development Life Cycle (SDLC) starts with Requirement Analysis phase, where the
stakeholders discuss the requirements of the software that needs to be
developed. The aim of the requirement analysis phase is to document SRS
(Software requirement Specification) in detail to make sure everyone
understands the scope of the work.
Design
Phase
During
the design phase, developers and technical architects start the high-level
design of the software as per SRS document.The Technical details
of the design is discussed with the stakeholders and various parameters such as
risk, time and budget are reviewed and design is documented.
Implementation
Phase
After the
requirements and design documentation is completed, the third phase of the
Software Development Life Cycle is the implementation or development of the
software. In this phase, developer’s starts writing code according to the
requirements and the design discussed in the design phase.
Testing
Phase
Maintenance
Phase
In
Maintenance phase the product is released and deployed in the client system for
use. In this phase development team will maintain the system to fix post
production issues.
Integration Testing
Integration
Testing is the type of software testing, which individual
modules/components of software is combined and tested as a group; this is done
once the individual modules/components are tested and validated. Integration
Testing is done with intention to reveal the existence of issue/failure between
the modules of software.
 |
| Integration Testing |
Here before starting
integration test, as a unit module 1, module 2 and module 3 tested
individually. Once having successful validation on the individual modules,
finally all the modules are combined and tested as a group which meant
integration testing.
Methods
of Integration Testing:
Two
Types of approach in integration testing,
1.
Big Bang Approach
2.
Incremental Approach
a.
Top down Approach
b.
Bottom up Approach
Big Bang Approach:
In this approach,
completed individual modules are not tested at initial, instead once all the
modules are ready, and are integrated and tested at a once. Consider the above
picture, without testing individually module 1, module 2 and module 3, all the
modules are combined and tested at a once.
Incremental
Approach:
In this
approach, once the individual modules are unit tested successfully, and further
testing is carried on by integrating two or more modules, this will continue
till all the modules are combined and tested successfully. Consider the below
picture once module 1 and module 2 is ready, those are integrated and tested
successfully.
 |
| Incremental Approach |
Bottom up
Approach:
In this
approach, test starts from the lowest module and finally with the higher
modules.This testing will continue till all the modules are integrated and test
completed from lowest to highest modules.
In this
scenario module 3 and module 4 are lowest modules that are developed and test
completed. But still the higher module 1 & 2 not yet developed, since the
higher modules having the function’s to call the lower modules, so in this
place ‘Drivers’ are used as dummy program of module 1 & 2 to integrate with
module 3 & 4. This approach helps to detect the failure at early stage in
the lowest modules.
 |
| Bottom up Approach |
Top down
Approach:
In this
approach, unit test starts from the highest module and finally with the lower
modules. This testing will continue till all the modules are integrated and
test completed from top to lowest modules. Assume here top is module 1,
and it’s developed and unit tested and still module 2 is not yet developed it
is in progress. In order to test module 1 with 2, ‘Stubs’ is used in the place
of module 2. ‘Stubs’ is dummy program which acts as lowest module to integrate
with highest modules.
 |
| Top Down Approach |
Subscribe to:
Comments (Atom)