Testing Interview Questions and Answers

 

Q 1. What Is Black Box Testing?

Black Box Testing: Testing an Application Under Test (AUT) without referencing the internal structure is called the black box testing. Testing will be done by visualizing the application as a black box.

Black Box Test Technique: A testing technique to derive the test cases based on the functionality of the application and not considering the internal structure of the system.

Synonyms: Specification-Based Testing

Black box testing is a testing approach that is used to test the functionality of the AUT based on the specifications/SRS without any knowledge of the technology used to implement the application under test.

In the black-box testing, major testing will be around possible inputs and expected outputs. A tester should be able to choose the valid test data carefully. In simple terms, a tester can only see the actions of the AUT. The tester need not know how those actions are performed.

Example: A simple example of black-box testing is a TV (Television). As a user, we watch the TV but we don’t need the knowledge of how the TV is built and how it works, etc. We just need to know how to operate the remote control to switch on, switch off, change channels, increase/decrease volume, etc.

In this example,

The TV is your AUT (Application Under Test).
The remote control is the User Interface (UI) that you use to test.

You just need to know how to use the application.

Suggested Read => All That You Need to Know About Black Box Testing

Q 2. What Is White Box Testing?

White Box Testing: Testing an application with reference to the internal structure of the software component is called white box testing.

White-box test technique: A Procedure to derive and/or select test cases based on an analysis of the internal structure of a component or system.

Synonyms: Clear-box testing, Code-based testing, Glass-box testing, Logic-coverage testing, Logic-driven testing, Structural testing, Structure-based testing, etc.

White box testing is a test approach that is used to test the implementation part of an application under test. To perform this testing, the tester/possibly the developer should know the internal structure of the application and how it works.

Example: A Car mechanic should know the internal structure of the car engine to repair it.

In this example,

CAR is the AUT (Application Under Test).
The user is the black box tester.
The mechanic is the white box tester.

These are the basic definitions of white and black box testing and each test method has different techniques to follow.

Recommended Read => An In-Depth Tutorial on White Box Testing

Q 3. Difference Between Black Box And White Box Testing

S.No	Black Box Testing	White Box Testing
1	The main objective of this testing is to test the Functionality / Behavior of the application.	The main objective is to test the infrastructure of the application.
2	This can be performed by a tester without any coding knowledge of the AUT (Application Under Test).	Tester should have the knowledge of internal structure and how it works.
3	Testing can be performed only using the GUI.	Testing can be done at an early stage before the GUI gets ready.
4	This testing cannot cover all possible inputs.	This testing is more thorough as it can test each path.
5	Some test techniques include Boundary Value Analysis, Equivalence Partitioning, Error Guessing etc.	Some testing techniques include Conditional Testing, Data Flow Testing, Loop Testing etc.
6	Test cases should be written based on the Requirement Specification.	Test cases should be written based on the Detailed Design Document.
7	Test cases will have more details about input conditions, test steps, expected results and test data.	Test cases will be simple with the details of the technical concepts like statements, code coverage etc.
8	This is performed by professional Software Testers.	This is the responsibility of the Software Developers.
9	Programming and implementation knowledge is not required.	Programming and implementation knowledge is required.
10	Mainly used in higher level testing like Acceptance Testing, System Testing etc.	Is mainly used in the lower levels of testing like Unit Testing and Integration Testing.
11	This is less time consuming and exhaustive.	This is more time consuming and exhaustive.
12	Test data will have wide possibilities so it will be tough to identify the correct data.	It is easy to identify the test data as only a specific part of the functionality is focused at a time.
13	Main focus of the tester is on how the application is working.	Main focus will be on how the application is built.
14	Test coverage is less as it cannot create test data for all scenarios.	Almost all the paths/application flow are covered as it is easy to test in parts.
15	Code related errors cannot be identified or technical errors cannot be identified.	Helps to identify the hidden errors and helps in optimizing code.
16	Defects are identified once the basic code is developed.	Early defect detection is possible.
17	User should be able to identify any missing functionalities as the scope of this testing is wide.	Tester cannot identify the missing functionalities as the scope is limited only to the implemented feature.
18	Code access is not required.	Code access is required.
19	Test coverage will be less as the tester has limited knowledge about the technical aspects.	Test coverage will be more as the testers will have more knowledge about the technical concepts.
20	Professional tester focus is on how the entire application is working.	Tester/Developer focus is to check whether the particular path is working or not.

Q 4. Unit Testing Vs Integration Testing Vs Functional Testing

Unit testing means testing individual modules of an application in isolation (without any interaction with dependencies) to confirm that the code is doing things right.

Integration testing means checking if different modules are working fine when combined together as a group.

Functional testing means testing a slice of functionality in the system (may interact with dependencies) to confirm that the code is doing the right things.

Functional tests are related to integration tests, however, they signify to the tests that check the entire application’s functionality with all the code running together, nearly a super integration test.

Unit testing considers checking a single component of the system whereas functionality testing considers checking the working of an application against the intended functionality described in the system requirement specification. On the other hand, integration testing considers checking integrated modules in the system.

And, most importantly, to optimize the return on investment (ROI), your code base should have as many unit tests as possible, fewer integration tests and the least number of functional tests.

Q 5. Difference between Unit Testing Vs Integration Testing Vs Functional Testing

	Unit testing	Integration testing	Functional testing
Definition and purpose	Testing smallest units or modules individually.	Testing integration of two or more units/modules combined for performing tasks.	Testing the behavior of the application as per the requirement.
Complexity	Not at all complex as it includes the smallest codes.	Slightly more complex than unit tests.	More complex compared to unit and integration tests.
Testing techniques	White box testing technique.	White box and black box testing technique. Grey box testing	Black box testing technique.
Major attention	Individual modules or units.	Integration of modules or units.	Entire application functionality.
Error/Issues covered	Unit tests find issues that can occur frequently in modules.	Integration tests find issues that can occur while integrating different modules.	Functional tests find issues that do not allow an application to perform its functionality. This includes some scenario-based issues too.
Issue escape	No chance of issue escape.	Less chance of issue escape.	More chances of issue escape as the list of tests to run is always infinite.

Q 5. Performance Testing Vs Load Testing Vs Stress Testing

#1) Performance Testing

 What is Performance Testing?

Performance testing is the testing that is performed to ascertain how the components of a system are performing under a certain given situation.

Resource usage, scalability, and reliability of the product are also validated under this testing. This testing is a subset of performance engineering, which is focused on addressing performance issues in the design and architecture of a software product.

The above image clearly explains to us that Performance Testing is the superset for both load & stress testing. Other types of testing included in performance testing are Spike testing, Volume testing, Endurance testing, and Scalability testing. Thus, performance testing is basically a very wide term.

Performance Testing Goal:

The primary goal of performance testing includes establishing the benchmark behavior of the system. There are a number of industry-defined benchmarks that should be met during performance testing.

Performance testing does not aim to find defects in the application. It also does not pass or fail the test. Rather, it addresses the critical task of setting the benchmark and standard for an application. Performance testing should be done very accurately. Close monitoring of application/system performance is the primary characteristic of performance testing.

The benchmark and standard of the application should be set in terms of attributes like speed, response time, throughput, resource usage, and stability. All these attributes are tested in a performance test.

For Example,

For instance, you can test the application’s network performance through the “Connection Speed vs. Latency’ chart. Latency is the time difference between the data to reach from the source to the destination.

A 70kb page would not take more than 15 seconds to load for the worst connection of a 28.8kbps modem (latency=1000 milliseconds), while a page of the same size would appear within 5 seconds for the average connection of 256kbps DSL (latency=100 milliseconds).

A 1.5mbps T1 connection (latency=50 milliseconds) would have the performance benchmark set as 1 second to achieve this target.

Another example would be that of a Request-response model. We can set a benchmark that the time difference between the generation of requests and acknowledgment of responses should be in the range of x ms (milliseconds) and y ms, where x and y are the standard digits.

A successful performance test should project most of the performance issues, which could be related to database, network, software, hardware, etc.

#2) Load Testing

Load testing is meant to test the system by constantly and steadily increasing the load on the system until it reaches the threshold limit. This is a subset of performance testing.

Load testing can be easily done by employing any of the suitable automation tools available in the market. WAPT and LoadRunner are two such famous tools that aid in load testing. Load testing is also famous by names like Volume testing and Endurance testing.

However, Volume testing mainly focuses on databases. Endurance testing tests the system by keeping it under a significant load for a sustained time period.

The sole purpose of load testing is to assign the system the largest job it can possibly handle to test the endurance of the system and monitor the results. An interesting fact here is that sometimes the system is fed with an empty task to determine the behavior of the system in a zero-load situation.

The attributes which are monitored in the load test include peak performance, server throughput, response time under various load levels (below the threshold of break), adequacy of H/W environment, and how many user applications it can handle without affecting the performance.

Load Testing Goal:

The goals of load testing include:

• Exposing defects in an application related to buffer overflow, memory leaks and mismanagement of memory. The issues that will eventually come out as a result of load testing may include load balancing problems, bandwidth issues, the capacity of the existing system, etc.
• To determine the upper limit of all the components of an application like a database, hardware, network, etc. so that the application can manage the anticipated load in the future.
• To set the SLAs for the application.

For Example,

Let’s consider to check the email functionality of an application that could be flooded with up to 1000 users at a time. Now, 1000 users can fire the email transactions (read, send, delete, forward, reply) in many different ways.

If we take one transaction per user per hour, then it would be 1000 transactions per hour. By simulating 10 transactions/users, we can load test the email server by occupying it with 10000 transactions/hour.

Another Example of a load test is shown in the image below:

The above image depicts a load test done in the tool called JMeter. This test is done to identify how many users a system can handle. In this test, 100 users are added after every 30 seconds until the load reaches 1000 users. Each step takes 30 seconds to complete and JMeter waits for 30 seconds before kicking off the next step.

Once the load reaches 1000 threads, all of them will continue running for 300 seconds (5 mins) together and then finally stops 10 thread every 3 seconds.

#3) Stress Testing

Under stress testing, various activities to overload the existing resources with excess jobs are carried out in an attempt to break the system down. Negative testing, which includes removal of components from the system, is also done as part of stress testing.

Also known as fatigue testing, this testing should capture the stability of an application by testing it beyond its bandwidth capacity.

Thus, stress testing evaluates the behavior of an application beyond peak load and normal conditions.

The purpose of stress testing is to ascertain the failure of the system and to monitor how the system recovers back gracefully. The challenge here is to set up a controlled environment before launching the test so that you can precisely capture the behavior of the system repeatedly under the most unpredictable scenarios.

Issues that will eventually come out as a result of stress testing may include synchronization issues, memory leaks, race conditions, etc. If the stress test is checking how the system behaves in the situation of a sudden ramp-up in the number of users, then it is called a spike test.

If the stress test is to check the system’s sustainability over a period of time through a slow ramp-up in the number of users, it is called a soak test.

Stress Testing Goal:

The goal of stress testing is to analyze post-crash reports to define the behavior of the application after failure.

The biggest challenge is to ensure that the system does not compromise the security of sensitive data after the failure. In successful stress testing, the system will return to normality along with all its components even after the most terrible breakdown.

For Example,

A word processor like Writer1.1.0 by OpenOffice.org is utilized in the development of letters, presentations, spreadsheets, etc.  The purpose of our stress testing is to load it with excess characters.

To do this, we will repeatedly paste a line of data, until it reaches its threshold limit of handling a large volume of text. As soon as the character size reaches 65,535 characters, it would simply refuse to accept more data.

The result of stress testing on Writer 1.1.0 produces a result that does not crash under stress and it handles the situation gracefully which ensures that the application is working correctly even under rigorous stress conditions.

Another Example of a load test which depicts a spike test through sudden ramp-up of 7000 users is shown below:

Q #1) Is Load testing and Performance testing the same?

Answer: The answer to this is “No”. They are not the same.

By now you must have clearly understood the difference between performance testing and load testing. You can refer to the tabular summary below to see how performance and load testing have different objectives and scope attributes to the study and issues to uncover.

Q #2) Is it an unfair test to perform Stress testing at the same time while you perform load testing?

Answer: This is also a common question in many software testing interviews and certification exams as is it unfair to do stress testing and load testing parallelly? The answer to this is “No”. It is not unfair to do stress testing at the same time when you are doing load testing.

No test is ever unfair. As a tester, your job is to find issues. However, the actualities of software testing may apply and any issues that you detect in this situation may not be fixed.

Q #3) Is Recovery testing a part of Performance testing?

Answer: Yes, recovery testing is categorized under performance testing and at times it is also conducted with load testing. During recovery testing, it is accessed as how well an application is able to recover from faults, crashes, hardware failures, and other similar issues.

In this activity, the software is forced to fail and then it is verified if it is able to recover properly. For example, restarting the system suddenly when an application is running and then verifying the data integrity of the application.

Q #4) Does Performance testing require coding?

Answer: Performance testing does not require you to know the advanced level of coding. However, having a fundamental knowledge of programming is an added advantage.

For Example, if you are using JMeter, then it is good for you to know the fundamentals of Java. It can help you to debug certain things and you can also write your own script if required.

Q #5) What is Spike testing in Performance testing?

Answer: In spike testing, the load is abruptly increased or decreased by a huge number of users and later the system behavior is observed. Spike testing is mainly done to check if the system is able to handle sudden changes in the load.

Difference Between Load And Stress Testing

To summarize, let’s observe the major differences between load testing, stress testing as well as performance testing in the table below:

	Performance Testing	Load testing	Stress testing
Domain	Superset of load and stress testing	A subset of performance testing.	A subset of performance testing.
Scope	Very wide scope. Includes - Load Testing, Stress Testing, capacity testing, volume testing, endurance testing, spike testing, scalability testing and reliability testing, etc.	Narrower scope as compared to performance testing. Includes volume testing and endurance testing.	Narrower scope as compared to performance testing. Includes soak testing and spike testing.
Major goal	To set the benchmark and standards for the application.	To identify the upper limit of the system, set SLA of the app and see how the system handles heavy load volumes.	To identify how the system behaves under intense loads and how it recovers from failure. Basically, to prepare your app for the unexpected traffic spike.
Load Limit	Both – below and above the threshold of a break.	Till the threshold of break	Above the threshold of break
Attributes studied	Resource usage, reliability, scalability, resource usage, response time, throughput, speed, etc.	peak performance, server throughput, response time under various load levels (below the threshold of break), adequacy of H/W environment, the number of user app can handle, load balancing requirements, etc.	Stability beyond bandwidth capacity, response time (above the threshold of break), etc.
Issues identified through this testing type	All performance bugs including runtime bloat, the scope for optimization, issues related to speed, latency, throughput, etc. Basically – anything related to performance!	Load balancing problems, bandwidth issues, system capacity issues, poor response time, throughput issues, etc.	Security loopholes with overload, data corruption issues at overload situation, slowness, memory leaks, etc.

Difference Between Load, Stress And Volume Testing

By now we already know about the load and stress testing along with the differences between the two. Let’s now explore what volume testing is and how it is different from load testing and stress testing.

Volume testing is also a kind of performance testing that majorly focuses on the database.

In volume testing, it is checked as for how the system behaves against a certain volume of data. Thus, the databases are stuffed with their maximum capacity and their performance levels like response time and server throughput are monitored.

To keep it very simple, the difference between load, stress and volume testing is shown below:

Volume testing	Load testing	Stress testing
A huge amount of data	A huge number of users	Too many users, too much data, towards system crash.

Sanity Testing

Sanity Testing is done when as a QA we do not have sufficient time to run all the test cases, be it Functional Testing, UI, OS or Browser Testing.

Hence, we can define,

“Sanity Testing as a test execution which is done to touch each implementation and its impact but not thoroughly or in-depth, it may include functional, UI, version, etc. testing depending on the implementation and its impact.”

Sanity Testing Vs Regression Testing

Given below are a few differences between the two:

S. No.	Regression Testing	Sanity Testing
1	Regression testing is done to verify that the complete system and bug fixes are working fine.	Sanity testing is done at random to verify that each functionality is working as expected.
2	Every tiniest part is regressed in this testing.	This is not a planned testing and is done only when there’s a time crunch.
3	It is a well elaborate and planned testing.	This is not a planned testing and is done only when there’s a time crunch.
4	An appropriately designed suite of test cases is created for this testing.	It may not every time be possible to create the test cases; a rough set of test cases is created usually.
5	This includes in-depth verification of functionality, UI, performance, browser/OS testing etc. i.e. every aspect of the system is regressed.	This mainly includes verification of business rules, functionality.
6	This is a wide and deep testing.	This is a wide and shallow testing.
7	This testing is at times scheduled for weeks or even month(s).	This mostly spans over 2-3 days max.

Smoke Testing

Smoke Testing is not 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 are having bugs or if any of the working functionality is broken.

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

The answer to this will be to perform Smoke Testing.

Once the tests are marked as Smoke tests (in the test suite) pass, only then will the build be accepted by the QA for in-depth testing and/or regression. If any of the smoke tests fail, then 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 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.

This testing is normally used in Integration Testing, System Testing, and Acceptance Level Testing. Never treat this as a substitute for actual end to end complete testing. It comprises of both positive and negative tests depending on the build implementation.

Difference Between Smoke and Sanity Testing

Most of the time we get confused between the meaning of Sanity Testing and Smoke Testing. First of all, these two testings are way “different” and are performed during different stages of a testing cycle.

S. No.	Smoke Testing	Sanity Testing
1	Smoke testing means to verify (basic) that the implementations done in a build are working fine.	Sanity testing means to verify the newly added functionalities, bugs etc. are working fine.
2	This is the first testing on the initial build.	Done when the build is relatively stable.
3	Done on every build.	Done on stable builds post regression.

SMOKE TESTING

• This testing originated in the hardware testing practice of turning on a new piece of hardware for the first time and considering it a success if it does not catch fire or smoke. In the software industry, this testing is a shallow and wide approach whereby all the areas of the application without getting into too deep, is tested.
• The smoke test is scripted, either using a written set of tests or an automated test
• Smoke tests are designed to touch every part of the application in a cursory way. It’s shallow and wide.
• This testing is conducted to ensure whether the most crucial functions of a program are working, but not bothering with the finer details. (Such as build verification).
• This testing is a normal health check-up to the build of an application before taking it to test in-depth.

SANITY TESTING

• A sanity test is a narrow regression test that focuses on one or a few areas of functionality. Sanity Testing is usually narrow and deep.
• This test is usually unscripted.
• This test is used to determine that a small section of the application is still working after a minor change.
• This testing is cursory testing, it is performed whenever a cursory testing is sufficient to prove that the application is functioning according to specifications. This level of testing is a subset of regression testing.
• This is to verify whether the requirements are met or not, by checking all the features breadth-first.

Static Testing Vs Dynamic Testing

Let us now understand the differences between these two important testing techniques:

Static Testing	Dynamic Testing
Also known as Verification testing.	Also known as validation testing.
Does not require execution of the source code.	Requires execution of the source code.
Static testing is all about prevention of the defects	Dynamic testing is all about detecting the defects
It involves the documents, checklists, and a process to be followed	It involves the source code and the test cases for execution
No code compilation needed	Code should be compiled and in executable situation.
Cost of fixing the defects found is less	Cost of fixing the defects found is more
Done in early stages of the development life cycle	Done in later stages of the development life cycle.
Requires lots of meetings	Requires fewer meetings
This testing is done before code deployment	This testing is done after code deployment
Performs a dry run on the code as part of the static analysis of the code.	Code is fully analyzed for different paths by executing it.
Static testing covers the structural and statement coverage testing.	Dynamic testing covers the executable file of the code.
It includes the following items for testing:	It includes the following items for testing:
?        Requirement document	?        Unit tests
?        Design documents	?        Integration tests
?        Program specifications	?        System tests
?        GUI wireframes	?        Security tests
	?        Performance tests
	?        User acceptance tests
It consists of reviews, walkthrough, inspection and static analysis of code.	It consists of functional testing, non-functional testing and data/control flow analysis.
Some of the tools used for Static testing are: * Soot * Eclipse * Checkstyle * Clang * Sonarqube * Source meter	Some of the tools used for dynamic testing are: * ValGrind * Procmon * DroidBox * Diakon * BoundsChecker