Manual Testing Overall - Notes
Manual Testing Overall - Notes
com
9123820085
Manual Testing
Overall Notes
hr@kasperanalytics.com
kasper-analytics
kasperanalytics.com
9123820085
1) REQ: requirement
2) Defect: it’s a deviation in the with respect to requirement
3) Bug: it’s a informal name of a defect. Whenever a defect is found by a
test engineer it should be released to the developers. Once the
developers accept the defect it is termed as defect.
4) Error: mistake in the source code is known as error.
5) Issue: problem faced by the customer or the end users.
6) Failure: multiple issues will lead to the failure.
When the end users face lot of issues that will lead to the failure.
QA and QC
It is a process oriented
It is a product oriented.
QA QC
hr@kasperanalytics.com
kasper-analytics
kasperanalytics.com
9123820085
Eg . www.dev.facedook.com www.qa.facebook.com
www.facebook.com
We have the different servers because developers, test engineers, end users
should use the application and work independently.
When developers are working for 1 feature. That feature is given to testing team
during that time developers start working for another feature
Due to this
Stake holders
A person who directly (or) indirectly involved in a software application (or) project
is a stake holder.
hr@kasperanalytics.com
kasper-analytics
kasperanalytics.com
9123820085
BA should be good in
1. Communication skills
2. Domain expert
3. Convencing skills.
4. Technical expert.
BA collects all the requirement from the customer is called requirement analysis.
Feasibility study: in this phase BA, HR, ARCHITECT, FINANCE, PM will discuss all the
information that is needed.
hr@kasperanalytics.com
kasper-analytics
kasperanalytics.com
9123820085
Pm will take the final decision and gathers all the data information to proceed for
the next step or not.
Design: once everything is fine, we go for the design.in design we have HLD and
LLD. Usually design phase is done by the architect or senior developers
High level design: is just like a blue print .it shows the external specification of the
project. Low level design: shows the internal specification of the project.
Coding: once the design is done developers starts writing the code for application
by looking at design or requirement.
Testing: once coding is done developers will give application to test engineers. All
test engineers start finding the defects. If any defects are found in software
application, it again goes back to the developers like this process continues.
Installation: making the software application available for end users is called
installation. It is done by the software company once testing is completed.
Customers should approve for installation.
Maintenance: once software is provided to customer or end users if they face any
problem a support has to be provided that is maintenance.
Initially it will be free. later it will be paid. Free service will be provided based on the
agreement b/w customer and company. During maintenance defect fix will be
handled and changes will be taken care.
hr@kasperanalytics.com
kasper-analytics
kasperanalytics.com
9123820085
1. Developers always focus how to build the software not to break the
software.
2. They always be over confident what they do.
3. They does not like to find there own mistake.
4. Since it is not easy to find there own mistake , even though mistake are
there they will hide it.
hr@kasperanalytics.com
kasper-analytics
kasperanalytics.com
9123820085
Spiral model
1. Customer can see the application partially and can get confidence.
2. Requirement changes can be done.
hr@kasperanalytics.com
kasper-analytics
kasperanalytics.com
9123820085
V and V model
hr@kasperanalytics.com
kasper-analytics
kasperanalytics.com
9123820085
advantages of V model
Drawbacks of V model
V and V means verification and validation model. It is one of the best model in
SDLC. In this model the development and testing are done parallelly the left side
of model is done by developers and the right side of the model is done by the test
engineers.
When the customers give the requirement of 100 pgs documents in the form of
CRS. It is converted in the form of SRS by BA. At some time, review of CRS is done
by test engineers. If there is any mistakes it goes back if not it will continue the
process. The SRS will review against the CRS to find the defects. Parallelly they do
the test plan and test cases will be ready for the application to test.
Once the documentation of development process is done, with the design and
coding, the software is ready for testing.
First testing is white box testing. This testing is done by the developers, then there
will be FT it is done by the TE. At the same time the execution of the test cases are
also done.
After FT the IT is done, test cases are same for all the application for execution.
Later ST and then AT is done by the customer then it is released to end users.
The review of the document is verification and it is based on QA. The testing of
application is validation and it is based on QC.
hr@kasperanalytics.com
kasper-analytics
kasperanalytics.com
9123820085
Prototype model
hr@kasperanalytics.com
kasper-analytics
kasperanalytics.com
9123820085
hr@kasperanalytics.com
kasper-analytics
kasperanalytics.com
9123820085
SOFTWARE TESTING
MANUAL TESTING
Testing the software without using any tool and ensure its working fine.
AUTOMATION TESTING
Testing the software by using the tool to ensure it is working fine. (the tool can be
selenium)
Examples
Every software is developed for business purpose if testing is not done, end users
may find the defects while using the applications.
This will spread negative impact in the market and number of users who uses
application will be reduced. This will become loss for the investor on business. To
avoid all those things s/w testing has to be done before it is released to end users.
SCENARIOS
Testing the application in all the possible ways is scenarios. It can be +ve
scenarios or -ve scenarios.
Testing the application with valid or expected data is called +ve scenarios. It is
also called positive testing.
Testing the application with invalid or unexpected data is called -ve scenarios. It
is also called negative testing.
hr@kasperanalytics.com
kasper-analytics
kasperanalytics.com
9123820085
To identify the defects we should find the scenarios first. Scenario is not a defect
or defect is not a scenario.
Few cases we may get confused whether it is a +ve scenario or -ve scenario. In
this case we can judge whether it is a defect or not a defect based on REQ.
RETESTING
hr@kasperanalytics.com
kasper-analytics
kasperanalytics.com
9123820085
1. Load runner
2. J meter.
3. Qa Load
4. Silk performer.
5. Neo load
hr@kasperanalytics.com
kasper-analytics
kasperanalytics.com
9123820085
Using the above tools we can manage the testing activities like below
Req-add requirement Test plan-write test cases Test lab-execute test case.
1. Going through the req given by the customer and adding to the test
management tool.
2. Write test cases by identifying scenarios
3. Execute test cases.
4. Find defect , report defect , and track.
In Bugzilla we cannot add the requirement write test cases and execute test
cases. We can only report the defect and track the defect.
hr@kasperanalytics.com
kasper-analytics
kasperanalytics.com
9123820085
testing the source code or internal structural of an application is called White box
testing.
It is usually done by developer.
testing the source code and user interface of an application parallelly Together is
called gray box testing.
hr@kasperanalytics.com
kasper-analytics
kasperanalytics.com
9123820085
Junit: when the source code is written in java to test that we use junit.
Nunit: when the source code is written in .net to test that we use nunit. Selenium is
a tool to test the black box testing.
hr@kasperanalytics.com
kasper-analytics
kasperanalytics.com
9123820085
It will tell all the possible ways we can test It is step by step procedure to
theapplication test theapplication.
Scenario doesn’t have a navigation steps. Test cases have a navigation steps.
Scenarios doesn’t say where the exact Test cases will tell where the exact
defect isthere defect ispresent.
Scenarios take less time to write. Test cases take more time to write.
Test cases
When the developers are developing the application, we will write a test case.
Under the test case preparation, we have to fill following sections like
1. Step no
2. Description
3. Input
4. Excepted result.
5. Actual result
hr@kasperanalytics.com
kasper-analytics
kasperanalytics.com
9123820085
1. Actual result.
2. Status.
3. Comments.
hr@kasperanalytics.com
kasper-analytics
kasperanalytics.com
9123820085
It is the procedure to test the software application. It has a different stages and
phases like
hr@kasperanalytics.com
kasper-analytics
kasperanalytics.com
9123820085
System study: it is going through the requirement given by the customer and
understands how the system works.
Write test plan: it is a document which is prepared for feature to do the testing
activates.
It is done by the test lead or test manager in the testing field. Because the plans
where done by experienced people.
Write test cases: it is a step by step procedure to perform the testing on the
application. It is done by the test engineer. Once we go through the requirement,
we identify the scenarios and then converted into the test cases. To write the test
case we need requirement and test case template or tools (qc/alm, JIRA)
Execute test cases: once the requirement is given to the test engineer. He writes
test cases for the application. After the developer gives the developed application
then the test cases are compared with expected result and actual result. If the
expected result and actual result are same then the status is pass, if the expected
result and actual result are not same status will be fail. This is called execute test
cases. So, to execute test cases we need test cases and software application. This
is were the exactly the software is been tested. This is the most important phases
of software testing life cycle.
Defect tracking: while executing the test cases we may come across the defects.
These defects are raised to the developers and they accept defects and starts
fixing it. This is called defect tracking. It is done by using tool called “Bugzilla”.
Test execution report: once we execute the test cases. we should prepare one
document called test execution report. This document tells about how many test
cases are pass and how many test cases are fail.
Till here customer involvement will be there according to the customer this is the
end of the project.
hr@kasperanalytics.com
kasper-analytics
kasperanalytics.com
9123820085
Retrospective meeting: in this meeting all the team members will gather together
like PM, TL,DL, TL DEV,BA, TM and they discuss about the good and improvements
needed once the project is done. This will be very useful for next release or next
project.
When we are executing the test cases if the excepted result and actual result are
not same we come across the defect, then the defect are raised to the developer
then the status will be new/open. And the new defect is assigned to the developer
or development lead. The developer will reproduce the defect and accepts it.
Then he start fixing the defect in the development server. When he fixes the defect
he will change the status as fixed. The defect which is fixed is installed in testing
server. The test engineer start retesting the defect fixed in the testing server. If the
defect is properly fixed then the status will be closed. If the status is not properly
fixed then again, the defect is reopened to the developer.
hr@kasperanalytics.com
kasper-analytics
kasperanalytics.com
9123820085
What is differed/postpone?
Whenever test engineer raises the defect the developer accepts the defect but he
will not fix the defect. He will give the status as differed/postpone.
Whenever there is a major defect or minor defect. Developer have less time to fix
the major defect. In this case the developer will fix the major defect and for minor
defect he will assign status as differed or postpone.
Whenever the test engineer finds the defects and he did not raise it. If another test
engineer finds the same defect and he raise it unknowingly. Then this status is
known as duplicate.
To avoid this when the test engineer finds the defects, he should raise it
immediately so that there will not be duplicate defects
Can’t be reproduce
When the test engineer finds the defects but developer cannot be able to
reproduce that defect. So he will change the status as “cannot be reproduce”.
1. Installation problem
2. Improper defect report.
3. Inconsistent bug.
Can’t be fixed
Whenever the developer is unable to fix the defect that is raised by the test
engineer, then he changes the status as “can’t be fixed”. And it is a void defect but
he can’t fix the defect.
Even though the developer does not fix the defect, it should not affect the
business. If the technology doesn’t support to fix the defect.
hr@kasperanalytics.com
kasper-analytics
kasperanalytics.com
9123820085
Invalid/reject
Whenever the test engineer raises the defects but developer will not accept the
defects and he change the status as invalid/reject.
New/open->assign->invalid->closed
New/open->assign->invalid->reopen->fixed->closed
Whenever the test engineer raises the defect which is not given in the
requirement so the developer will take it as suggestion. In this case he will change
the status as RFE.
hr@kasperanalytics.com
kasper-analytics
kasperanalytics.com
9123820085
Severity
Severity will tell how much that defect effect to the customer business is known as
severity Types of severity
1. Blocker
2. Critical
3. Major
4. Minor
5. Trivial: this defect is negligible.
PRIORITY
Priority says which defect has to be fixed first by the developer. For every defect
we have to set priority.
1. High
2. Medium
3. Low
Developer or managers can discuss about this if they want to change it they have
to provide proper justification.
Priority is very much important for the developer to decide which defect has to be
fixed first
If priority is not their developer may fix the easy defects and they leave all the
important defects
As a project point of view the important part of defects has to be fix earlier.to
manage these things we have severity and priority for each and every defect.
hr@kasperanalytics.com
kasper-analytics
kasperanalytics.com
9123820085
Author
Reviewer
Approved by
Approved date
Header part
Pre conditions: it is the action which we should do before executing the scenarios.
Test case type: in this section we should write which type of testing we are going
to use.
Priority: assigning the priority to each and every test cases will help us in
prioritizing the defects
hr@kasperanalytics.com
kasper-analytics
kasperanalytics.com
9123820085
When ever the test engineer finds the defect it has to be raised or logged or
reported to developer. For this we have to create a defect report.
When we create the defect report in tools like BUGZILLA, or by using the excel file or
word documents
Expected result
Actual result
Attachment of screen
shot
hr@kasperanalytics.com
kasper-analytics
kasperanalytics.com
9123820085
ACCEPTANCE TESTING
(or)
It is an end to end testing which is done by the customer to ensure the application
is fit for business scenarios or not.
This is mainly done to get a confidence for customer before he releases the
product to the end users.
If the product is released to the end user without checking the business scenarios,
it will affect the customer business. To avoid this acceptance testing has to be
done.
We may forget some of the business scenarios to test and those scenarios would
be tested by the customer
Note:
if the customer finds the defect during the acceptance testing. That is a negative
path to the test engineers.
So before finding the any defect we should think all those business scenarios and
finds defects.
hr@kasperanalytics.com
kasper-analytics
kasperanalytics.com
9123820085
Alpha testing and Beta testing are types of acceptance testing Difference
between alpha and beta testing
When the software company releases the product to customer if the customer
finds any defects in the software. The customer will send the application back to
the software company, and software company should fix the defect as early as
possible and give back to the customer. This situation is called hotfix.
If any problem is find by the customer or end user in the production server, it will
be raised as the incident to the software company. Every incident is raised in the
form of ticket and every ticket will have a priority.
hr@kasperanalytics.com
kasper-analytics
kasperanalytics.com
9123820085
Whenever there is a production issue all the team members will gather together,
and they discuss about reason for production issues that is documented in the
form of fish bone diagram. The main purpose of this is to find the root cause of the
production house.
Between two planned release of the application some times the customer gives a
unplanned release which is done in short duration. It is called short term release.
The build has to be installed from development server to testing server. It will be
done by the installation team or testing team.
hr@kasperanalytics.com
kasper-analytics
kasperanalytics.com
9123820085
Once build is installed to the testing server testing team will perform different type
of testing depending upon the content of the build ex. For new features, FT, IT, will
be done for old features regression testing. for defect fixes retesting will be done.
While doing the testing we find the defects that will be raised to the developers.
Development team will reproduce the defect and they will fix it in the local system
and it is saved in the repository again. Same process will be repeated for every
build, until we get the final stable build.
Once the testing is completed, we will give the application to the customer for
acceptance testing. Customer will do acceptance testing in the testing server or
customer will have their own server called user acceptance testing server (UAT
Server).
Once everything is fine application is released to end users that is for production
server. This is called production release.
What is release?
Starting from gathering the requirement, developing the application, testing the
application, finally releasing it to the end users is called release.
What is a build?
The compiled and compressed format of source code is called build. A build
contains different formats like compress and archive.
Compress format:
1. Zip
2. Multiple lives can be made in single file.
3. Size of the file will be reduced.
Archive format
hr@kasperanalytics.com
kasper-analytics
kasperanalytics.com
9123820085
A build contains
1. New features
2. Old features
3. Defect fixes
It depends upon the contents which developer will add inside an build, and it
varies from build to build.
It is effort or time spent to test the application once the build is given. The duration
of each test cycle can be days, weeks, months, depending upon the build
The first release of first build1 we cannot do retesting and regression testing, for
other builds we can do retesting and retesting based on the situations.
hr@kasperanalytics.com
kasper-analytics
kasperanalytics.com
9123820085
TEST STRATEGY
Test plan
based on that approach we decide one approach and we plan based on that
A good test case should have the header, body and footer sections. It should
contain the attributes which are easily understandable.
1. Step no
2. Description
3. Input
4. Expected result
5. Actual result
6. Status
7. Comments
If the test case contains all the possible scenarios that can be called good test
case.
a good test case is a test case which is easily understandable to every test
engineer. It should cover all the scenarios with respect to requirement.
A good test case should be written by applying like boundary value analyses,
equivalence partitioning, error guessing.
A test cases has to be reviewed by another test engineer and find mistakes in it.
Those mistakes have to be corrected then it becomes a good test case.
What would you do if you have a large suite and execute it in very less time?
First, we have to execute the basis features of an application that is smoke testing.
hr@kasperanalytics.com
kasper-analytics
kasperanalytics.com
9123820085
How do you ensure that the testing having the good coverage?
Test engineer will get confidence on basic features, that is working fine
If we find the defect in the basic features only, that create a good impact on the
testing team
If there are any blocker or critical defect found in the basic features, developer will
get more time to fix the defect.
hr@kasperanalytics.com
kasper-analytics
kasperanalytics.com
9123820085
Once the build is given by the developer, we start doing smoke testing first.
For every build given by the developer we start with smoke testing first we assure
basic feature are working fine.
When time is less for testing team to do the testing, we will do smoke testing and
if the customer is fine, we will release to customer.
It is testing the basic features only It is testing the new features and bug fixes
Only positive testing is done Both positive testing and negative testing
aredone
Testing the application randomly without following any formal documents like
requirement, test cases etc.
1. Children
2. A person with happy mode
3. A person with depressed mode.
4. A drunken person
hr@kasperanalytics.com
kasper-analytics
kasperanalytics.com
9123820085
When we are not able to get the defect through over regular testing like FT, IT, ST
we can think about adhoc testing so that we can get more defect.
This is the best testing for gaming application. Because while playing games
usually children will click where ever they want without their knowledge.
This testing is mandatory for gaming applications, for other applications we will
do testing based on customer request.
When we are not getting much defects with functional integration and system
testing think about adhoc testing we will get definitely defects.
All the defects we found through adhoc testing need not to be fixed by the
developer unless it is crashing the applications.
Response time: time taken to get the expected screen based on the user actions.
Load testing:
Testing the response time of an application by applying the load which is less
than or equal to designed number of users. (it will be given by customer).
Ex: if the customer want application for 1 lakh users then the designed number of
users are 1 lakh.
Stress testing:
Testing the response time of an application by applying the load which is greater
then designed no of users, that can be around 10-20% greater than the load.
hr@kasperanalytics.com
kasper-analytics
kasperanalytics.com
9123820085
Yes, we can do performance testing manually but there are some drawbacks likes
So we go for automation
Volume testing
Ex data sharing through share it, Bluetooth, google drive by uploading more
photos.
Sock testing
Ex 72 hrs users are using application continuously to check the response time
RELIABILITY TESTING
hr@kasperanalytics.com
kasper-analytics
kasperanalytics.com
9123820085
TYPES OF APPLICATIONS
1. Standalone applications
2. Client server application
3. Web applications
Standalone applications:
This kind of applications can be installed, accessed and used without any
dependency on server or internet.
1. Client software
2. Server software
Client software will be installed by the end users usually from play store. Server
software will be available at the company location.
To use client software to interacting with each other, we need server software. To
connect to the server software, we need internet.
In client server application static elements will be already stored in the mobile ,
only dynamic elements will be accessed through the internet.
This is the fastest compared to the web application and slower compared to
standalone application.
Web application:
In this we access the application through the browser. Here static and dynamic
element will load together.
hr@kasperanalytics.com
kasper-analytics
kasperanalytics.com
9123820085
Ex: we can access gmail or fb any other application by entering the url into the
browser. We need internet connection compulsory.
COMPATIBILITY TESTING
Testing the applications with different hardware and software platforms is called
compatibility testing.
To ensure that application is working for multiple platforms because there might
be different types of users.
GLOBALIZATION TESTING
When the language is changed the translated content is not proper because a
machine translator could not understand the exact meaning of the word
displayed because of below reasons
All this are reason for wrong translation. So, we go for human translator.
If a person is very good with multiple languages local and international, we could
perform good globalization testing.
1. I18N: internationalization
2. L10N: localization
hr@kasperanalytics.com
kasper-analytics
kasperanalytics.com
9123820085
Internationalization
Testing the application weather, it displays the right content at the right place in
the right language is called I18N.
Localization
Testing the application with respect to the local culture or local standard to that
country or state or region is localization testing.
ACCESSIBILITY TESTING
Testing whether the application is suitable for physically challenged people or not
Ex RGB (red green blue) should not be used in the application.
Music and keyword: anybody is injured wrist they can still use the application
using the keyboard.
1. In focus
2. Wave
RECOVERY TESTING
AESTHETIC TESTING:
USABILITY TESTING
hr@kasperanalytics.com
kasper-analytics
kasperanalytics.com
9123820085
Test strategy:
TEST PLAN:
Test plan is a document which is prepared for future testing activities. It is usually
prepared by the test lead or manager.
Test engineer can also involve – if there is any support needed for test lead or
manager. Test plan contain different sections or attributes like
1. Objective: this section tells about the purpose of preparing the test plan.
2. Scope: limitations
hr@kasperanalytics.com
kasper-analytics
kasperanalytics.com
9123820085
7. Risk: this section will tell about what are the possible risk happen during
the project. The possible risks are team members will quit the job
suddenly and abscond.
8. Contiguity plan or mitigation plan: this section will tell about how to over
come the risk which occurs during the process.
to avoid this regular knowledge transfer or cross sections should
happen inside the company.
This section will contain what are the roles and responsibilities for team members.
Ex roles and responsibilities for test engineers.
We should perform above task plus we should write test scripts and execute test
scripts by using the selenium tool. Manage test script.
Environment: this section contains what is a platform we are using for testing
purpose ex. Window 10,8,7 chrome browser,
Deliverables: this section will tell what are the documents that should be prepared
for the project ex test plan, RTM, source code, defect, reports etc.
Graphs and matrices: this section contains the graphs and matrices that are
prepared for project.
Mapping from requirement to test case to automation test script to defect. This is
called forward traceability matrix.
hr@kasperanalytics.com
kasper-analytics
kasperanalytics.com
9123820085
Mapping from defect to automation test script to test case to requirement this is
called
Mapping from test case to requirement and test case to automation test script to
defect this is bidirectional traceability matrix.
Mapping from test case to automation test script to defect can be traceability
matrix.
When we test an application for different operating system and for each as for
different versions like kitkat windows ios, and for each brand of mobile (Samsung,
redmi, nokia) for different models.
1. Look and feel change (whats app color green and white to blue and
black)
2. Object overlapping (conform and cancel button sitting on one another)
3. Certain images will not displayed in certain browsers
4. Scroll bar issues
5. Alignment problems
6. Scattered content
7. Certain buttons, links and components may work in one browser and
may not work in another browsers
FUNCTIONAL TESTING
Testing the each and every component individually with respect to requirement
thoroughly is called functional testing.
INTEGRATION TESTING:
Testing the data flow between two or more dependent modules is called
integration testing.
hr@kasperanalytics.com
kasper-analytics
kasperanalytics.com
9123820085
SYSTEM TESTING:
Testing the application end to end like a real user is called system testing.
Defect seeding:
Injecting the defect in the application by developer to check the efficiency of test
engineer is called defect seeding.
Defect masking:
Defect leakage:
The defect which is not found by the testing team but it is found by the customer
or end users it is called defect leakage.
Manager arranges a meeting with all the development team and testing team
discuss about the existing defects which are not fixed because the defect age
should not be increased and defect status should be moved for further level until
the defect status is closed. The meeting is known as defect triage meeting. it is the
main part of agile meeting.
Defect density:
Number of defects means the defect which are considered as valid defect not all
the reported defect.
hr@kasperanalytics.com
kasper-analytics
kasperanalytics.com
9123820085
ISTQB
STATIC TESTING:
Review:
Finding the mistakes in the document is called review. In review we have types
hr@kasperanalytics.com
kasper-analytics
kasperanalytics.com
9123820085
Walk through:
Explaining about the document to the set of people who are not aware of that.
Inception:
It is the kind of auditing process which is done on the documents for a software
company. IOS: international organization standardization.
It is for hardware.
It has five levels CMMI 1, CMMI 2, CMMI 3, CMMI 4, CMMI 5. Highest level is CMMI5
DYNAMIC TESTING:
Equivalence partitioning:
Error guessing:
It is the technique where we come with all the possible errors is known as error
guessing Without requirement we cannot do requirement.
hr@kasperanalytics.com
kasper-analytics
kasperanalytics.com
9123820085
Decision table:
It is the table which helps us to decide how many numbers of test cases are
needed for a given set of requirements.
Use cases:
Use case testing is the functional black box testing technique that helps us testers
to identify the scenarios that excises whole system on each transition basis from
start to finish.
Actors represent user and interaction is that each user take part into. Test cases
based on use cases and are referred as scenarios.
Capability to identify the gaps in the system which would not find by testing
individual components is isolation.
Path testing: testing all the independent paths in a program is called path testing.
100% statement coverage is not equal to 100% branch coverage is not equal to
path coverage.
100% path coverage is equal to 100% branch coverage + 100% statement coverage
Cyclometric complexity
hr@kasperanalytics.com
kasper-analytics
kasperanalytics.com
9123820085
It is a technique which is mainly used to reduce the complexity in the source code.
If the source code is complex then testing also become complex.
Formula1: (e-n) +2
Testing all the conditional statements like if, else, switch to, is called conditional
testing.
Loop testing:
Testing all the looping statement like for, while, do while is called looping testing.
RETESTING
REGRESSION TESTING
To make sure that existing features are still working properly after the changes is
done in the application or whenever a defect is fixed for an application.
Test engineer will write test case manually the test cases which has been
executed again and again will be categorized and a separate document will be
maintained as regression test cases
hr@kasperanalytics.com
kasper-analytics
kasperanalytics.com
9123820085
Whenever we have to do regression testing, we will start testing by using the test
cases.
Since the regression testing is repetitive in nature better, we will always go for
automation testing.
Full execution:
Batch execution:
Whenever a new feature is added for executing a module and the impact is only
for that particular module, we can also call it as unit.
When we do regression testing for that unit, we do not do regression testing for
any other unit that is called unit regression testing.
Whenever there is a change in the one module and that module is having
dependency with other few modules not all the modules, then we do regression
testing for all the dependence modules we call them as regional regression
testing.
Whenever there is any change in the application and because of that change if
we have an impact on the whole application then we do complete testing again
for whole application. This is called full regression testing.
hr@kasperanalytics.com
kasper-analytics
kasperanalytics.com
9123820085
INTEGRATION TESTING
Testing the data flow between two or more dependent modules is called
integration testing.
Ex in gmail if we send a mail the sent mail should be displayed in sent items
checking whether it there in sent items or not is a integration testing.
hr@kasperanalytics.com
kasper-analytics
kasperanalytics.com
9123820085
whenever parent module is there child module is added, child module is there
parent module is added by preforming the integration testing between there
modules is called integration testing.
Whenever we cannot find which is a child and which is a parent even then we find
the integration testing between them is called non incremental integration
testing.
Stubs:
Whenever there are no child module available stubs will receive the data and
acknowledges it.
Drivers:
Drivers will send or trigger data and send data to child module
Stubs and drivers are mainly used in critical projects related to space, medical,
Submarines, defense etc.
hr@kasperanalytics.com
kasper-analytics