Explore topic-wise InterviewSolutions in .

Different categories of debugging include: 

• Brute force debugging 
• Backtracking 
• Cause ELIMINATION 
• Program SLICING 
• Fault TREE analysis 

Agile testing is basically a software testing process that uses agile methodologies i.e., follow test-first design paradigm. It evaluates the software from the customer's point of view. It does not require any development team to complete coding for starting QA, instead of testing and coding can go hand in hand. Features are TESTED as they are DEVELOPED. Some of its advantages include:  

• BOOSTS the performance as it allows all the testers and developers to work together 
• Features are tested as they are developed 
• Ensure successful delivery of the high-grade product 
• Saves time and money 
• Flexible and highly adaptable to changes 
• Improves product QUALITY and allows developers to release software as early as POSSIBLE

Data flow testing is a type of STRUCTURAL testing that is used to analyze the flow of data in the program. In this, a programmer can perform various tests on data values and variables. USING this testing, one can determine the variables that are used at every stage of the program’s control flow. It HELPS us in the following ways: 

• Eliminate or remove variables that are NEVER used after being declared  
• Pinpoint variables that are used but never declared  
• Deallocate variable before it is used 
• Pinpoint variables that are DEFINED multiple times before it is used 

Fuzz testing is a software testing technique in which a large AMOUNT of random data, called fuzz, is provided as input to the application simply to detect or discover security loopholes and coding errors in the software application. It is more useful for bigger projects but it only detects a serious FAULT or defect. It is simply used to CHECK the vulnerability of software and gives more effective results when used with BETA testing, black box testing, etc.

Baseline Testing: It is a TYPE of non-functional testing in which a set of tests are run to capture performance information. Using this GATHERED information, we can make required changes in the application and ultimately improve the performance and capabilities of the application. In general, it refers to a benchmark that usually forms the base of any new creation. During this testing, MANY errors are discovered and resolved. 

Benchmark Testing: It is a type of testing that involves both the developers and DBAs (Database Administrators) to determine current performance information. Using this information, one can improve the performance of the same by MATCHING it with the BENCHMARKS (industry standards). Its main objective is to compare the present and future software releases with their specific benchmark. 

Path testing is a type of testing specially USED to DESIGN test cases. In this type of testing, the control flow graph of a PROGRAM is specially designed to identify a set of linearly independent paths of execution. Its main objective is to ensure that each path is COVERED and executed well. It also reduces or MINIMIZES the occurrence of redundant tests. 

Localization testing is a type of testing that is performed to ensure whether the software product offers full functionality and usability in a PARTICULAR LOCALE or not. It is simply used to verify the ACCURACY and suitability of the CONTENT. It is not only about linguistics, but also about traditions, common HERD behavior, and other similar factors. It generally deals with the functionality and GUI of the application.

Endurance testing, also KNOWN as SOAK testing, is a type of performance testing usually performed to check the performance of the system that is under constant use. Its main purpose is to DETERMINE whether a system can sustain a continuous high load or not. Memory UTILIZATION is also monitored to identify potential leaks during this testing. Some of the endurance testing tools include: 

• WebLOAD 
• LoadUI 
• OpenSTA 
• LoadComplete 
• Apache JMeter, etc. 

Test driver and test stub, both are types of test harness that are USED to provide a simulation environment for testing a module or component. They both are dummy MODULES specially created for test purposes. 

Test STUBS: Test stubs are used in a top-down testing approach and allow testing of the upper levels of the CODE when the lower levels of the code are not developed yet. It is used as ‘called programs’ when subprograms are under construction. 

Test drivers: Test drivers are used in a bottom-up testing approach and allow testing of the lower levels of the code when the upper levels of the code are not developed yet. It is used as ‘called programs’ when main programs are under construction. 

Monkey Testing: Monkey testing, ALSO known as Random Testing, is a type of SOFTWARE testing technique in which data is generated randomly using a tool or some automated mechanism. The system is tested using this randomly generated input, and results are analyzed ACCORDINGLY. There are no such rules in this type of testing.

Performance Testing: It is a type of non-functional software testing technique that is used to determine the system parameters like speed, scalability, and STABILITY under different WORKLOAD conditions. Its main purpose is to eliminate performance bottlenecks, not to find bugs. Some of the key parameters of performance testing include: 

• CPU Utilization
• Memory Utilization
• QPS/TPS (Transaction per second)
• Average load time
• System throughput, etc.

All the COMPONENTS of the software are GENERALLY TESTED as a whole to MAKE sure that the overall product fulfills the requirements that are specified. So, no. system testing cannot be done at any stage instead system testing must start only when all modules or units work correctly and are in place, but it needs to be performed before UAT. 

UAT, also KNOWN as end-user testing, is BASICALLY a testing methodology performed by the end-users or clients for the approval of the production release. It is one of the last STAGES of the SDLC and is only performed after the software has been tested thoroughly. Its main purpose is to validate end-to-end business flow. It makes sure that the developed software meets all the requirements to float into the market or not.

A CRITICAL bug is referred to as a bug that affects the majority of the functionality of the given APPLICATION. It does not DISTURB or block the testing of other parts of the given application. A bug is only classified as critical when it HALTS the core OPERATIONS of the software.

Positive Testing: It is a type of testing process where the software application is validated against the valid data sets as an input. It is simply used to CHECK whether the application does what it is supposed to do or not.

Negative Testing: It is a type of testing process where the software application is validated against invalid data sets as an input. It is simply used to check whether the system SHOWS an error when it is supposed to do or not. In test case execution, negative testing is considered a very crucial factor. 

Positive vs Negative Testing:

Test Matrix: It is referred to as a testing tool that is used to capture actual quality, EFFORT, resources, plan, and time required to capture all the phases of software testing. It only COVERS the testing phase of the LIFE cycle.  

Requirement Traceability Matrix (RTM): It is referred to as a document, usually present in the form table, that is used to trace and demonstrate the relationship between the requirements and other artifacts of the PROJECT right from start to end. In simple words, it maps between test cases and customer requirements.  

Use case testing is basically defined as a technique that helps DEVELOPERS and testers to identify TEST cases that exercise the whole system on each transaction basis right from start to finish. It is a part of black-box testing that is used widely in DEVELOPING TESTS or systems for ACCEPTABLE levels.  

Error: It is defined as a programming MISTAKE in coding because of which we can't compile or run a program.  

Defect: It is defined as the variation or difference between the actual result and the expected result FOUNDED by a tester or developer. The defect is BASICALLY detected after the product goes into production and is resolved in the development PHASE only.  

Bug: It is defined as a fault or MISMATCH in a software system that is detected during the testing phase. It has an impact on software functionality and performance. 

STLC (Software Testing Life Cycle) is a fundamental PART of SDLC which is used to test software and ensure that the QUALITY standards are met. It generally involves both verification activities and validation activities. In this, different activities are executed in a specific order throughout the software testing process. There are basically six different phases in STLC Model as shown below: 

• Requirement ANALYSIS 
• Test Planning 
• Test Case Development 
• Test Environment Setup 
• Test Execution 
• Test Cycle Closure 

Test deliverables, also known as test artifacts, are basically a list of all of the documents, tools, and other components that are given to the stakeholders of a SOFTWARE project during the SDLC. Test deliverables are maintained and developed in support of the test. At every phase of SDLC, there are DIFFERENT deliverables as given below:

Before TESTING Phase 

• Test plans document. 
• Test cases documents 
• Test Design specifications.

During Testing Phase 

• Test Scripts 
• Simulators. 
• Test Data 
• Test Traceability Matrix 
• Error logs and execution logs

After testing Phase 

• Test Results/reports 
• Defect REPORT 
• Installation/ Test procedures guidelines 
• Release NOTES 

Test report is BASICALLY a document that includes a total summary of testing objectives, activities, and results. It is very much required to REFLECT testing results and gives an opportunity to estimate testing results quickly. It helps us to decide whether the product is ready for release or not. It also helps us DETERMINE the CURRENT status of the project and the quality of the product. A test report must include the following DETAILS: 

• Test Objective 
• Project Information 
• Defect 
• Test Summary

A test plan is basically a dynamic document monitored and controlled by the testing manager. The success of a testing project totally depends UPON a well-written test plan document that describes software testing scope and activities. It basically serves as a blueprint that outlines the what, when, how, and more of the entire test PROCESS. 

A test plan must INCLUDE the following details: 

• Test Strategy 
• Test Objective 
• Test Scope 
• Reason for Testing 
• Exit/Suspension Criteria 
• Resource Planning 
• Test Deliverables. 

There are various ATTRIBUTES of test cases that make them more reliable, clear, and concise, avoiding any sort of redundancy. Some of them are given below: 

• Test Case Id: Unique identifier of test case 
• Test Summary: One-liner summary of test case 
• Description: Detailed description of test case 
• Prerequisite or pre-condition: Set of conditions to be FOLLOWED before implementing the test steps 
• Test steps: Detailed steps for performing test case 
• Test Data: Test data value USED in test case 
• EXPECTED Result: Estimated result to pass the test 
• Actual Result: Actual result after executing the test steps. 
• Test Result: Status of the test execution (Pass or Fail) 
• Automation Status: Identifier for automation 
• Date: Test execution date 
• Executed By: Person NAME executing the test case 

TEST case is basically a document that includes a set of test data, preconditions, expected results, and postconditions. This document is specially developed for a specific test scenario to ensure WHETHER the software product meets the specific requirement or not.  In manual testing, test cases are executed manually by a TESTER without USING any of the automated tools. One can easily identify loopholes in the specifications while DEVELOPING test cases.  

Some of the commonly applied DOCUMENTATION ARTIFACTS that are associated with software testing include:  

• Test Plan 
• Test SCENARIO 
• Test Case  
• TRACEABILITY Matrix 

Testbed is generally referred to as a DIGITAL platform that is used for testing an APPLICATION. It includes an operating SYSTEM, hardware, network CONFIGURATION, database, SOFTWARE application under test, and all other software-related issues.  

Validation: It is defined as a process that involves DYNAMIC testing of software products by running it. This process validates WHETHER we are building the right software that meets that customer requirement or not. It involves various activities like system testing, integration testing, user acceptance testing, and UNIT testing.

Verification: It is defined as a process that involves analyzing the documents. This process verifies whether the software conforms to specifications or not.  Its ultimate goal is to ENSURE the quality of software products, design, architecture, etc.  

Verification Vs Validation:

Latent defect, as the name SUGGESTS, is a type of defect or bug which has been in the software system for a LONG time but is discovered now. A latent defect is an existing defect that can be FOUND effectively with inspections. It usually remains hidden or DORMANT and is a low-priority defect. 

There are SEVERAL methods that can be used in CODE COVERAGE includes: 

• Statement Coverage 
• Decision Coverage 
• Branch Coverage 
• Toggle Coverage 

BENEFITS of manual testing over AUTOMATED testing:

• When test cases need to be run for a short duration of time (once or twice). 
• When one needs to perform ad-hoc testing, EXPLORATORY testing, or usability testing 
• When one wants to ENSURE the user-friendliness of an application 
• When flexibility is REQUIRED 
• When one wants to better handle the complex scenarios 

Benefits of automated TESTING over manual testing  

• When test cases NEED to be run repeatedly for a long duration of time.  
• When one needs to perform regression testing, performance testing, or load testing. 
• When one wants to record the testing process 
• When one has less time to complete the testing phase 
• When tests are needed to be executed in a standard runtime environment 
• When tests include REPETITIVE steps 
• When there are multiple and quick DEPLOYMENTS for the product, manual becomes very time TAKING and redundant

Some of the top MANUAL TESTING tools include:

• Postman
• Message QUEUE monitors
• DB tools, ETC.

DIFFERENT types of MANUAL testing INCLUDE: 

• Black Box Testing 
• White Box Testing 
• Unit Testing 
• System Testing 
• Integration Testing 
• Acceptance Testing 
• PERFORMANCE Testing
• Load Testing

The process of manual testing includes the FOLLOWING: 

• Planning and control 
• Analysis and DESIGN 
• IMPLEMENTATION and Execution 
• Evaluating exit criteria and Reporting 
• TEST CLOSURE activities

There are several drawbacks of manual testing as given below: 

• Not SUITABLE for time-bounded projects and LARGE organizations  
• More prone to human errors and mistakes 
• Less efficient as the choice of recording the testing process is not available 
• Less Reliable 
• Regression testing is time-consuming 
• Does not cover all the aspects of testing 
• LOAD testing and performance testing can be performed manually 
• More expensive in the LONG RUN process

There are several advantages of MANUAL testing as given below: 

• Preferable for products with a short life cycle 
• Saves time, money, and resources 
• ENSURE the error-free product 
• Useful in ad-hoc testing, exploratory testing, and usability testing 
• No need to change the entire code to make minor changes 
• Get accurate user interface feedback  
• ABILITY to handle difficult use case SITUATIONS in a better way 
• GUI testing can be done accurately 
• Highly reliable 
• Make user-friendliness better 
• Easy to learn for new TESTERS 

Code coverage is one of the IMPORTANT testing metrics. It INDICATES the ratio of the codebase under unit tests to the entire codebase. Code coverage of 50% means that the unit tests cover half of the codebase.

It is crucial to keep in mind that 100% code coverage doesn’t mean that the software is error-free or there are no bugs. It just means that the unit tests cover all the code. However, it’s still possible that the tests don’t test all branches that code COULD TAKE or the problems with business LOGIC execution.

API testing ensures that the APIs that the software is using work as EXPECTED. The tester writes code that makes an API request to the server that provides the API, provides the required inputs, collects the output from the response, and matches the ACTUAL output with the expected output.

API testing primarily CONCERNS the business logic of the software that’s exposing the API. It does not involve the look and feel, accessibility, or usability of the software. API testing can be automated to make it repeatable and reproducible each time they RUN. 

In contrast to static TESTING, dynamic software testing tests the software when it’s executing. The TESTER runs the software in a test ENVIRONMENT and goes through all the steps involved, entering the inputs and verifying the actual output with the expected result.

Static testing is a technique in which you test the software without ACTUALLY executing it. It INVOLVES doing code walkthroughs, code reviews, peer-reviews, or using sophisticated tools such as eslint, StyleCop to PERFORM static ANALYSIS of the source code. Static testing is typically PERFORMED during software development.

Once you ship the software to the customers after alpha TESTING, the software's actual users perform the beta testing in a REAL production environment. It is one of the final components of user acceptance testing. Beta testing is HELPFUL to get feedback from real PEOPLE using your software in real ENVIRONMENTS. 

Before you SHIP the software to the CUSTOMERS, the internal TESTING team performs alpha testing. Alpha testing is part of the user acceptance testing. Its goal is to identify bugs before the customers START using the software.

White-box testing is an alternative strategy to black-box testing, in which a tester views the system as a transparent box. They are allowed to OBSERVE the internal implementation of the system, which guides the TEST. Typically, the software developers perform the white-box testing during the development phase.  

In white-box testing, we ASSUME that the tester has some programming knowledge. They try to test each possible branch a program COULD take in a running system. Knowing what’s INSIDE the box, i.e., taking a look at the source code and the implementation details, it’s possible to test the system more thoroughly.

In black-box testing, the tester views the software as a black box, ignoring all the internal structure and behavior. Their only concern is the input provided to the system and the generated output. Black-box testing verifies the program’s behavior against the specified requirements.

During black-box testing, the TEST conditions are created based upon the software’s functionality but are unaware of how the software works internally. The software is tested from the end user’s perspective and gives a BROADER picture of the whole system.

Given that the users are only concerned with whether the software works according to their NEEDS and don’t care how it works, black-box testing helps test software USABILITY and anticipate how the customer will use the product.