Manual Testing Full NOTES
Manual Testing Full NOTES
Manual Testing Full NOTES
QA and QC
QA: is quality assurance.
It is a process oriented.
QC: is a quality control.
It is a product oriented.
QA QC
It does not involve executing the programs. It always involves executing the programs.
It is a preventive technique. It is a corrective technique.
DOMAIN: It is a categorization of the software application into various fields. Each software
company will work for various domains.
Finacle: it is a banking software used by the banks.
When developers are working for 1 feature. That feature is given to testing team, during that
time developers can start working for another feature.
Due to this
1. Everybody can work independently.
2. Dependency will not be there.
3. If any problems occurs it can be handled separately.
4. Disturbance will not be there for end users.
Stake holders
A person who directly (or) indirectly involved in a software application (or) project is a stake
holder.
SDLC(SOFTWARE DEVELOPMENT LIFE CYCLE)
It is a procedure to develop the software application.
It consists of different stages or phases.
CRS: customer requirement specification
BRS: business requirement specification.
SRS: system/software requirement specification.
BA: business analyst.
HR: human resource.
HLD: high level design.
LLD: low level design.
TE: test engineer.
PM: project manager
Requirement
gathering / collection
Feasibility study
Design
MANUAL TESTING
Coding/Implementati
on/Development
Testing
Installation/Deployme
nt
Maintenance
Requirement Gathering/Collection:
Usually customer or client gives a requirement in the form of CRS/BRS. And it is converted
into SRS by BA. BA is business analyst. BA acts like bridge b/w customer and company.
BA should be good in
1. Communication skills
2. Domain expert
3. Convincing skills.
4. Technical expert.
5. Analyzing skills
BA collects all the requirement from the customer and gives to Software Company.
MANUAL TESTING
Design: once everything is fine, we go for design. In design phase, we have HLD and LLD.
Usually design phase is done by architect or senior developers.
High level design: It is just like a blue print. It shows the external architecture of the
Application.
Low level design: It shows the internal architecture of the Application.
Both HLD and LLD are the documents.
Coding:Once the design is done,developers starts writing the code for application by looking
at design and requirement.
This is done in Development Server. All developers will be involved in this.
Testing:Once coding is done, developers will give application to test engineers. All test
engineers start testing the application and find defects. If any defects are found in software
application, it again goes back to the developers. They will fix it and again given back to Test
Engineers.Like this process continues, till Application meets the Requirement.
Once everything is completed, we will go for next phase called 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.
Changes can be Adding, Modifying, Deleting a feature.
V and V model
V and V means verification and validation model
Verification is a process of checking “are we building product right”
Validation is a process of checking “are we building right product”.
V and V is done only by test engineer.
Verification is QA process.
Validation is a QC process.
When do we go for V and V model?
1. When the customer needs high quality products
2. For complex applications
Ex: Banking, health care applications, space applications, airlines applications,
navy applications.
3. For Long term projects. (more than one year).
verification validation
Software is
ready for
testing
SRS will be reviewed against the CRS to find the defects. Parallelly they prepare the test
plan and test cases.
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, 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.
Prototype model
Prototype is a dummy model that is a non-working application.
When we go for prototype model?
1. When the customer is not clear about requirement.
2. When the software company is new to the domain, then they will go for prototype
model.
3. When the developers are new to the technologies.It is a experimentation.
4. When the customer and software company are new to the business.
Advantages of prototype model
1. Initially customer can get to know what he gets on.
2. Initially itself developers will also come to know what they should deliver on last day.
3. Requirement changes can be done initially itself.
4. Initially investment is very less.
Drawbacks of prototype model
1. There will be a delay in the actual start of the real project.
2. Investment is done on non-working product.
3. Too many changes can disturb the rhythm of the company.
AGILE
MANUAL TESTING
MANUAL TESTING
SOFTWARE TESTING
• Testing the functionality of an application with respect to given REQ.
• Checking the application with the intent of finding the defect.
• Checking the behavior of an application to see whether it meets customer REQ or not.
• Testing the process of QA and QC.
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
Televisionremote: if we operate by using the remote it is a automation testing
if we do without remote it is manual testing.
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.
To identify the defects we should find the scenarios first.
Scenario is not a defect or defect is not a scenario.
+ve scenarios and -ve scenarios are not a defect.
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.
DRAWBACKS OF MANUAL TESTING.
1. It is a time-consuming process.
2. It is a repetitive in nature (Because of REGRESSION TESTING)
3. Turn around time is more in manual testing, so we go for automation testing.
4. Need more Man Power.
3. Winrunner.
4. Silk test.
5. Test partner.
5. Neo load
Load runner is a licensed tool. It is with HP.
In Bugzilla, we cannot add the requirement, write test cases and execute test cases.
We can only report the defect and track the defect.
MANUAL TESTING
TYPES OF TESTING
White box Testing : Testing the source code or internal structural of an application is
called
White box testing.
It is usually done by developer.
When situation demands, even Test Engineer can do this if we know
coding.
Black box Testing:Testing the user interface(UI) or graphical user interface(GUI) of an
application is known as black box testing.
Here we don’t worry about internal structure of an application.
It is done by test engineers.
Grey box Testing:Testing the source code and user interface of an application parallely
together is called grey box testing.
It is done by a person who is aware of both testing and source code of an
Application. Means he can be a developer or test engineer. OR he can be
SDET(Software Developer Engineer in TEST).
MANUAL TESTING
+
White box testing tools / Unit testing tools
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. It cannot be used for WBT.
WBT
manually automation
1. Check each and every code(LOC) 1. Write a pgm to develop
Manually without using a tool 2. Write a pgm to test the developed pgm
Ex .check the syntax and logics etc 3. Run the test pgm in a tool
BBT
manually automation
1. Check each and every 1. Write a pgm(TEST SCRIPT)(using selenium,
Functionality without using a qtp)
Tool on ui. To use selenium core java is used
For qtpvb is used.
2.Run the test pgm in the tool.
It will tell all the possible ways we can test the It is step by step procedure to test the
application application.
Scenario doesn’t have a navigation steps. Test cases have a navigation steps.
Scenarios doesn’t say where the exact defect is Test cases will tell where the exact defect is
present. present.
Scenarios take less time to write. Test cases take more time to write.
System study
System study: It is going through the requirement given by the customer and understand how
the system works.
Write test plan: It is a document which is prepared for FUTURE testing activities.
It is done by the test lead or test manager. Because the plans will be done by experienced
people.
MANUAL TESTING
Write test cases: It is a step by step procedure to perform the testing on the application. It is
done by 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)
Prepare RTM:(requirement traceability matrix): It is a document which is prepared to check
whether every requirement has atleast one test case or not.
To prepare RTM, we need both requirement and test cases.
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
executedand it is 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 where exactly
the software is been tested. This is the most important phase of software testing life
cycle.
Defect tracking:While executing the test cases, we may come across the defects.
These defects are raised/logged/reported to the developers.
Once we raise, we should also check what is happening to that Defect.
This is called defect tracking.
It is done by using tool called Bugzilla, QC/ALM, JIRA
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.
CLOSED
Differed/postpone Duplicate Cannot Invalid/ RFE Cannot
fix reject reproduce
RETEST
NEW /OPEN ASSIGN FIXED
REOPEN
If the defect is not fixed properly
When we are executing the test cases if the expected result and actual result are not same, we
come across the defect.Then the defect is raised to the developer, the status will be
NEW/OPEN. That defect will be assigned to the concerned developer or development
lead(If we don’t know the correct developer), then the status is ASSIGNED.
Then developer will reproduce the defect and if it is Reproducible, it will be accepted. Then
he starts fixing the defect in the development server and it has to be installed to Testing
Server.Then he should change the status to FIXED.
The test engineer starts retesting the defect fixed in the testing server. If the defect is properly
fixed, then the status will be CLOSED. If the defect is not properly fixed, then again, the
defect is REOPEN to the developer.
MANUAL TESTING
This whole process is called DEFECT LIFE CYCLE / BUG LIFE CYCLE / STATUS
OF DEFECTS.
What is deferred/postpone?
Whenever test engineer raises the defect, the developer accepts the defect but he will not fix
the defect immediately. He will fix it later, then the status of those defects will be done as
deferred/postpone.
Ex : Whenever there is a major defect and 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
make status as deferred or postpone.
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 valid defect, but he can’t fix the defect.
Ex : Whenever Technology does not Support to fix that defect, then developer will change
the status to “can’t be fixed”
What is Invalid/Rejectstatus:
Whenever the test engineer raises the defects but developer will not accept the defect as
VALID and he changes the status to INVALID / REJECT.
Severity will tell how much that defect is affecting the customer business.
Types of severity
1. Blocker / Showstopper
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.
Different types of priority
1. High
2. Medium
3. Low
OR
1. Urgent
2. High
3. Medium
4. Low
MANUAL TESTING
OR
1. P1
2. P2
3. P3
Author
Reviewer
Approved by
Approved date
Header part
Test data: it is the data we need to execute the scenarios.
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
Test case description: summery of test cases.
DEFECT REPORT
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
Template for defect report
Defect ID This will be auto generated if we use the tools
MANUAL TESTING
Expected result
Actual result
Attachment of screen shot
ACCEPTANCE TESTING:
MANUAL TESTING
It is a testing which is mainly done to check the business scenarios of the application which is
done by the customer.
(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.
Why acceptance testing is done?
1. This is mainly done to get a confidence for customer before he releases the product to the
end users.
2. Because of business pressures, software company might be releasing the Application to
the customer with some defects. To ensure this is not there, customer will do acceptance
testing.
3. 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.
4. 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 negative to test
engineers.
So before giving application to customer, we should think all those business scenarios and
finds defects.
Alpha testing involves both black box and Beta testing typically uses black box testing
white box testing techniques Techniques
Alpha testing requires lab environment or Beta testing doesn’t require lab environment
testing environment or testing environment because software is
available for end users and is said to be real
time environment
Long execution cycle may require for alpha Only few weeks execution are required for
testing beta testing
Critical issues or fix are addressed by Most of the issues or feedback are collected
developers immediately in alpha testing from beta testing will be implemented in
future version of the product
Virtual environment Real time environment
Done at Offshore Done at Onsite
Alpha testing is done under controlled Beta testing is done under uncontrolled
environment environment
When the software company releases the product to customer/end user, if the end
user/customer finds any defects in the software, customer will raise an incident to 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.
The commitment between software company and customer is called service level agreement.
(SLA)
Ex:
PRIORITY of Ticket Time given to fix
P1 – 3hrs
P2 – 10 hrs
P3 – 1 day
P4 – 3 days
P5 – 10 days
Production
issues
BA TE DEV
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 issue.
MANUAL TESTING
REAL TIME PROJECT (OR) HOW ARE THE SERVERS USED (OR) BUILD
PROCESS
Usually we have 3 servers like development server, testing/ QA server, production server.
Customer gives the requirement then the developer start writing the source code for
developing the application in the local system, this source code will be saved in the
repository(Ex: github,vct, cvt). There white box testing will be done by developers. The
source code will be compiled and compressed, then we will be getting a file called BUILD.
All this will be happened in development server.
The build has to be installed from development server to testing server. It will be done by the
installation team or testing team or development team, depending upon project to project.
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).
MANUAL TESTING
Once everything is fine application is released to end users that is for production server. This
is called production release OR Go-LIVE.
What is release?
Starting from gathering the requirement, developing the application, testing the application,
finally releasing it to the end users is called release.
That is called production release or GO-LIVE.
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 files can be made in single file.
3. Size of the file will be reduced.
Archive format
1. .Jar(java archive), .war (web archive), .tar (tape archive) , .gz(Gun Zip)
2. Multiple files are made in a single file.
3. Size of the file will be almost same.
What does build contain?
A build contains
1. New features
2. Old features
3. Defect fixes
It depends upon the contents which developer will add inside a build, and it varies from build
to build.
What is test cycle?
MANUAL TESTING
It is effort or time spent to test the application once the build is given. The duration of each
test cycle can be days or weeks or months, depending upon the build and application size.
application
TEST STRATEGY
Test strategy is the approach to test the software application.
Based on the situation, one approach should be selected.
TEST PLAN
Based on that selected approach, we plan how to take it forward.
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.
What is a 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
mistakeshave 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.
6. Mad
When we are not able to get the defect through our regular testing like FT, IT, ST we can
think about adhoc testing so that we can get more defects.
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 or based on situation.
When we are not getting much defects with functional, integration and system testing think
about adhoc testing we will definitely get defects.
All the defects we found through adhoc testing need not to be fixed by the developer unless
it is crashing the applications.
MANUAL TESTING
Stress testing:
Testing the response time of an application by applying the load which is greater than
designed no of users, that can be around 10-20% greater than the load.
Ex : Req-100000 users ------ response time should be within 2sec.
Stress testing 1,10,000 users --------- response time 2sec
Volume testing
Testing the response time of an application by transferring huge volume of data through
application.
Ex : Huge data sharing through share it, Bluetooth, google drive by uploading more photos
and checking the time taken to transfer that data.
Soak testing
Testing the response time of an application by applying load continuously for some
duration of time.
Ex :72 hrs more users are using application continuously and we will check the response time
for 72 hrs
MANUAL TESTING
RELIABILITY TESTING
Testing the functionality of an application continuously for some duration of time. This can
be done by single users. It is to check the consistency of an application.
Ex: Mobile should function properly with one user for long time.
Standalone applications:
This kind of applications can be installed, accessed and used without any dependency on
server or internet.
Ex notepad, calculator, word, calendar.
This is the fastest applications with respect to response time.
Client server applications:
In this case we have software in two categories.
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.
Ex whatsapp, facebook, gmail, redbus app.
Web application:
In this we access the application through the browser. Here static and dynamic element will
load together.
Ex: we can access gmail or fb any other application by entering the url into the browser.
We need internet connection compulsory.
Here the browser will act as client.
COMPATIBILITY TESTING
Testing the application with different hardware and software platforms is called compatibility
testing.
Why do we do compatibility testing?
1.To ensure that application is working for multiple platforms because there might be
different types of users.
2.To check whether the application is working in all platforms or not.
MANUAL TESTING
Android (mobile)
Alpha, beta, cupcake, donut, éclairs,foreo, gingerbread, honey comb, icecream
sandwich, jellybean, kitkat, lollypop, mar……, noughet, oreo, pie,
IOS(mobile)
GLOBALIZATION TESTING
Testing the application with respect to the local culture or local standard to that country or
state or region is localization testing.
Rs $
Dd/mm/yyyy mm/dd/yyyy
Pin code zip code
(560097) (CA 12345) , (SJ 25634)
USABILITY TESTING
GPS
VPS
Touch screen
Keypad
OLA
Pick up , drop , type of cab, confirm
Your name, mother name , father name, age, aadhar card etc
UBER
Pick up , drop , type of cab, confirm
M1 marks, 1st sem , btech – pass , yofp, backlogs?
Mobile
Long press, PIN, password, pattern, finger print, facelock, iris, voice,
MANUAL TESTING
Testing whether the application is suitable for physically challenged people or not.
Ex : RGB (red green blue) colour should not be used in the application.
Every feature or component in an application should be accessed by mouse and also by
keyboard.
RECOVERY TESTING
Testing the application whether it is able to recover from crash state or not.
AESTHETIC TESTING:
MANUAL TESTING
USABILITY TESTING
Testing the application, whether it is user friendly or not
Who should do usability testing?
1. End users is the best
2. Customer or client 2nd best.
3. Others project team members.
4. Nobody is there, test engineer has to do usability testing.
Test strategy:
Strategy is an approach to do any type of task.
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:
MANUAL TESTING
1. Objective: this section tells about the purpose of preparing the test plan.
2. Scope: This will say the limitations.
This section will tell about
a) Features what to be tested. (Ex: GMAIL)
b) Features what not to be tested. (Ex: FB,INSTAGRAM)
3. Schedule and milestone:
This section will tell which activity has to done first and which activity has to done
next.
It is just like a time table of the project.
Ex:
REQ - wtc – Etc - AT(milestone) – PR(milestone)
4. Entry and exit criteria : This section tells about when to enter and when to exit each
type of testing.
5. Defect tracking: This section will tell about whenever a defect is found how to track
the defect and which is the tool, we are using to track the defect. And what are the
terminologies we are using to raise the defect.
MANUAL TESTING
7. Risk: This section will tell about what are the possible risk
happen during the project.
Ex : All employees are not in office. Leave/Quit
This section will contain what are the roles and responsibilities for team members.
10. Environment: This section contains which platform we are using for testing purpose
ex. Window 10,8,7 chrome browser,
MANUAL TESTING
11. Deliverables: This section will tell what are the documents that should be prepared
for the project. EX: Test plan, Test cases, RTM, Defect reports etc.
12.
Graphs and metrices: This section contains the graphs and metrices that are
prepared for project.
INTEGRATION TESTING:
Testing the data flow between two or more dependent modules is called integration testing.
SYSTEM TESTING:
Testing the application end to end just like a real user is called system testing.
It is a done on a Testing Server, which is similar to Production server.
BEFORE MARRIAGE
9 am - 9 pm - 10 defects
MARRIED
AFTER MARRIAGE
10 am – 5 pm - No defects Build
Defect seeding:
MANUAL TESTING
Injecting the defect in the application by developer to check the efficiency of test engineer is
called defect seeding.
This is done based on the request of manager.
Build 01
Login-A - Defect raised (MASKING defect)
Compose-B - MASKED DEFECT
Build 02
Login – A -Retesting
Compose-B – Defect
Defect masking:
Whenever one defect is hiding another defect that is 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.
MANUAL TESTING
Defect Density:
Defect density = Number of defects / Total size of the project (LOC/Duration)
Ex :
DD = 100 / 2000 (loc)
DD = 100 / 6 months (duration)
MANUAL TESTING
Number of defects means the defect which are considered as valid defect not all the reported
defect.
SIT :
(System Integration Testing)
Testing the data flow between 2 or more systems
FB
Sit
GMAIL
MANUAL TESTING
ISTQB
International software testing qualifications board
It is a certification for software testing engineers.
ISTQB
Review
Walk through
inspection
STATIC TESTING:
Testing which is performed on the document is called static testing.
MANUAL TESTING
Walk through:
Explaining about the document to the set of people who are not aware of that.
Inspection:
It is the kind of auditing process which is done on the documents for a software company.
DYNAMIC TESTING:
Testing which is done on the application is called dynamic testing, that is on source code or
user interface of an application
Here in this testing, execution takes place.
Equivalence partitioning:
It is the technique where we come up with given range of requirement. Here it contains one
valid and two invalid data.
Error guessing:
It is the technique where we come with all the possible error message for different scenarios .
It is error guessing
Here we have more of Negative scenarios.
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.
MANUAL TESTING
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.
RETESTING
Testing the defect fixed or bug fixed of an application is called retesting.
REGRESSION TESTING
Testing the impact areas of an application after
1. After the defect fixed.
2. After changes done in application.
Changes can be adding modifying and deleting a feature.
Why we do 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.
When do we do regression testing?
1. After the defect fixed.
2. After changes done in application.
Changes can be adding modifying and deleting a feature.
MANUAL TESTING
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.
Types of integration testing
Integration testing
P C2
C1 C1
C2 P
Incremental integration testing:
Whenever parent module is there, child module is added and we do integration testing.
OR
Whenever child module is there, parent module is added and we do integration testing
between these modules.
MANUAL TESTING
STUBS
DRIVERS
STUB
Acts like a child module when CHILD MODULE IS NOT PRESENT
DRIVER
acts like a PARENT module when PARENT MODULE IS NOT PRESENT
Acceptance Testing
whole
hole
A - 1 year PARENT
MANUAL TESTING
B – 1 year CHILD
A – 1 year – DRIVER – PARENT
Stubs:
It is a dummy module which acts like a child module.
Whenever there is no child module available, stubs will receive the data and acknowledges
the data.
Drivers:
It is a dummy module which acts like a parent module.
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,
defence etc.