Most Popular Functional Testing Interview Questions and Answers

Q #1) What do you understand by the term ‘Functional testing’?

Answer: A black box testing technique, where the functionality of an application is

tested to generate the desired output by providing certain input is called ‘Functional
testing’.

The role of functional testing is not only to validate the behavior of the application as per
the requirement document specification but is also to verify whether the application is
ready to be released into the live environment or not.

Given below are few functional testing techniques that are commonly used:

 Unit testing
 Smoke testing
 Integration testing
 System Testing
 Usability testing
 Regression testing
 User Acceptance testing

Q #2) What are the important steps that are covered in Functional testing?

Answer: Following are the steps that should be covered as a part of functional
testing:

1. Understanding the Requirement document specification and clearing the

doubts and queries in the form of review comments.

2. Writing the test cases with respect to the requirement specification by

keeping in mind all the scenarios that should be considered for all the cases.

3. Identifying the test inputs and requesting the test data that is required to
execute the test cases as well as to check the functionality of the application.

4. Determine the actual outcomes as per the input values to be tested.

5. Execute the test cases that determine whether application behavior is as

expected or any defect has occurred.

6. Compare the actual result and the computed result to find out the actual
outcome.
Q #3) Explain the difference between Functional testing and Non-Functional
testing.

Answer: The difference between Functional testing and Non-functional testing can be
found in the table given below:

Functional Testing NonFunctional Testing

Functional testing is performed to Non-functional testing is the process to
determine the system behavior as per determine the system performance as per
the client functional requirements. client expectations
Functional testing is performed first with Non-functional testing is performed after
the help of Manual and Automation testing functional testing with the effective tools
tools. required.
It is difficult to perform manual testing as
It is easy to perform manual testing as
scalability, reliability, speed and other
client requirements are the input in
performance parameters are input in non
functional testing.
functional testing.
Functional testing types:
Non-functional testing types:
• Unit Testing
• Smoke Testing • Performance testing
• Sanity Testing • Load, Stress, Volume Testing
• Integration testing • Security testing
• User Acceptance testing • Compatibility testing
• Regression testing

Q #4) How is ‘Build’ different from ‘Release’?

Answer:

Build is an executable file which refers to that part of an application which is

handed over to a tester to test the implemented functionality of the application
along with some bug fixes.

The build can be rejected by the testing team if it does not pass the critical
checklist which contains the major functionality of the application.

There can be multiple builds in the testing cycle of an application.

Release refers to the software application which is no longer in the testing phase and
after completion of testing and development, the application is handed over to
the client.

One release has several builds associated with it.

Q #5) Explain Bug cycle.

Answer:

Bug is said to be an unwanted error, mistake, etc that has occurred within the
application and prevents it from delivering the desired output.

When any defect or bug is encountered in an application while testing, then from
logging a defect till its resolution, a bug moves through a definite life cycle known as
Bug Lifecycle.
Below figure will give you an idea of Bug lifecycle:
image source: Bugzilla bug life cycle

1. The whole process goes as and when an issue or bug is encountered. It is

reported /logged in bug tracking tool following a considerable format.

2. These bugs are assigned to the developer and its status is made as ‘Open’.

3. Developer can now review the bug, reproduce it at its end and start working on it.

4. If the bug is fixed, the developer changes its status to ‘Fixed’ or the status can
be moved to ‘need more information’, ‘won’t fix’, ‘cannot reproduce’ etc., in other
cases.
5. QA then performs regression i.e. re-verify the bugs with a specific action and
responds accordingly.
If the issues/bug is now behaving as expected then its status is changed to Verified
/Closed else Reopen.

Q #6) Enlist some Bug status along with its description.

Answer: Enlisted below are few bug statuses along with their descriptions:

 New: When the defect or bug is logged for the first time it is said as New.

 Assigned: After the tester has logged a bug, his bug is being reviewed by the
tester lead and then it is assigned to the corresponding developer team.

 Open: Tester logs a bug in the Open state and it remains in the open state until
the developer has performed some task on that bug.

 Resolved/Fixed: When a developer has resolved the bug, i.e. now the
application is producing the desired output for a particular issue, then the
developer changes its status to resolved/fixed.

 Verified/Closed: When a developer has changed the status to resolved/fixed

then the tester now tests the issue at its end and if it’s fixed then he changes the
status of the bug to ‘Verified/Close’.

 Reopen: If a tester is able to reproduce the bug again i.e. the bug still exists
even after fixing by the developer, it’s status is marked as reopen.

 Not a bug/Invalid: A bug can be marked as invalid or not a bug by the developer
when the reported issue is as per the functionality but is logged due to
misinterpretation.

 Deferred: Usually when the bug is of minimal priority for the release and if there
is lack of time, in that case, those minimal priority bugs are deferred to the next
release.

 Cannot Reproduce: If the developer is unable to reproduce the bug at its end by
following the steps as mentioned in the issue.
Q #7) What is known as Data-driven testing?

Answer: Data-driven testing is the methodology where a series of test script containing
test cases are executed repeatedly using data sources like Excel spreadsheet, XML file,
CSV file, SQL database for input values and the actual output is compared to the
expected one in the verification process.

For Example: Test studio is used for data-driven testing.

Some advantages of data-driven testing are:

 Reusability.
 Repeatability.
 Test data separation from test logic.
 The number of test cases is reduced.


Q #8) What are the important points that should be considered while writing Test
Cases?

Answer: Writing a test case is said to be the most important activity of the test
execution process which requires writing skills as well as in-depth knowledge of the
application to make effective and reusable test cases.

Few important points that should be considered while writing test cases includes:

 There should be a clear understanding of the client’s requirements before

beginning to write the test cases. Nothing should be assumed and every doubt
regarding the requirements should be cleared.

 Every requirement should be included in the form of test cases and nothing
should be left out. Usually Traceability matrix is maintained to keep a check on
every requirement implementation and testing completion.

 As per the requirement document specifications, every functional and non-

functional requirement including UI interface, compatibility should be covered.

 Test cases should be checked from time to time for no repetition or redundancy.

 Priority is an important factor which should be set for the test cases while writing.

 This priority helps tester to test the application first with the high priority tests
cases which includes basic functionality, then the medium and later the low
priority test cases.
  For a particular release, test cases can also be built Sprint wise so that the
tester, as well as the developer, can analyze the quality of the product based on
test case execution.

 Structure of test cases should be easily understood and must be in a simple

language. The input data values for test cases should be valid as well as in a
wide range.

Q #9) What is Automation testing?

Answer:

Automation testing is a testing methodology where automation tool is used to

execute the test cases suite in order to increase test coverage as well speed to test
execution.

Automation testing does not require any human intervention as it executes pre-
scripted tests and is capable of reporting and comparing outcomes with previous
test runs.

Repeatability, ease of use, accuracy, and greater consistency are some of the
advantages of Automation testing.

Some automation testing tools are listed below:

1. Selenium
2. Tellurium
3. Watir
4. SoapUI
Q #10) Explain the term Stress Testing and Load testing.

Answer:

Stress Testing is a form of performance testing where the application is bound to go

through exertion or stress i.e. execution of application above the threshold of the
break to determine the point where the application crashes.

This condition usually arises when there are TOO MANY USERS & DATA.

Stress testing also verifies the application recovery when the work load is reduced.

The goal of stress testing is to ANALYZE THE BEHAVIOR OF THE SYSTEM AFTER
A FAILURE.

For stress testing to be SUCCESSFUL,  a system should display an appropriate

error message while it is under extreme conditions.

Consider the following scenarios -

 During festival time, an online shopping site may witness a spike in traffic,
or when it announces a sale.

It is imperative to perform Stress Testing to accommodate such abnormal traffic spikes.

Failure to accommodate this sudden traffic may result in loss of revenue and repute.

Stress testing is also extremely valuable for the following reasons:

 To check whether the system works under abnormal conditions.

 Displaying appropriate error message when the system is under stress.

 It is better to be prepared for extreme conditions by executing Stress Testing.

Application Stress Testing:

This testing concentrate on finding defects related to data locking and blocking, network
issues and performance bottlenecks in an application.

Systemic Stress Testing:

This is integrated stress testing which can be tested across multiple systems running on
the same server. It is used to find defects where one application data blocks another
application.

Exploratory Stress Testing:

This is one of the types of stress testing which is used to test the system with unusual
parameters or conditions that are unlikely to occur in a real scenario. It is used to find
defects in unexpected scenarios like

1. A large number of users logged at the same time

2. If a virus scanner started in all machines simultaneously
3. If Database has gone offline when it is accessed from a website,

Tools recommended for Stress Testing:

LoadRunner

LoadRunner from HP is a widely-used Load Testing tool. Load Test Results shaped by
Loadrunner are considered as a benchmark.

Jmeter
Jmeter is an Open Source testing tool. It is a pure Java application for stress and
Performance Testing. Jmeter is intended to cover types of tests like load, functional,
stress, etc. It needs JDK 5 or higher to function.

Stress Tester

This tool provides extensive analysis of the web application performance, provides
results in graphical format, and it is extremely easy to use. No high-level scripting is
required and gives a good return on investment.
Neo load

This is a popular tool available in the market to test the web and Mobile applications.
This tool can simulate thousands of users in order to evaluate the application
performance under load and analyze the response times. It also supports Cloud-
integrated - performance, load and stress testing. It is easy to use, cost-effective and
provides good scalability.

Load testing is a kind of Performance Testing which determines a system's

performance under real-life load conditions.

This testing helps determine how the application behaves when multiple users
access it simultaneously.

This testing usually identifies –

 The maximum operating capacity of an application

 Determine whether the current infrastructure is sufficient to run the

application

 Sustainability of application with respect to peak user load

 Number of concurrent users that an application can support, and scalability

to allow more users to access it.

It is a type of non-functional testing. In Software Engineering, Load testing is commonly

used for the Client/Server, Web-based applications - both Intranet and Internet.

Need of Load Testing:

Consider the following examples

 Popular toy store Toysrus.com, could not handle the increased traffic generated
by their advertising campaign resulting in loss of both marketing dollars, and
potential toy sales.
 An Airline website was not able to handle 10000+ users during a festival offer.
 Encyclopedia Britannica declared free access to their online database as a
promotional offer. They were not able to keep up with the onslaught of traffic for
weeks.
Goals of Load Testing:

Load testing will determine whether the system needs to be fine-tuned or

modification of hardware and software is required to improve performance.

How to do Load Testing

The load testing process can be briefly described as below -

1. Create a dedicated Test Environment for load testing
2. Determine the following
3. Load Test Scenarios
4. Determine load testing transactions for an application
o Prepare Data for each transaction
o Number of Users accessing the system need to be predicted
o Determine connection speeds. Some users may be connected via leased
lines while others may use dial-up
o Determine different browsers and operating systems used by the users
o A configuration of all the servers like web, application and DB Servers
5. Test Scenario execution and monitoring. Collecting various metrics
6. Analyze the results. Make recommendations
7. Fine-tune the System
8. Re-test

Summary:

 Load testing is defined as a type of software testing that determines a system's

performance under real-life load conditions.

 Load testing typically improves performance bottlenecks, scalability and

stability of the application before it is available for production.

 This testing helps to identify the maximum operating capacity of applications as

well as system bottlenecks.

 Loading testing is important because if ignored, it causes financial losses.

Q #11) What do you understand by Volume testing?

Answer: Volume testing is a form of performance testing which determines the

performance levels of the server throughput and response time when concurrent
users, as well as large data load from the database, are put onto the
system/application under tests.

Volume testing is defined as a type of Software Testing, where the software is subjected
to a huge volume of data. It is also referred to as flood testing.

Volume testing is done TO ANALYZE THE SYSTEM PERFORMANCE BY

INCREASING THE VOLUME OF DATA IN THE DATABASE.

With the help of Volume testing, the impact on response time and system behavior
can be studied when exposed to a high volume of data.

In VOLUME TESTING, FOLLOWING THINGS NEED TO BE TESTED

 Test to check if there is any data loss

 Check the system's response time
 Check if the data is stored correctly or not
 Verify if the data is overwritten without any notification
 Check for warning and error messages, whether it comes at all for volume
problems
 Check whether high volume data affects the speed of processing
 Does system have the necessary memory resources
 Does volume test executed on the whole system
 Is there any risk if data volume is greater than specified

Q #13) What do you understand by Exploratory Testing? When is it Performed?

Answer:

Exploratory testing means testing or exploring the application without following

any schedules or procedures.

While performing exploratory testing, testers do not follow any pattern and use their
out of box thinking and diverse ideas to see how the application performs.

Following this process covers even the smallest part of the application and helps in
finding more issues/bugs than in the normal test case testing process.
Exploratory testing is usually performed in cases when:

 There is an experienced tester in the testing team who can use their testing
experience to apply all the best possible scenarios.

 All critical paths have been covered and major test cases are prepared as per the
requirement specifications that have been executed.

 There is a critical application and no possible cases can be missed in any case.

 New tester has entered the team, exploring the application will help them
understand better as well as they will follow their own mind while executing any
scenario rather than following the path as mentioned in the requirement
document.

Q #14) For any Web Application, what are the possible login features that should
be tested?

Answer: Enlisted below are the possible scenarios that can be performed to fully
test the login feature of any application:

 Check the input fields i.e. Username and password with both valid and
invalid values.

 Try entering valid email id with an incorrect password and also enter an
invalid email and valid password. Check for the proper error message
displayed.

 Enter valid credentials and get logged in to the application.

 Close and reopen the browser to check if still logged in.

 Enter the application after logging in and then again navigate back to the login
page to check whether the user is asked again to login or not.

 Sign in from one browser and open the application from another browser to
verify whether you are logged into another browser also or not.

 Change password after logging into the application and then try to login
with that old password.

There are few other possible scenarios as well which can be tested.
Q #15) Explain Accessibility testing and its importance in the present scenario.

Answer:

Accessibility testing is a form of usability testing where testing is performed to ensure

that the application can be easily handled by people with disabilities like hearing, colour
blindness, low visibility etc. In today’s scenario, the web has acquired the major place in
our life in the form of e-commerce sites, e-learning, e-payments, etc.
Thus in order to grow better in life, everyone should be able to be a part of technology
especially people with some disabilities.

Enlisted below are few types of software which helps and assist people with
disabilities to use technology:
 Speech recognition software
 Screen reader software
 Screen magnification software
 Special keyboard

Q #16) What is Adhoc testing?

Answer:

Adhoc testing, usually known as random testing is a form of testing which does not
follow any test case or requirement of the application.

Adhoc testing is basically an unplanned activity where any part of the application is
randomly checked to find defects.
In such cases, the defects encountered are very difficult to reproduce as no planned
test cases are followed.

Adhoc testing is USUALLY PERFORMED WHEN THERE IS A LIMITED TIME TO

PERFORM ELABORATIVE TESTING.
Q #17) What is Equivalence Partitioning?

Answer:

Equivalence partitioning also known as equivalence class partitioning is a form of

black box testing where INPUT DATA IS BEING DIVIDED INTO DATA CLASSES.

This process is done in order to reduce the number of test cases, but still covering
the maximum requirement.

Equivalence partitioning technique is applied where input data values can be divided
into ranges. The range of the input values is defined in such a way that only one
condition from each range partition is to be tested assuming that all the other conditions
of the same partition will behave the same for the software.

For Example: To identify the rate of interest as per the balance in the account, we can
identify the range of balance amount in the account that earn a different rate of interest.

Q #18) Explain Boundary Value Analysis.

Answer:

Boundary value analysis method checks the boundary values of Equivalence class
partitions. Boundary value analysis is basically a testing technique which identifies the
errors at the boundaries rather than within the range values.

For Example,

An input field can allow a minimum of 8 characters and maximum 12 characters

then 8-12 is considered as the valid range and

<7 and >13 are considered as the invalid range. Accordingly, the test cases are
written for valid partition value, exact boundary value, and invalid partition value.
Q #19) Explain the difference between Severity and Priority.

Answer:

Defect Severity is defined by the level or the degree of impact by the defect on the
application under test. Higher the severity of the defect, the more is the impact on the
application.

Following are the 4 classes in which a defect severity is categorized:

 Critical
 Major
 Medium
 Low

Defect priority defines the order in which the defect should be resolved first i.e. the
higher the priority of the defect implies that the application is unusable or stuck at some
point and the defect should be resolved as soon as possible.

Following are the 3 classes in which a defect priority is defined:

 High
 Medium
 Low

What is a Software Build?

If you are developing a simple computer program which consists of only one
source code file, you merely need to compile and link this one file, to produce an
executable file.

This process is very simple.

Usually, this is not the case. A typical Software Project consists of hundreds or even
THOUSANDS OF SOURCE CODE FILES.

Creating an executable program from these source files is a complicated and time-
consuming task.
You need to use "build" software to create an executable program and the process
is called " Software Build"
Q #20) When do we perform Smoke testing?

Answer:

Smoke testing is performed on the application AFTER RECEIVING THE BUILD.

Tester usually tests for the critical path and not the functionality in deep to make sure,
whether the build is to be accepted for further testing or to be rejected in case of broken
application.

A smoke checklist usually contains the critical path of the application without which an
application is blocked.

Smoke Testing is executed "before" any detailed functional or regression tests are
executed on the software build.

The purpose is to reject a badly broken application so that the QA team does not
waste time installing and testing the software application.

The OBJECTIVE is not to perform exhaustive testing, but to VERIFY THAT THE
CRITICAL OR THE MOST IMPORTANT FUNCTIONALITIES OF THE SYSTEM ARE
WORKING FINE.

For Example, a typical smoke test would be - Verify that the application launches
successfully, Check that the GUI is responsive ... etc.

Q #21) What do you understand by Sanity testing?

Answer: Sanity testing is performed after receiving the build to check the new
functionality/defects to be fixed. In this form of testing the goal is to check the
functionality roughly as expected and determine whether the bug is fixed and also the
effect of the fixed bug on the application under test.

There is no point in accepting the build by the tester and wasting time if Sanity testing
fails.
Points to note.
 Both sanity tests and smoke tests are ways to avoid wasting time and effort by
quickly determining whether an application is too flawed to merit any rigorous
testing.
 Sanity Testing is also called tester acceptance testing.
 Smoke testing performed on a particular build is also known as a build
verification test.
 One of the best industry practice is to conduct a Daily build and smoke test in
software projects.
 Both smoke and sanity tests can be executed manually or using an automation
tool. When automated tools are used, the tests are often initiated by the same
process that generates the build itself.
 As per the needs of testing, you may have to execute both Sanity and Smoke
Tests in the software build. In such cases, you will first execute Smoke tests and
then go ahead with Sanity Testing. In industry, test cases for Sanity Testing are
commonly combined with that for smoke tests, to speed up test execution.
Hence, it's a common that the terms are often confused and used
interchangeably

What is Regression Testing?

Regression Testing is defined as a type of software testing to confirm that a recent

program or code change has not adversely affected existing features.

Regression Testing is nothing but a full or partial selection of already executed test
cases which are re-executed to ensure existing functionalities work fine.

This testing is done to make sure that new code changes should not have side
effects on the existing functionalities.

It ensures that the old code still works once the new code changes are done.

Need of Regression Testing

Regression Testing is required when there is a

 Change in requirements and code is modified according to the requirement
 New feature is added to the software
 Defect fixing
  Performance issue fix

How to do Regression Testing

Software maintenance is an activity which includes enhancements, error corrections,

optimization and deletion of existing features.

These modifications may cause the system to work incorrectly. Therefore, Regression
Testing becomes necessary.

Retest All

 This is one of the methods for Regression Testing in which all the tests in the
existing test bucket or suite should be re-executed. This is very expensive as it
requires huge time and resources.

Regression Test Selection

 Instead of re-executing the entire test suite, it is better to select part of the test
suite to be run
 Test cases selected can be categorized as 1) Reusable Test Cases 2) Obsolete
Test Cases.
 Re-usable Test cases can be used in succeeding regression cycles.
 Obsolete Test Cases can't be used in succeeding cycles.

Prioritization of Test Cases

 Prioritize the test cases depending on business impact, critical & frequently used
functionalities. Selection of test cases based on priority will greatly reduce the
regression test suite.

Selecting test cases for regression testing

It was found from industry data that a good number of the defects reported by
customers were due to last minute bug fixes creating side effects and hence selecting
the Test Case for regression testing is an art and not that easy. Effective Regression
Tests can be done by selecting the following test cases -
 Test cases which have frequent defects
 Functionalities which are more visible to the users
 Test cases which verify core features of the product
 Test cases of Functionalities which has undergone more and recent changes
 All Integration Test Cases
 All Complex Test Cases
  Boundary value test cases
 A sample of Successful test cases
 A sample of Failure test cases

Q #24) Differentiate between Regression testing and Re-testing.

Answer: Difference between Regression testing and Re-testing can be explained

as follows:

Regression testing Retesting

Regression testing is the form of testing which is Retesting is the form of testing the
carried out to make sure that implementation of any application after fixing of defects for
new feature or fixes does not affect any other part those test cases which were failed
or functionality of the application. in last execution.
As a part of regression testing, new changes in the
As a part of retesting, defect
application should not affect the existing
verification is done.
functionalities.
Retesting is performed before
Based on the project requirement, regression
regression testing because of its
testing can be parallel performed with retesting.
high priority.
Also known as generic testing and is done for Also known as planned testing and
passed test cases. is only done for failed test cases.
As manual testing can be time consuming and
expensive, automation can be done for regression
testing. Automation cannot be done for
retesting.

Q #25) Explain User Acceptance testing.

Answer:

User acceptance testing is usually performed after the product is thoroughly

tested.

In this form of testing, software users or say, client, itself use the application to
make sure if everything is working as per the requirement and perfectly in the real
world scenario.

UAT is also known as End-user testing.

What is Black Box Testing?

Black box testing, which is also known as behavioral, opaque-box, closed-box,

specification-based or eye-to-eye testing.

Software Testing method that analyses the functionality of a software/application

without knowing much about the internal structure/design of the item that is being
tested and compares the input value with the output value.

The main focus in black box testing is on the functionality of the system as a
whole.

The term ‘behavioral testing’ is also used for black box testing.

Types of Black Box Testing

Practically, there are several types of black box testing that are possible but if we
consider the major variant of it then below mentioned are the two fundamental ones.
#1) Functional Testing

This type deals with the functional requirements or specifications of an application.

Here, different actions or functions of the system are being tested by providing the input
and comparing the actual output with the expected output.

For Example,

when we test a Dropdown list, we click on it and verify that it expands and all the
expected values are showing in the list.

Few major types of Functional Testing are:

 Smoke Testing
 Sanity Testing
 Integration Testing
 System Testing
 Regression Testing
 User Acceptance Testing

#2) Non-Functional Testing

Apart from the functionalities of the requirements, there are several non-functional
aspects as well that are required to be tested to improve the quality and performance of
the application.

Few major types of Non-functional testing include:

 Usability Testing
 Load Testing
 Performance Testing
 Compatibility Testing
 Stress Testing
  Scalability Testing

Smoke Testing

Smoke testing is not an exhaustive testing but it is a group of tests that are executed to
verify if the BASIC FUNCTIONALITIES of that particular build are working fine as
expected or not.

This is and should always be the first test to be done on any ‘new’ build.

When the development team releases a build to the QA for testing, it is obviously not
possible to test the entire build and verify immediately if any of the implementations is
having bugs or if any of the working functionality is broken.

In the light of this, how will a QA make sure that the basic functionalities are working
fine?

The answer to this will be to perform a Smoke Testing.

Once the tests are marked as Smoke tests (in the test suite) pass, only then the build is
accepted by the QA for in-depth testing and/or regression.

If any of the smoke tests fail, the build is rejected and the development team needs to
fix the issue and release a new build for testing.

Theoretically, the Smoke test is defined as a surface-level testing to certify that the build
provided by the development team to the QA team is ready for further testing.

This testing is also performed by the development team before releasing the build to the
QA team.

Who Should Perform Smoke Test?

Smoke testing is ideally performed by the QA lead who decides based on the result as
for whether to pass the build to the team for further testing or reject it.

Or in the absence of the lead, the QA’s themselves can also perform this testing.
Why should we Automate Smoke Tests?

This testing is the first test to be done on a build released by the development team(s).
Based on the results of this testing, further testing is done (or the build is rejected).

The best way to do this testing is to use an automation tool and schedule the smoke
suite to run when a new build is created. You may be thinking why should I “automate
the smoke testing suite”?

Let us look at the following case:

Let’s say that you are a week away from your release and out of the total 500 test
cases, your smoke test suite comprises of 80-90.

If you start executing all these 80-90 test cases manually, imagine how much time will
you take? I think 4-5 days (minimum).

But if you use automation and create scripts to run all these 80-90 test cases then
ideally, these will be run in 2-3 hours and you will have the results with you instantly.

Didn’t it save your precious time and give you the results about the build in a much less
time?

5 years back, I was testing a financial projection app, which took inputs about your
salary, savings etc., and projected your taxes, savings, profits depending on the
financial rules.

Along with this, we had customization for countries that depend on the country and its
tax rules used to change (in the code).

For this project, I had 800 test cases and 250 were smoke test cases. With the use of
Selenium, we could easily automate and get the results of those 250 test cases in 3-4
hours.

It not only saved our time but showed us ASAP about the showstoppers.
Hence, unless it is impossible to automate, do take the help of automation for this
testing.

Sanity Testing

You must be wondering why I am mentioning specifically about the mobile apps here?
The reason is that OS and browser version for web or desktop apps do not vary
much and especially the screen sizes are standard. But with mobile apps, the
screen size, the mobile network, the OS versions etc affect the stability, look and in
short, the success of your mobile app.
Hence a strategy formulation becomes critical when you are performing this testing on a
mobile app because one failure can land you in a big trouble. The testing must be done
smartly and with caution too.
Following are some pointers to help you perform this testing successfully on a
‘mobile app’:

#1) First of all, analyze the impact of the OS version on the implementation with your
team.

Try to find answers to questions like, will the behavior be different across versions? Will
the implementation work on the lowest supported version or not?

Will there be performance issues for the implementation of versions? Is there any
specific feature of the OS that might impact the behavior of the implementation? etc.

#2) On the above note, analyze for the phone models also i.e. are there any features of
the phone that will impact the implementation? Is the implementation behavior changing
with GPS? Is the implementation behavior changing with the phone’s camera? etc. If
you find that there’s no impact, avoid testing on different phone models.

#3) Unless there are any UI changes for the implementation I would recommend
keeping UI testing on the least priority, you can inform the team (if you want) that UI will
not be tested.

#4) In order to save your time, avoid testing on good networks because it is obvious that
the implementation is going to work as expected on a strong network. I would
recommend starting with testing on a 4G or 3G network.

#5) This testing is to be done in a less time but make sure that you do at least one field
test unless it’s a mere UI change.

#6) If you must test for a matrix of different OS and their version, I would suggest that
you do it in a smart way. For instance, choose the lowest, medium and the latest OS-
version pairs for testing. You can mention in the release document that not every
combination is tested.
#7) On a similar line, for UI implementation sanity test, use small, medium and large
screen sizes to save time. You can also use a simulator and emulator.

What is White Box Testing?

If we go by the definition, “White box testing” (also known as clear, glass box or
structural testing) is a testing technique which EVALUATES THE CODE AND THE
INTERNAL STRUCTURE OF A PROGRAM.

White box testing involves looking at the structure of the code. When you know the
internal structure of a product, tests can be conducted to ensure that the internal
operations performed according to the specification.

Difference Between White-Box and Black-Box Testing

To put it in simple terms:

Under Black box testing, we test the software from a user’s point of view, but in White
box, we see and test the actual code.

In Black box testing, we perform testing without seeing the internal system code, but in
WBT we do see and test the internal code.

White box testing technique is used by both the developers as well as testers.

It helps them to understand which line of code is actually executed and which is not.

This may indicate that there is either a missing logic or a typo, which eventually can
lead to some negative consequences.

Steps to Perform WBT

Step #1 – Understand the functionality of an application through its source code.

Step #2– Create the tests and execute them.

Main White Box Testing Techniques:

1. Statement Coverage
2. Branch Coverage
3. Path Coverage