0% found this document useful (0 votes)
35 views51 pages

Manual Testing Overall - Notes

Data enquire

Uploaded by

Amit Aarya
Copyright
© © All Rights Reserved
Available Formats
Download as PDF, TXT or read online on Scribd
Download as pdf or txt
0% found this document useful (0 votes)
35 views51 pages

Manual Testing Overall - Notes

Data enquire

Uploaded by

Amit Aarya
Copyright
© © All Rights Reserved
Available Formats
Download as PDF, TXT or read online on Scribd
Download as pdf or txt
Download as pdf or txt
You are on page 1/ 51

kasperanalytics.

com

9123820085

Manual Testing
Overall Notes

hr@kasperanalytics.com

kasper-analytics
kasperanalytics.com

9123820085

Terminologies used in software industry

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

QA: is quality assurance.

It is a process oriented

QC: is a quality control.

It is a product oriented.

QA QC

It is a procedure that focus on It is a procedure that focus on fulfilling


providing assurance that quality thequality requested.
requested will be achieved.

QA aims to prevent the defect QC aims to identify the defect.

It is a method to manage quality It is a method to verify the quality


verification validation

It does not involve executing the It always involves executing the


programs. programs.
It is a preventive technique. It is a corrective technique.

hr@kasperanalytics.com

kasper-analytics
kasperanalytics.com

9123820085

RTM: requirement traceability matrix.

KT: knowledge transfer.

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.

Servers and environments

We have usually 3 types of servers.

1. Development server.(used by developers)


2. Testing server or QA server(used by test engineers)
3. Production server(end users)

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

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.

hr@kasperanalytics.com

kasper-analytics
kasperanalytics.com

9123820085

SDLC(SOFTWARE DEVELOPMENT LIFE CYCLE)

It is a procedure to develop the software application. It consists of different


stages.

CRS: customer requirement specification

BRS: business requirement specification.

SRS: system requirement specification.

BA: business analyst.

HR: human resource.

HLD: high level design.

LLD: low level design.

TE: test engineer.

PM: project manager

Requirement gathering: usually customer or client gives a requirement in the


form of CRS/BRS. And it is converted into SRS by BA. BA means business analysis.
BA acts bridge b/w customer and company.

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.

BA will explain about the project HR is for needed resource.

Finance will take care about budget.

hr@kasperanalytics.com

kasper-analytics
kasperanalytics.com

9123820085

Architect will for which technology we should use for project.

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.

Once everything is completed, we will go for next phase called installation.

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

TYPES OF SDLC MODLES

Water fall model

It is one of the oldest traditional models.

When we go for water fall model?

1. When the customer freezes the requirement


2. For any short-term project.
3. For developing simple application.

What are the advantages of waterfall model?

1. We can expect stable application.


2. There will be no disturbance for the team members if the requirement
does not change.

Drawbacks of waterfall model?

1. Testing happens after coding.


2. Requirement and design are not tested.
3. Developers used to do testing before. (currently it is done by test
engineers)
4. If requirement changes it leads to lot of work.

Why developers are not involved in testing?

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

This is also one of the traditional model.

When do we go for spiral model?

1. When the customer gives requirement part by part.


2. When there is a lot of dependency b/w the models.

What are the advantages of spiral model?

1. Customer can see the application partially and can get confidence.
2. Requirement changes can be done.

What are the drawbacks of the spiral model?

1. Requirement and design are not tested.


2. Testing happens only after coding.
3. Developers used to do testing.
4. If there is any requirement changes it may delay the projects.

Requirement changes are of two types.

1. Major: whenever there is a major changes we work only on that


changes. we cannot work on the new requirement.

hr@kasperanalytics.com

kasper-analytics
kasperanalytics.com

9123820085

2. Minor: whenever there is a minor change we can work on that changes


and we can work on the new requirement.

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 compiler applicationsEx banking, health care applications, space
applications, airlines applications, navy applications.
3. For Long term projects. (more than one year).

hr@kasperanalytics.com

kasper-analytics
kasperanalytics.com

9123820085

advantages of V model

1. Testing is started at initial stage.


2. Requirement and design are tested
3. The downward flow of defects are less.
4. Requirements changes can done.
5. Quality will be high compared to other products.
6. Rework will be less.

Drawbacks of V model

1. Documentation work will be more.


2. Too much of resource are needed.

Explain about V and 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

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
model.
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 do on initially itself.
4. Initially investment is very less.

Drawbacks of protypes model

1. There will be a delay in the actual short of the real project.


2. Investment is done on non-working product.
3. Too many changes can disturb the rhythm of the company.

hr@kasperanalytics.com

kasper-analytics
kasperanalytics.com

9123820085

hr@kasperanalytics.com

kasper-analytics
kasperanalytics.com

9123820085

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

1. Television remote: if we operate by using the remote it is a automation


testing if we do without remote it is manual testing.

Why testing is important?

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.

+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.

DROWBACKS OF MANUAL TESTING.

It is a time-consuming process. It is a repetitive in nature

Turn around time is more in manual testing so we go for automation testing.

RETESTING AND REGRESSION TESTING

RETESTING

Testing the defect fixed which is done on an application is called retesting.


REGRESSION TESTING

Testing the impacted 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.

TOOLS USED IN INDUSTRIES

Functional testing tools

1. Selenium(core java ,python,…)


2. QTP/UFT(quick test professional, unified functional test) supports
VBS(visual basic scripting) Selenium is a free and is a open source.
Qtp/uft is a paid and licensed tool developed by HP. Hewlett Packard
Thought works is a company that came up with the selenium tool.
3. Win runner.
4. Silk test.
5. Test partner.

hr@kasperanalytics.com

kasper-analytics
kasperanalytics.com

9123820085

The tools which are using are

1. Functional testing tools are


1. Selenium : selenium is a tool which is in demand and it is a open
source and free tool. The best combination is that selenium is used
by core java. Thought works is the first company to come with the
selenium.
2. Qtp/uft: it is powerful tool and it is a paid and licensed tool. The best
combination is that qtp is used by vbs.

performance testing tools

checking the load and response time.

1. Load runner
2. J meter.
3. Qa Load
4. Silk performer.
5. Neo load

Load runner is a licensed tool. it is with hp.

hr@kasperanalytics.com

kasper-analytics
kasperanalytics.com

9123820085

Test management tools

1. QC/ALM(quality center /application life cycle management) it is a


licensed tool. it is with hp.
2. JIRA.(best tool for agile modal)
3. OTM(oracle test management tool)
4. Test link

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.

Defect-repose defect or track defect.

What are the test management activities?

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.

Defect or Bug tracking tools

1. Bugzilla: it is a open source and free.


2. QC/ALM(quality center /application life cycle management) it is a
licensed tool. it is with hp.
3. JIRA.(partially free)

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

White box testing.

testing the source code or internal structural of an application is called White box
testing.
It is usually done by developer.

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.

Gray box testing:

testing the source code and user interface of an application parallelly Together is
called gray 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.

hr@kasperanalytics.com

kasper-analytics
kasperanalytics.com

9123820085

White box 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.

hr@kasperanalytics.com

kasper-analytics
kasperanalytics.com

9123820085

scenario Test cases

It will tell all the possible ways we can test It is step by step procedure to
theapplication test theapplication.

Scenarios says “what to do” Test cases says “hoe to test”.

Scenario is a high-level document. Test cases is a low-level document.

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.

Template is a format used to write a test cases.

Test cases

A test case is a document which contain all the possible scenarios.

When do we write test cases?

When the developers are developing the application, we will write a test case.

There are two stages

1. Test case preparation.


2. Test case execution.

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

Under test case execution we have to fill following sections like

1. Actual result.
2. Status.
3. Comments.

hr@kasperanalytics.com

kasper-analytics
kasperanalytics.com

9123820085

Software testing life cycle (STLC)

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)

Prepare RTM:(requirement tractability matrix): it is a document which is prepared


to check weather every requirement has at least one test cases.

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 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.

DEFECT LIFE CYCLE OR BUG LIFE CYCLE

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.

What is duplicate status?

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”.

Ex mobile hang .. etc.

Reasons for can’t 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.

Reasons for invalid

Due to the misunderstanding of the requirement.

1. If test engineers misunderstand requirement

New/open->assign->invalid->closed

2. If developer misunderstand the requirement

New/open->assign->invalid->reopen->fixed->closed

Request for enhancement (RFE)

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.

Different types of priority

1. High
2. Medium
3. Low

Who will set severity and priority?

Test engineer will set severity and priority.

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

TEST CASE TEMPLATE

Test case name


Project name
Module name
Requirement
number
Test data
preconditions
Test case type
priority
Test case
environment
Test case
description
Test steps
Sl.no description Input Expected Actual Status comment
result result s

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

hr@kasperanalytics.com

kasper-analytics
kasperanalytics.com

9123820085

Test case description: summery of test cases.

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


Build no It is the number of build where defect has found
Test case no It is a number of the test case where we found this defect
Status
severity
Priority
Test
environment
Module no
Reported by
Brief description
Test data

Expected result
Actual result
Attachment of screen
shot

hr@kasperanalytics.com

kasper-analytics
kasperanalytics.com

9123820085

ACCEPTANCE TESTING

It is 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?

This is mainly done to get a confidence for customer before he releases the
product to the end users.

Because of business pressures, software company might be releasing the project


to the customer with some defects. To ensure this customer will do acceptance
testing.

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.

Approaches of acceptance testing.

BA or IT employees of customer will do acceptance testing at customer place.

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

Alpha testing Beta testing


Alpha testing is performed by tester who Beta testing is performed by the client
areusually an internal employee of an orend users who are not an employee
organization. of anorganization
Alpha testing is performed by the Beta testing is performed at the
developersite clientlocation or end user of
product
Reliability and security testing are not Reliability and security and robustness are
performed in depth alpha testing checked during beta testing
Alpha testing involved both black box and Beta testing typically uses black box testing
white box testing techniques Techniques
Alpha testing requires lab environment Beta testing doesn’t require lab
ortesting environment environmentor testing environment
because software is
available for end users and is said to be
realtime environment

Approach no 2: employees or test engineer of customer will do acceptance


testing at customer place.

Approach no 3: test engineers of software company will do acceptance testing at


customer place.

Approach no 4: test engineer or BA of software company will do acceptance


testing under the control of customer at developer place.

Hot fix / incident management system

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

The commitment between software company and customer is called service


level agreement.

Fish bone diagram

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.

SHORT TERM RELEASE/INTERIM RELEASE

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.

REAL TIME PROJECT (OR) HOW ARE THE SERVERS USED

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(github,vlt.cvt), there white box testing will be done
by developer. The source code will be compiled and compressed, then we will be
getting a file called build. All this will be happened in developer server.

The build has to be installed from development server to testing server. It will be
done by the installation team or testing team.

Depending upon project to project

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.

That is called production 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

1. Jar (java archive), war (web archive), tar (tape archive).


2. Multiple files are made in a single file.
3. Size of the file will be almost same.

hr@kasperanalytics.com

kasper-analytics
kasperanalytics.com

9123820085

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 an build, and it
varies from build to build.

What is test cycle?

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

Retesting and regression testing with respect to build

Application will be having multiple release.

Release can have multiple builds.

The final stable build will be released to production server.

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 strategy is the approach to test the software application

Test plan

based on that approach we decide one approach and we plan based on that

how do you a define a format of good test case?

A good test case should have the header, body and footer sections. It should
contain the attributes which are easily understandable.

Ex in body section it should contain

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.

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 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

Difference b/w functional and non-functional testing?

Functional testing Non-functional testing


Functional Performance testing
testing Compatibility
Integration testingGlobalization
testing System testingSecurity
testing testing Accessibility
testing
Usability testing
Checking for single users Checking for multiple users
1. Multiple platforms
2. Multiple languages

What is negative testing?

Testing the invalid or unexpected data then it is called negative testing.

How do you ensure that the testing having the good coverage?

We prepare RTM document.

Apply test case technique.

SMOKE TESTING (OR) BUILD VERIFICATION TESTING (OR) CONFIDENECE TESTING

it is testing the basic feature of an application before we do through testing like


functional, integration, system testing.

Why we do smoke testing?

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

When we do smoke testing?

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.

Difference b/w formal and informal smoke testing?

Formal smoke testing Informal smoke testing


It is a document type It is not a document type
We have a proof There is a proof
It has a procedure There is no proper procedure

Difference b/w smoke testing and sanity testing

Smoke testing Sanity testing

It is testing the basic features only It is testing the new features and bug fixes

It is shallow and wide testing It is narrow and deep testing

It is done on the unstable builds It is done on the stable builds

Only positive testing is done Both positive testing and negative testing
aredone

It is the subset of regression testing.

ADHOC TESTING (OR) MONKEY TESTING (OR) GORILLA TESTING

Testing the application randomly without following any formal documents like
requirement, test cases etc.

Why we do adhoc testing?

An application can be used different set of people or end users like

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.

PERFORMANCE TESTING OR SCALABILITY TESTING

Testing the response time of an application by applying load for an application is


known as performance testing.

Load: number of users who uses the application.

Response time: time taken to get the expected screen based on the user actions.

Types of performance testing

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.

Req-100000 users response time 2sec

Stress testing 110000 users response time 2sec

hr@kasperanalytics.com

kasper-analytics
kasperanalytics.com

9123820085

Can we do performance testing manually?

Yes, we can do performance testing manually but there are some drawbacks likes

1. Too much cost will be involved because of multiple human resource


and multiple devices, a huge place for gathering everybody.
2. There will be no accuracy in the results, we human beings we do not
perform all the actions at same time because of this result may vary.

So we go for automation

Volume testing

Testing the response time of an application by applying transferring huge volume


of data through application.

Ex data sharing through share it, Bluetooth, google drive by uploading more
photos.

Sock testing

Testing the response time of an application by applying load continuously for


some duration of time

Ex 72 hrs users are using application continuously to check the response time

RELIABILITY TESTING

Testing the functionality of an application continuously for some duration of time.


This can be done by single users

Ex: mobile should work properly with one user.

Standalone applications: it does not depend on the server. It is installed


separately Ex calculator, calendar, word.

Client server application: using an application by server by using internet


connection.

Web applications: fully depends on internet connection. Ex. Chrome---gmail---


facebook

hr@kasperanalytics.com

kasper-analytics
kasperanalytics.com

9123820085

TYPES OF APPLICATIONS

Generally, we have three types of application

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.

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.

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.

Here the browser will act as client.

COMPATIBILITY TESTING

Testing the applications with different hardware and software platforms is called
compatibility testing.

Why do we do compatibility testing?

To ensure that application is working for multiple platforms because there might
be different types of users.

To check weather the application is working in all platforms.

GLOBALIZATION TESTING

Testing an application to which is developed for multiple languages is


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

1. Machine does not have feeling


2. It cannot understand meaning.
3. It cannot understand grammar.
4. It cannot understand spelling.

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.

Types of 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.

Every feature or component in an application should be accessed by mouse and


also by keyboard.

RGB color blind will not be able to view that.

Music and keyword: anybody is injured wrist they can still use the application
using the keyboard.

Tools used for accessibility testing

1. In focus
2. Wave

RECOVERY TESTING

Testing the application weather, it is able to recover from crash state.

AESTHETIC TESTING:

Testing the beauty of an application is called aesthetic testing.

USABILITY TESTING

Testing the application, it is user friendly or not

hr@kasperanalytics.com

kasper-analytics
kasperanalytics.com

9123820085

Why should we 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

1. Objective: this section tells about the purpose of preparing the test plan.
2. Scope: limitations

This section will tell about

Future what to be tested.

Future what not to be tested.

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.
4. Entry and exit: 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.
6. Assumptions: this section will tell about what are the assumptions we
have during this project.

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.

Roles and responsibilities of test engineer

This section will contain what are the roles and responsibilities for team members.
Ex roles and responsibilities for test engineers.

Going through the requirement and understanding the requirement and


identifying the scenarios and writing the test cases, prepare RTM, and execute test
cases when the build is given, find the defect and raise the defects.

For automation test engineer:

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.

RTM (REQUIREMENT TRACEABILITY MATRIX)

It is a document which is prepared to test that every requirement having at least


one test case or not.

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

backward traceability matrix.

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.

Mobile compatibility testing:

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.

What kind of bugs we find computability testing?

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.

This is done based on the request of manager.

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.

For a good testing team defect leakage percentage should be 0%.

Defect triage meetings

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:

Dd=number of defects/ total size of the project

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

International software testing qualification board

It is a certification for software testing engineers.

STATIC TESTING:

testing which is performed on the document is called static testing. there is no


execution here.

types of static testing:

Review:

Finding the mistakes in the document is called review. In review we have types

1. Self-review: review done by ourselves


2. Peer to peer review: review done by others
3. Manager review: review done by managers

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.

CMMI: capability maturity model integration.

It has five levels CMMI 1, CMMI 2, CMMI 3, CMMI 4, CMMI 5. Highest level is CMMI5

SEI: software engineer institute

CMMI is the recognition given by SEI

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 and execution take place.

Black box testing techniques

Boundary value analysis:

Testing the boundaries of the certain components or element present on web


page is called boundary value analysis

Ex testing on text field which accepts only 3-10 characters.

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 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.

The formula for this is 2^n= no of test cases or scenarios.

Where n is number of conditions or components

State transition diagram:

It is a technique which is used to come up with the flow of an application in a easy


manner. This can be used in system testing and integration testing.

For atm machine this diagram helps a lot.

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.

Characteristics of use case testing

Use case can capture interaction between actor and system.

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.

Very effective in defining the scope of acceptance testing.

White box testing techniques:

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% branch coverage is not equal to 100% statement 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

Formula 2: number of predicate nodes+1 Formula3: number of regions + 1 Formula


4: number of paths Conditional testing:

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

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.

How do we do regression testing?

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.

IN AUTOMATION REGRESSION TESTING TYPES:

Full execution:

Executing all the test scripts is called full execution.

Batch execution:

Executing the partially test scripts is called batch execution.

Types of regression testing

Unit regression testing:

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.

Regional 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.

Full 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

Difference between QC and QA

Quality analysis Quality control

it is a process oriented it is a product oriented

it is a verification process It is a validation process

it is a preventive method it is a detective method

Here we check “are we developing Here we check “are we developing


productright” rightproduct”

It involves only static testing It includes dynamic 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

hr@kasperanalytics.com

kasper-analytics
kasperanalytics.com

9123820085

incremental integration testing

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.

Non incremental 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 and drivers

Or one module is ready another module is not ready

How can we do integration testing by using stubs and drivers?

Stubs:

It is a dummy module which acts like a child module

Whenever there are no child module available stubs will receive the data and
acknowledges it.

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, defense etc.

hr@kasperanalytics.com

kasper-analytics

You might also like