Functional Testing Interview Questions and Answers for 2024 Software Testing

The process of functional testing generally involves a deep understanding of the documentation done in the form of test planning. It involves writing cases for tests along with their requisite resource specification (even for unforeseeable circumstances). It involves identifying lucrative inputs and scrutinizing the data that is to be entered to achieve the desired outcome for a particular test. As per the specified input values, it determines whether the software is working fine or not. And in case, it isn't, then the tester needs to do a proper root cause analysis followed by logging the bug and assigning them to be corrected. Once, the bugs are fixed by the team, the tester needs to retest and pass the test case.

Functional testing is a black box technique involving generating a desired outcome for a set of tests or functions being performed. Non-functional testing, on the other hand, is a black box technique involving generating a desired outcome for a set of expectations laid out by the client. While functional testing can be easily performed via automation as well as manual testing tools, non-functional testing can only be carried out with tools that prove to be effective during functional testing. Manual testing is seamlessly performed when the features are being tested, as happens in functional testing. When it comes to nonfunctional testing, manual testing becomes a daunting task as reliability, scalability, and speed are the limited input parameters used. Functional testing involves techniques such as the integration testing technique, the regression testing technique, smoke testing technique, the system testing technique, the unit testing technique, the usability testing technique, and the user acceptance technique. On the other hand, non-functional testing involves techniques such as the compatibility testing technique, the load, stress, volume testing technique, the performance testing technique, and the security technique.

Writing test cases is of paramount importance when it comes to functional testing. Here, the use of both - writing skills, as well as in-depth software testing skills, is required. The language used for writing the test cases should be lucid. Apart from that, there should be a clear understanding of what the client needs to have on the screen. No assumptions should be made by the tester. Each doubt should be cleared. The input data should hold some value and should come with a wide scope. The test cases should feature any and every requirement. Nothing should be missed and nothing should be skipped. In order to do this, testers keep a traceability matrix for every requirement (especially the functional and the non-functional ones such as compatibility, UI, etc.) and record the progress made. On top of that, testers should not refrain from test cases. Apart from keeping redundancy at bay, high-priority cases should be taken into account first, followed by the medium-priority test cases and then the low-priority ones.

Focusing on the release, quality-based test cases can be made so that it becomes seamless for the developer and the tester to analyze the project.

When it comes to functional testing, two different test techniques are used that has different basis: 

• Requirement-based testing technique 

Under the requirement-based testing technique, functional testing is executed keeping in mind the requirements established on the basis of the identified risks. In addition to that, it is made sure that the requisite critical test paths are incorporated into the testing process via this testing technique. 

• Business process-based testing technique 

Under the business process-based testing technique, functional testing is given a brand-novel business outlook. For the execution of this type of testing technique, business knowledge is explored and used for performing tests successfully. 

The login features that should be tested for a web application are 

• The input fields. 

Nothing can be as important as these. The username and password should be entered as invalid and then valid values to check the working of the input fields. 

• Watch out for the error message! 

Entering an incorrect password for a valid e-mail address and then a valid password for an invalid e-mail address will display the error message. Read it carefully. 

• Still logged in? 

Simply log into the application with the correct login credentials. Now, close the browser and reopen it to see whether it is still logged in or not. In addition to that, a tester should try going to the previous page and then coming back to the one with the application to see if it is still logged in or not. 

• Check from different browsers. 

Try laying your hands on multiple browsers while testing. Login from one browser, check how it is working on some other browser, and then see if you are still logged in or not. 

• Try changing passwords. 

Once logged in, simply change the password. Now, try logging in with the previous password.

Data-driven testing is all about repeating the execution of test cases of test scripts with the help of the inputs from a random CSV file, an Excel spreadsheet, an SQL database, or an XML file. Afterward, the outputs are compared to the one the tester was expecting. It is helpful since this methodology can be reused, and repeated with the test inputs remaining intact and separated from the test logic. In addition to that, this methodology can keep the test cases in check. For data-driven testing, testers generally put a test studio to use. This methodology is practiced because it comes with umpteen benefits. Some of them are: 

• Data-driven testing allows testing with the help of a variety of data values that come in sets, especially during regression testing. 
• With the help of data-driven testing, both the test as well as the verification data can be compiled in a single file. Best of all, it remains distinguished from the test cases' logic. 
• Based on the automation tool, it is plausible to keep all the concerned test scripts in the same repository, thus making the texts pretty lucid to understand, organize as well as maintain. 
• Because of data-driven testing, functions, and actions can now be used again in an array of tests. 
• With certain tools, you can now generate test data quickly and automatically. This comes in handy when a tester is asked to generate loads and loads of data randomly, and thus is time-saving. 
• With the help of data-driven testing, the previously-conducted tests can be re-conducted and that too umpteen times, thus reducing the number of test scripts and test cases. 
• It is because of data-driven testing that the test script is prevented in any and every manner from modifying the test data. 

While data-driven testing sounds very lucrative, it does come with some drawbacks. These are: 

• There is no iota of doubt that data validation involves a lot of time especially when the tester is dealing with a gigantic database. 
• Herein, the quality of the execution of a test depends entirely on the automation testing skills of not the testing but the implementing team which is less adept in functional testing. 
• Since it requires consistent and a lot of coding work, data-driven testing often comes with a maintenance issue. 
• Training needs are high-end here. A tester may be compelled to pick a novel scripting language in between the project which might disrupt the schedule. 
• More and more documentation is undertaken in data-driven testing. Many test scripts are on infrastructure testing and other results alone. 
• A different notepad-like creation is required for data-driven testing in order to create and properly maintain data-related files. 

A common question in functional testing interview questions for freshers, don't miss this one. Automation testing is where test cases are executed quickly with the help of any of the automation tools such as Selenium, SoapUI, Tellurium, and Watir to enhance the test coverage. Such functional testing automation tools help in interacting with the user interface of an application that is currently under testing. They assist the tester in identifying buttons and list boxes amidst other objects present on the screen which can be selected for data entry or can be pressed. One of the most widely used functional testing automation tools is the recorder. A recorder watches the way in which users engage and interact with the application as well as the array of objects hovering on the screen. It also records how users can select these visible objects, enter data, press buttons as well as select menus and perform a variety of other actions.

These actions are then replayed using the same set of objects to replicate the activities of the user base. The results fetched here are recorded by the functional testing automation tool. These are then compared with the results that are expected as per the automation engineer's criteria on the test getting successfully completed or getting failed. These functional testing automation engineers work on their tests in a step-by-step manner with the help of objects that can be edited with the help of tools. They also record steps and customize them based on the general data they have from the user's engagement or interaction with the application. Last but not least, they run the tests under different circumstances and in an array of environments including mobile devices and browsers.

Since automation testing focuses on executing the test cases that are pre-scripted, this methodology doesn't require any human input. In addition to that, automation testing emphasizes comparing the outcomes obtained every time. This methodology is lucid to use, is accurate and because of repeatability, it comes with a great consistency level as compared to other methodologies.

It is a type of performance testing wherein an application is tested for handling a humungous database as well as the inflow of too much user traffic. The outcome is obtained in the form of its performance level and the run time it takes. Volume testing is also known as 'flood testing'. 

Volume testing has a lot of benefits. These include: 

• It helps in consuming money by pre-identifying major load issues. 
• If you have scalability plans, then you can get a good jumpstart with volume testing. 
• Bottlenecks in the testing process are identified earlier and quicker. 
• It helps in checking the load an application can take with humongous data inputs. 
• Volume testing reveals the point where the application or the software will be robbed of its stability. 
• It is a great identifier of an application or a system's capacity. It assigns labels of normal volume and heavy volume. 
• An application should be of use in the real world. This validation is obtained with the help of volume testing. 

To perform volume testing, a tester can follow some typical steps. These are: 

• Initiate a test to look for any data loss. 
• Carefully see what the response time of the system or the application is. 
• Check if the data has been stored aptly or not. 
• Look out for overwritten notifications that happen because of data leakage. 
• For volume problems, always look out for warning notifications as well as error messages. 
• Carefully observe the indelible impact humungous data leaves on the processing speed of the application or the software. 
• See if the system or the application you are working on has sufficient memory resources or not. 
• Now, see whether the volume testing has been executed over the entire system or the application, or not. 
• What happens if the data volume exceeds the permissible limit? Identify the arising risks, defects, or faults. 
• Does the application or software has some constrictions on larger dates? If yes, then, what are they? 

In this manner, you can execute volume testing on your application or software.

With exploratory testing, a tester implies exploring and identifying the loopholes in an application without following any sort of procedures, laid-out timelines, or schedules. In addition to that, testers don't follow any set pattern while performing exploratory testing. They tend to give the reins to their creative side and come up with diverse and unique ideas to see what a particular software or application turns out to be. 

Since its inception, exploratory testing has enabled testers to study the micro-aspects of applications and helps them to identify more bugs and issues as compared to the ones they are able to find with the help of any random or normal testing technique. This is the reason why testers keep on relying on this methodology, especially in cases when: 

• The test lead wishes to incorporate the testing experiences of any and everybody who is on the team. 
• Test cases have been prepared with the help of all the identified critical paths. 
• Testing as per the specified requirements has already been executed. 
• The application is too critical to be left like this. 
• A novice tester steps in and is required to hone his knowledge and skills by testing this application. 
• If the current project happens to be a pretty huge and outdated one, then the chances of incorporating all the features and fulfilling the older requirements are very unlikely. 
• In some projects, engineers are hired in the mid of the project and thus they do not get sufficient time to understand the requirement. 

A build refers to the file that a tester receives and is bound to test for functionality with some previously-done bug fixes. It is an executable file that can be dropped by the entire team of testers if it fails to satisfy the checklist consisting of the crucial functionalities of that application or software. When it comes to testing, you can expect multiple builds to be there.

A release, on the other hand, is the final product that has cleared all the tests and has been duly passed to the clientele. It is an amalgamation of multiple builds. Hence, the two of them are very different from each other.

Acceptance testing is an end to end testing done by the end user in which they use the software for real time business for a certain period and check whether the software is able to handle all the real time business scenarios and situations.  

 In service based companies we call this user acceptance testing 

The purpose of doing user acceptance testing is as follows: 

1. To create confidence in the software 
2. To ensure that the software meets the business requirements 
3. To ensure that developer has not created a wrong software 
4. To identify defects that have been overlooked by the company under business pressure 

In this manner, user acceptance testing can be executed on an application or software

Equivalence partitioning is a black-box design technique wherein the inputs are carefully divided into various data classes in the form of ranges. Here, the range of the inputs undergoes a sort of conditional formatting in which the tester expects all the other partitions to react in the same manner as the chosen one does during a test. For instance, if we are dealing with a financial application and we are supposed to find the interest rate for a particular bank balance, then we can identify bank balance ranges that earn an entirely different bank balance. Known by the name equivalence class partitioning, it is majorly performed to decrease the test case numbers after hitting the desired requirement.

Also known by the name 'random testing' or 'error guessing testing', the Ad hoc testing is a methodology that doesn't go by any pre-specified test or any pre-determined requirement. It is abrupt and unplanned in nature so any part of the application is randomly picked and checked for potential defects or risks. Since the testing itself is unplanned, naturally, the testers don't have any test cases for it. As a result, the defects found are difficult to reproduce. It is suitable for scenarios when testers cannot perform elaborative testing because of a scarcity of time. Generally, this type of testing is executed once a formal test has taken place. If a tester doesn't face a paucity of time, then Ad hoc testing can be executed on the system or the application alone. It is believed that Ad hoc testing is the most effective when the tester is well-versed with the nitty and gritty of the system under test. Ad hoc testing can be of various types: 

• Buddy Ad hoc testing 

Here, two buddies work with a mutual understanding towards identifying faults or defects in the system or the application in the same module. Usually, one person is from the development team and the other one is a tester. They both come together to perform buddy Ad hoc testing. This type of Ad hoc testing is helpful in the development of test cases as far as the testers are concerned. For developers, such test cases can be modified earlier. This type of Ad hoc testing takes place once the unit testing is successfully completed. 

• Pair Ad hoc testing 

Here, two testers from the testing team are assigned some modules for which they have to share a variety of ideas and ought to work on the same machines in order to spot defects and faults. In this type of Ad hoc testing, one of the testers manages the execution of the test while another one keeps a record of all the results, outcomes, and findings. The respective roles of these two could be of a scriber as well as a tester during testing. 

• Monkey Testing 

Also known by the name 'random testing', this methodology aims at testing the capabilities of an application or software with a random input value. The tester is supposed to generate a random value via an automated tool or something, then fetch an output and finally, analyze it to see the difference. 

In order to practice Ad hoc testing efficaciously, one can consider the following: 

• Proficient business knowledge. 

For Ad hoc testing to go well, the testers need to have proficiency in business models and strategies. This will make them understand the business requirements of the assigned project in a much better and more efficacious manner. In addition to that, detailed business knowledge will help the testers in discovering faults, defects, or errors quickly and easily. 

• Test the key business modules. 

The key business modules should be spotted, acknowledged, and targeted under the Ad hoc testing. Also, to strengthen confidence in the system quality, it is imperative to test all the business critical modules. 

• Record the important defects, faults, and errors. 

This is a rule, a non-negotiable one. All the defects, faults, and errors ought to be well-recorded or well-written in a notepad. The defects must be assigned to the developers so that they can be fixed at the earliest. For each of the valid defects, faults, and errors, the corresponding test cases are to be added to the list of planned test cases simultaneously. These should be a technical parable for the developers as well as the testers and hence, ought to be reflected in the right light during the planning test cases of the next system or the next application. 

In this manner, you can efficaciously execute Ad hoc testing. 

A performance testing type, stress testing is all about testing an application to such an extent that it will crash. It is done to see how much exertion an application or software can undergo. The exertion is usually in the form of a humungous data upload or too much user traffic. In addition to that, stress testing also sees how the application or the software plans to recover post-exertion when the data input or the user traffic is reduced. Tools like JMeter and LoadRunner are put to use by testers in order to execute stress testing. Stress testing can be branched into various types. These are: 

• Application Stress Testing 

This particular type of stress testing focuses on finding out defects, errors, and faults concerning blocking, data locking, network reception as well as performance bottlenecks in software or an application. 

• Exploratory Stress Testing 

The exploratory stress testing is executed when unforeseeable or hypothetical scenarios intervene with the real-life working of a software or an application. Herein, defects, errors, and faults are found in scenarios like a mammoth number of users logging in at the very same time, some database that has shifted offline despite the website being publicly accessible, a virus scanner that has kickstarted a considerable number of machines and that too together or when an already-gigantic database is inserted with more data. 

• Systemic Stress Testing 

Systemic stress testing happens on more than one system that is on the same server. It is the perfect technique for finding out defects in case one application's data tends to block another application's data. 

• Transactional Stress Testing 

This sort of stress testing is made to be executed between the transactions of two or more two applications. It is ideal for optimization as well as for fine-tuning. 

To practice stress testing efficaciously, testers can follow the following steps: 

• Plan out the stress test. 

Here, the tester carefully gathers some application or system data in order to analyze the application or the system. Then, the tester is able to determine the goals for this stress testing session. 

• Creation of automation scripts. 

Here, you ought to create some stress-testing automation scripts. Using these very automation scripts, data for the test is generated keeping in mind the stress scenarios. 

• Executing the script. 

In this step, the focus of the tester is to run the previously-created stress-testing automation scripts. The fetched test results are stored. 

• Analyzing the results. 

The next step is to analyze the stored results. After analyzing the results obtained from stress testing, testers focus on identifying potential bottlenecks, defects, errors, or faults. 

• Fine-tuning and optimizing. 

Last but not the least, a tester focuses on fine-tuning and optimizing the application or the system. Herein, the tester is allowed to modify the configurations as well as optimize the previously-entered code. All this is done to seek validation of whether the motive of stress testing has been achieved or not. 

The entire process is executed again just to make sure that the spotted tweaks have managed to achieve the desired outcome. Usually, testers perform 3 to 4 cycles of stress testing in order to execute it efficaciously, letting the application or the system cash in as much benefit as it can from the testing process. 

It's no surprise that this one pops up often in functional test planning interview questions Interview Questions. Load testing takes place when an application is made to bear numerous exertion levels to come upon the result of obtaining the server throughput of the application, its peak performance, the run-time, etc. Best of all, load testing determines the application's integrity, performance as well as stability in such scenarios when the workload exceeds all bounds. This testing technique comes with myriads of benefits: 

• Load testing is popular in the team of testers since it helps in the quick discovery of bottlenecks before actual deployment takes place. Herein, evaluating any random piece of the website, the application, or the software before deployment can be pretty helpful in highlighting the bottlenecks, allowing them to be addressed before they incur large real-world costs. 
• Without load testing, it would have been difficult to enhance the system's scalability. With scalability, we mean the limit of the operating capacity of software or an application. So, as the system tends to scale upward, the infrastructure needs can be well-determined and well-addressed. 
• Load testing helps reduce the system downtime and hence the failure cost. Usually, a system or an application faces various scenarios that can culminate in a system failure. Since load testing prevents that, it becomes an effective tool for discovering solutions to the problems of high-traffic much before they emerge in the real world. Also, identifying concerns at the initial stages (obviously before the launch of the final product) can help in curbing exorbitant failure costs. On the other hand, failures discovered post-launch are difficult to compensate for. 
• Last but not the least, load testing helps in garnering improved customer satisfaction. If a website's response times are short even as it scales up to a higher audience, one-time customers will be more apt to revisit. Hence, the better the service, the more satisfaction. 

The best tool and software are not all that it takes for a tester to perform favorable load testing of the concerned software or application. What a tester needs is the most knowledge and efficacious of the best practices as far as load testing is concerned. Here are a few tried and tested practices for effective load testing: 

• Analyze the business requirements of the project. 

Believe it or not, most of the testers forget to pay heed to the business requirements of the project. This can be efficaciously done via the identification and development of numerous test scenarios. These test scenarios are based on documents such as the Business Requirements Document(BRD), the business use cases, the project charter, the process flow diagrams as well as the system requirements specification (SRS). 

• Determining the key fulcrum points of an application and its peaked-up web performance. 

A tester should determine the key measures for the application and its web performance. The entire team of testers should agree on the criteria to track that majorly include business performance metrics, maximum user load, resource utilization, response times, and throughput. 

• Choose a suitable load testing tool or tools. 

Select a tool that best caters to your needs. Some tools include but are not limited to WebLOAD, Load View, and LoadRunner. JMeter could also be used for this. 

• Creating a test case. 

Writing test cases is of paramount importance when it comes to functional testing. Here, the use of both - writing skills, as well as in-depth software testing skills, is required. The language used for writing the test cases should be lucid. In writing a test case, make sure both positive and negative scenarios are considered. Test cases must be accurate and capable of being traced to requirements. Apart from that, there should be a clear understanding of what the client needs to have on the screen. No assumptions should be made by the tester. Each doubt should be cleared. The input data should hold some value and should come with a wide scope. The test cases should feature any and every requirement. Nothing should be missed and nothing should be skipped. In order to do this, testers keep a traceability matrix for every requirement (especially the functional and the non-functional ones such as compatibility, UI, etc.) and record the progress made. On top of that, testers should not refrain from test cases. Apart from keeping redundancy at bay, high-priority cases should be taken into account first, followed by the medium-priority test cases and then the low-priority ones. Focusing on the release, quality-based test cases can be made so that it becomes seamless for the developer and the tester to analyze the project. 

• Understanding the test ambiance or environment. 

Consider different types of deployments you might want to test. Create configurations like typical production. Test different system capacities like security, hardware, software, and networks. 

• Run tests at an incredulous level. 

During these tests, the system will ultimately fail. One key goal is determining what volume results in failure, and spotlighting what fails first. 

• Always keep the potential end-users in mind. 

The satisfaction of customers and site visitors is crucial to the achievement of business metrics. This plays into their willingness to revisit a site or re-access an application. 

Severity, also known as the defect severity of an application is determined by the indelible defect impact left on it during a particular test. Usually, the severity and the impact are directly proportional to each other. Defect severity can be categorized into four different categories namely critical, major, medium, and low.

On the other hand, priority, also known as the defect priority of an application tells the tester the order in which the spotted defects are to be resolved.  Usually, the priority and the resolving time are indirectly proportional to each other. This means higher the defect priority, the sooner the defect must be resolved. Defect priority can be categorized into three different categories namely high, medium, and low.

Sanity testing is a subset of regression testing and acceptance testing. Whenever the build is deployed into the testing server or production server, sanity check is done to ascertain the stability of the build and the environment.

RTM is a document that ensures that each requirement has at least one test case 

 There are 2 types of RTM: 

1. Forward Traceability Matrix-In this matrix, we map requirements to the test case. This is prepared before executing the test case. 
2. Reverse Traceability Matrix- In this matrix the test case is mapped after the execution. 

With risk-based testing, testers need to make an application risk-free with the help of lucrative risk-managing practices or techniques. So, factors that should be considered by a tester before undertaking it include: 

• To identify the scenario where risk-based testing is required and how. 
• To opt for techniques and practices that help in identifying risky situations best. 
• To land upon an output that is both risk-free as well as feature-enrichening. 

This analysis is used for checking the boundary values that are mentioned in an equivalence class partition. The analysis is put to use in order to spot the errors or the defects near the boundaries and hence, divert from looking at the values in the range. For instance, if an input field can take in at least eight characters and at max 12 characters, then the stipulated valid range will be 8 to 12. Herein, less than seven characters and more than 13 characters will be the stipulate invalid range. Henceforth, the defects or errors will be spotted for the exact boundary value as well as the valid and the invalid partition values.

A smoke test is usually executed when an application's build is received. Under smoke testing, testers are expected to look out for critical paths without which an application might get crashed or gets blocked. However, no emphasis is to be laid on the functionality as such since that particular build can be accepted or dropped in case of a crashed application.

A staple in functional testing interview questions for 3 years of experience, be prepared to answer this one. Bug refers to spam, unwanted error, mistake, or a flaw occurring within the software hindering its output delivery. From the time a bug or defect is spotted till the time it is resolved properly, a bug is said to undergo various stages and processes within the realm of the application. This is termed the 'bug cycle' or the 'bug lifecycle'.

Sometimes, even after knowing the bugs, software or an application is launched. This is because these known bugs have a low defect priority or defect severity. Another thing that can happen after the software is released is a bug leakage. This happens when a customer can identify a bug and not the testing team.

When a bug is spotted, it is first logged in via a bug-tracking tool that has a specified format. The developer then gets these bugs and toggles their status as 'open'. Now, they can be reviewed, reproduced, and worked upon till it is completely eradicated. Later on, debugging is done either with the help of backtracking, as a brute force, a cause elimination, via fault tree analysis, or by slicing of the program. Once fixed, the status is toggled back to 'fixed'. If not, then labels such as 'can't be fixed' or 'cannot reproduce' are used. Then, it is the Quality Audit or QA manager that executes regression implying the verification of the bugs with more actions.

Regression testing, also known as generic testing, is all about checking if an application misbehaves after the incorporation of a new feature. On a whole, the novel functionality shouldn't mess up with the normal working of the application. Retesting, also called planned testing, is testing after successfully completing the test cases that had failed during their last execution. On a whole, verification of defects is carried out here. Keeping in mind the project, regression testing can be simultaneously carried out with retesting. However, retesting can only be performed before the regression when it's a high-priority case. Regression is done only for the tests that have got successfully completed whereas retesting is for failed tests. Regression testing can be carried out via automation since manual testing can consume too much time and money. However, automation cannot be carried out for retesting.

A test strategy is a guide designed by the project manager on how to conduct a test. It incorporates the scope of the tests, a brief of the to-be-tested features, the testing processes that are to be carried out, the modules that are to be tested, the format of documentation that is supposed to be used, a comprehensive order of reporting, the communication strategy designed for the clientele, etc. A test strategy narrates the approaches that are to be undertaken during a project and hence, are not susceptible to any changes later. In projects that are small-scale, a test strategy is covered in the test plan.

When it comes to coverage, testers put to use three different methodologies or techniques. These include: 

• Decision coverage technique 

Under this coverage technique, it is assumed that each decision made in the form of 'true' or 'false' gets a mention in the source code, gets executed, and finally, tested. 

• Path coverage technique 

As per the path coverage technique, the tester is bound to make sure that each of the critical paths or routes is thoroughly examined, executed, and finally, tested. 

• Statement coverage technique 

The statement coverage technique involves executing every line of the source codes and later, testing it successfully. 

Automation testing is performed because it is a lucrative technique. It lets the testers consume time by devoting less attention to the execution part by simultaneously running a lot of tests. It keeps redundancy at bay and so repeated tests are executed in a jiffy. When it comes to testing large test matrixes, nothing can be as helpful as the automation testing technique.

It is a concise summary of all the tests conducted so far during the Software Development Life Cycle or SDLC. A test closure comes with a comprehensive analysis of the spotted bugs, how they were removed, and later, the errors found by the tester. Moreover, this summary lists the total number of experiments conducted so far, how many of them have been executed so far, how many imperfections have been identified, the unsettled number of bugs as well as the bugs that have got rejected because they can't be fixed.

Test deliverables are the technical term for the amalgamation of components, documents, the techniques carried out, and the tools used to execute a test. A test deliverable can be produced at numerous stages or phases of a Software Development Life Cycle or SDLC. Basically, a tester expects the production at three key fulcrum stages that are before the software testing takes place, during the software testing, and once the software testing is successfully completed.

An 'entry criteria' is a set of parameters, standards, or prerequisites based on the test data, the test environment as well as the test tools or techniques that are to be met to kickstart software testing. These parameters, standards, or conditions describe the mutually-agreed novel features or functionalities that should be incorporated to get the best head start on the tests listed for a project. A solid' entry criteria' marks a smooth and early execution of each of the tests.

Use case testing is a popular methodology or technique enabling the testers to test how a particular piece's functionality kickstarts in software. It gives an idea of whether the software is meeting the laid-out objectives or not. On the other hand, A/B testing involves testing different versions of the same software with the potential user base to figure out which version is the most efficacious one. The potential user base is asked to lay their hands on a particular part of the software called A, another part called B, and then try using both. On the basis of their response and statistical analysis, it is determined which feature is better.

On a whole, A/B testing is a better method because it lets the testers test both the existing and the novel functionality variations.

Configuration testing is carried out by evaluating what are the configurational needs or requirements of a particular software. It is through configuration testing that testers can land upon the optimal configuration at which the application or the software attains its peak performance. In addition to that, testers are able to resolve compatibility issues, if there are any in the application or the software.

In order to determine the level of any risks associated with or the emergence of any potential dangers, it is important to be prepared for facing an adverse software issue or event. The indelible impact of this very event helps in determining the risks or potential dangers associated with a particular project.

Most testers still believe that manual testing is better and more efficacious than automated testing and this is the reason why they still carry it out while testing a project. Also, the analysis of a software or application from a user's point of view is best done via manual testing since visual accessibility, GUI testing which is responsible for testing the interface between the potential userbase, as well as the software, and other related preferences, are difficult to test with the help of automated testing. It is a well-known fact that testers who have just entered the domain of software testing find it easy to perform manual testing. Also, manual testing is apt for projects that have to be submitted in a short duration, and when test script redundancy and reusability are to be put at bay. For the initial stages of a project, testing is the best with the help of manual testing.

A test plan is an outline of the project or the software and the concerned details such as its scope, the resources at hand, the strategies that will be carried out as well as a tentative timeline for the activities that are to be conducted. To kickstart software testing, it is mandatory to make a test plan. As per tech experts, the success of software testing largely depends on the test plan made in the beginning. Initially, a test plan comprises very few details but with time, it is made more and more comprehensive.

In addition to that, a test plan often expounds on how the testing will be carried out by giving a gist of the specifications and the salient features that will lay out the scope of the project. It clearly traces out how a particular stage or phase of the project is to be started and ended. A contingency timeline is also set. On top of that, the methods and techniques that will help in carrying out the testing will be stated.

A test plan is required during functional testing because it lays out the timeline of testing by telling the tester where to begin and where he is supposed to stop. And since every task is well-expounded there, this is the reason why many testers also refer to a software test plan as a prototype. It is a software plan that tells us about the resources required to successfully complete testing as well as the time undertaken for the same.

While testing, there is a possibility of missing out on a minor step that can turn catastrophic for the entire testing process. In such times, a test plan acts as a guide that has rules laid out for each and every stage or phase, so that you don't miss out on anything. On top of that, it acts as a lucrative identifier of the loopholes, the challenges that are to be overcome, and how to address them with insightful solutions. Best of all, it is through a test plan that the entire team of testers gets to have a say in the project.

Test plans can be categorized into three categories. These include: 

• Master Test Plan 

Starting from planning out the test to managing the various stages or phases, this lays out each detail in a comprehensive manner. It provides a bigger picture of how the features are to be tested and what the associated timeline is to carry out the testing for each of the features in a lucid, list form. A connectivity is established between all the tests that are to be carried out during the course of the project. 

• Test Phase Plan 

All the testing plans mentioned in the master test plan are elaborated here. The test phase plan comes with the templates that are to be used, the quality benchmarks that are to be met, and the schedule for all the tests amidst other information that is not mentioned in the master test plan. 

• Specific Test Plans 

Security and other performance-related tests are mentioned under the specific test plan. With performance, a tester implies performance testing of the software which aims to determine how it functions and responds under stress or load. With security, the tester implies software testing that brings out how well-guarded or well-protected a system is against potential intrusions and threats. 

A test plan generally includes a myriad of components, however, six of them stand out to be the major ones. These include: 

• Resource Allocation 

As the name suggests, it allocates testers to the test. 

• Training Needs 

The training needs to encompass the requisite skills for carrying out the plethora of tests and associated tasks. This is clearly specified by the test planner and all those who are on the team of testers must comply with it. Hence, it is mandatory for them to meet the laid-out training needs. 

• Scheduling 

While testing, one of the most important things is to keep a record of the time each of the tests is taken. This is where scheduling comes into the picture. It helps in establishing as well as maintaining such records. 

• Tools 

These include the catalysts required to carry out the various stages or phases of functional testing. 

• Risk Management 

It explains the risks associated with the various stages or phases of testing. In addition to that, it lays out the problems the software will pose to potential users if introduced without proper testing. This problem gets materialized when there is a paucity of human resources or when there is an absence of a requisite test environment or ambiance. In addition to that, a low budget can also pave the way to project failure because of poor risk management. 

• Approach 

This section of the test plan talks about the handful of tips and cautions that are to be exercised while carrying out the variety of tests. 

Well, a test plan is all about its components. These components altogether force us to identify the loopholes in the testing process and overcome them with lucrative solutions. It is these components that lay the foundation of a communication channel in a team of testers as well as other concerned stakeholders. For an organizational-level testing process to get completed successfully, it is important that the test plan outlines each and everything in detail including the scope of the test, resources required, constraints, policies, and strategies.

With a test plan, the testers can easily adapt to the changes occurring in the course of the project. Augmentations and changes can be done seamlessly in a test plan with the help of its components. Strategies can be revised to achieve milestones, progress and durations can be recorded at each stage or phase of the project, and desired outcomes can be obtained.

Writing an efficacious test plan is not rocket science, just follow the steps given below: 

• Give a title to your test plan. 

First things, first. Give a name to your test plan, add the name of the Quality Audit or QA provider along with their logo, mention the version number, and the year it was formed. 

• Introduction, please. 

Describe the project plan in this part of the test plan. Do not forget to jot it down in a note-like format. 

• List down the test items. 

Every item that is to be tested features in the test items. In addition to that, it includes details such as registration, installation, and checkout and, thus provides a summary of the test plan. The more the objectives of the project, the longer your list will be. 

• Tested features. 

Describe in detail the features of the test plan. The should be in sync with the framed timeline. 

• Carry out approach. 

In this section, the approach toward testing is laid out. How the various testing stages or phases will be cleared, which methods will be used and the resources that will be employed are mentioned in detail here. 

• Trace out the test deliverables. 

Test deliverables are the outcomes of the test that are undertaken. These are sent to the client in the form of metrics. They are apt indicators of the progress attained so far. 

• Training needs. 

Not every project is based on a subject that is lucid for the testers. Sometimes, they can do it with some training. This aspect is covered in the test plan under the section on training needs. Herein, lectures from experts are rendered to the team of testers so that they can get well-acquainted with the topic they will be working on and can work efficaciously. 

• Make a schedule. 

It's next to impossible to be productive without setting a timeline. Deadlines are important and should be laid out clearly for each stage or phase. In a schedule, testers are asked to specify the speed they are expected to progress with and the order in which they will be undertaking the tests. 

• Risk management 

Without identifying the potential threats or faults, it is not advisable to proceed. Hence, the last step is to lay out the challenges that you will be facing and how to deal with them. While resolving threats is pretty seamless, faults require extra attention since these are failures erupting from a function that was getting executed by software. 

Almost all the components of a test plan are susceptible to changes. This can be cumbersome if the tester gets way too comfortable with the current strategy or plan of a phase or stage. Hence, to make sure that the team of testers gracefully accepts the change, it is important to amend only the schedule part of a test plan and that too carefully. A test lead should always keep in mind that the changes should be made in such a manner that it doesn't require the creation of a brand-novel test plan.

A test plan is an outline of the project or the software and the concerned details such as its scope, the resources at hand, the strategies that will be carried out as well as a tentative timeline for the activities that are to be conducted. On the other hand, a test case is the input obtained on which a particular project is getting tested.

A test strategy is a set of rules that help in regulating the process of software testing. It is majorly done to get hands-on an approach which is both feasible and systematic for the concerned project as per the traceability and quality standards.

A test harness is used to check how an application or software is performing under conditions that keep on changing such as in terms of getting too data-driven or becoming too stressful. A test harness is an amalgamation of tools and information associated with the project that also helps in handling the behavioral aspects of the software along with output generation.

The ISO/IEC/IEEE 29119-3 stands out to be the international standard for documenting a test plan in functional testing. Not only that, but it also turns out to be the international standard for test procedures as well as test cases. The international standard comprises rules and regulations for both - agile and conventional test planning along with requisite illustrations for each of the stages or phases of the test plan. The template use can be inspired by an acclaimed software testing process or a famed publication.

There are a set of rules and principles that are to be followed for any and every API test design. These include: 

• Setting up everything. 

Herein, the objects are to be created for the API test design. The services that are required are applications and the data inputs are to be initialized. 

• Here goes execution. 

The logging is to be done under execution. The tester is required to apply the concerned scenario of the API. 

• Verifying and validating. 

The result fetched after the execution undergoes a deep evaluation, verification, and validation here. 

• Final report. 

Herein, the final status is displayed in the form of 'failed', 'passed', or 'blocked' messages. 

• Clean up 

This encompasses the state that exists pre-test. 

An 'exit criteria' is a set of parameters, standards, or conditions that are to be met in software testing. These parameters, standards, or conditions describe the mutually-agreed novel features or functionalities that should be incorporated to successfully complete the tests listed for a project. A strong 'exit criteria' marks a smooth and early exit from software testing and allows the testers to hand over the release sooner to the clientele.

No. We know that testing is done once the test input data is obtained, the specified requirement list is fulfilled, and the test environment is set. So, system testing cannot be done as per one's own whims and fancies at any random stage or phase. It can only be conducted when everything is set in place.

The software testing term - Alpha is conducted by both the developers of the software and the testers. Many times, Alpha is conducted by the one who purchases the software or application, or by the team of people who do outsourcing without any aid from the software developers or the testers.

The software testing term - Beta is conducted by a set of users before the actual release of the application or the software. Beta testing is usually conducted with the help of end-user testing.

The software testing term - Gamma is done to check the last-minute details just before the final release. It is conducted by the ultimate user on his device. Before performing Gamma testing, all the firsthand in-house tests are omitted.

Defect triage is a methodology by which prioritization of defects takes place based on the amount of time it will consume to fix it, the risk associated, and the defect severity. It is through a defect triage meet-up that various stakeholders associated with the concerned project such as the development team, project manager, testing team etc. come together.

A defect that goes undetected despite being present all the time is known as a latent defect. It goes undetected majorly because of the conditions wherein it was impossible to find the defect. On the other hand, masked defects are the ones that are concealing their visibility. They come into the picture when a trigger event takes place in the software or the application.

The test-driven development or TDD is a methodology used for software development with the help of test cases created for the purpose of implementing functionality. The test cases are written in the TDD method.

A stub is a dummy model made for the purpose of emulating the module behavior by fetching a result that is either hard-coded or is pretty predictable given the input values. Stubs come in handy during a top-down integration technique because herein only when the testing and integration of the top-level modules is done, and then only the tester can move to the lower-level modules.

This question is a regular feature in functional testing interview questions for experienced, be ready to tackle it. A bug report consists of the fact-findings, the observations as well as other information that might be useful for the developer in resolving bugs. Such a report helps in understanding the problem from the grass root level, the test environment that gave birth to the bug as well as is instrumental in finding out a lucrative solution. 

Before a bug is resolved, it is given a status. Some of the most popular bug statuses of all time are: 

• Assigned 

Once the tester has spotted a bug, it is logged in, reviewed, and then assigned to one of the stakeholders of the project. Generally, a test lead gets to review an assigned bug and post-review it is assigned to the developer team. 

• Cannot Reproduce 

This status is given to a bug when it cannot undergo reproduction on its own even after abiding by the steps that have been described by a tester in the reported issue. 

• Deferred 

A bug status for a low-priority bug that cannot be fixed because of a paucity of time. Till the next release, the bug is said to be 'deferred'. 

• Invalid or Not a bug 

There can be times when although the reported issue of a tester is in compliance with the functionality but is a misinterpretation. In such a case, the reported bug is marked as 'invalid' or 'not a bug'. 

• New 

A newly-detected or newly-logged-in bug is labeled as 'new'. 

• Open 

The team of developers might wish to work on a bug for a while. In order to make sure that they can execute whatever they wish to on the bug, the bug is marked as 'open' and remains in the same state till the work is completed. 

• Reopen 

Even after a bug has reproduced and continues to exist despite all the initiatives taken to resolve it, it is labeled as 'reopen'. 

• Resolved or Fixed 

Once a bug is resolved or fixed by the developer and the application is working just fine by producing the required output in the case of an issue, the status of the bug is changed to 'resolved or fixed'. 

• Verified or Closed 

A bug that has been labeled as 'resolved or fixed' is now tested by the tester. Once it successfully completes the test, the bug is now labeled as 'verified or closed'. 

Configuration management is a technique that is not only cost-effective but helps in saving time on a whole for the organization. It is carried out with the purpose of using various engineering methods or techniques to enhance various features of a product such as its design, functional setting, performance, or operational information.

When a bug starts affecting the functionality of a particular part of the software or the application, it is said to be critical in nature. A critical bug is an indicator of a grave mishap wherein because of a misbehaving functionality, the entire system gets crashed or breaks without any workload left to proceed further.

A defect report consists of a variety of components. These include the test on which the defect is detected, the defect ID, the name of the defect, the name of the module, the name of the project, a legible screenshot of the defect as well as its defect priority and defect severity status, and lastly, who has resolved the defect and when.

DRE, an abbreviation for 'Defect Removal Efficiency' stands out to be a significant methodology here. This technique is used for testing the efficacy and productivity of the developer team in resolving issues and errors spotted in an application or software. The  'Defect Removal Efficiency'  is an apt ratio measure of a defect's number to the total number of issues or defects detected so far. For instance, if the tester has discovered about 80 issues or errors out of which about 60 have been resolved, then the DRE would be 80:60 = 1.3%.

No, a test matrix and a traceability matrix are different from each other. A test matrix is used to gauge the amount of time invested, the efforts put in, the plan implemented as well as the quality during the various stages or phases of software testing. On the other hand, a traceability matrix is a mapped relationship between the laid-out customer requirements and the written test cases.

Expect to come across this popular question in functional testing interview questions for experienced. Positive testing involves entering a valid input value and obtaining a response in the form of an action that meets the expectations of the tester. It includes the end-user-based tests (also called the system tests), the decision-based tests as well as the alternate flow tests. 

• End-user based/System Tests 

Herein, the system under test comprises of the components that when coupled together tend to achieve the user scenario. Let's say a customer scenario would include tasks like entering the correct credentials, going to the home page, and HRMS application loading, performing some actions, and logging out of the system. This particular flow has to work without any errors for a basic business scenario. 

• Decision-based Tests 

Decision-based tests are centered around the ideology of the possible outcomes of the system when a particular condition is met. In the above scenario given, the following decision-based tests can be immediately derived If the wrong credentials are entered, it should indicate that to the user and reload the login page. If the user enters the correct credentials, it should take the user to the next UI. If the user enters the correct credentials but wishes to cancel the login, then it should not take the user to the next UI and reload the login page. 

• Alternate Flow Tests 

Alternate path tests are run to validate all the possible ways that exist, other than the main flow to accomplish a function. 

Negative testing, on the other hand, involves entering an invalid input value and carefully reading the displayed error messages. This includes equivalence tests, Boundary Value Analysis as well as Ad hoc tests. 

• Equivalence test 

Equivalence partitioning is a black-box testing technique wherein the inputs are carefully divided into various data classes in the form of ranges. Here, the range of the inputs undergoes a sort of conditional formatting in which the tester expects all the other partitions to react in the same manner as the chosen one does during a test. For instance, if we are dealing with a financial application and we are supposed to find the interest rate for a particular bank balance, then we can identify bank balance ranges that earn an entirely different bank balance. Known by the name equivalence class partitioning, it is majorly performed to decrease the test case numbers after hitting the desired requirement. 

• Boundary Value Analysis 

This analysis is used for checking the boundary values that are mentioned in an equivalence class partition. The analysis is put to use in order to spot the errors or the defects near the boundaries and hence, divert from looking at the values in the range. For instance, if an input field can take in at least eight characters and at max 12 characters, then the stipulated valid range will be 8 to 12. Herein, less than seven characters and more than 13 characters will be the stipulate invalid range. Henceforth, the defects or errors will be spotted for the exact boundary value as well as the valid and the invalid partition values. 

• Ad hoc test 

Also known by the name 'random testing' or 'error guessing testing', the Ad hoc testing is a methodology that doesn't go by any pre-specified test or any pre-determined requirement. It is abrupt and unplanned in nature so any part of the application is randomly picked and checked for potential defects or risks. Since the testing itself is unplanned, naturally, the testers don't have any test cases for it. As a result, the defects found are pretty difficult to reproduce. It is suitable for scenarios when testers cannot perform elaborative testing because of a scarcity of time. Generally, this type of testing is executed once a formal test has taken place. If a tester doesn't face a paucity of time, then Ad hoc testing can be executed on the system or the application alone. It is believed that Ad hoc testing is the most effective when the tester is well-versed in the nitty and gritty of the system under test. Ad hoc testing can be of various types: 

• Buddy Ad hoc testing 

Here, two buddies work with a mutual understanding toward identifying faults or defects in the system or the application in the same module. Usually, one person is from the development team and the other one is a tester. They both come together to perform buddy Ad hoc testing. This type of Ad hoc testing is helpful in the development of test cases as far as the testers are concerned. For developers, such test cases can be modified earlier. This type of Ad hoc testing takes place once the unit testing is successfully completed. 

• Pair Ad hoc testing 

Here, two testers from the testing team are assigned some modules for which they have to share a variety of ideas and ought to work on the same machines in order to spot defects and faults. In this type of Ad hoc testing, one of the testers manages the execution of the test while another one keeps a record of all the results, outcomes, and findings. The respective roles of these two could be of a scriber as well as a tester during testing. 

• Monkey Testing 

Also known by the name 'random testing', this methodology aims at testing the capabilities of an application or software with a random input value. The tester is supposed to generate a random value via an automated tool or something, then fetch an output and finally, analyze it to see the difference. 

Defect cascading is efficaciously used to trigger associated defects in an application or software when one of them gets visible to the tester during testing. Defect cascading invokes other defects in prior so that they don't crop up later. However, this technique can mess up with the existing or the new features incorporated in the application or the software making it difficult to spot the associated defects. Testers are often compelled to take more and more tests to resolve issues erupting because of defect cascading.

Usually, test levels are of four different types. These are enlisted below: 

• Integration testing level 

This testing level incorporates software modules that can be logically integrated and can be tested as a single group. It signifies a bunch of modules that can undergo integration and testing altogether. The top-down integration technique is a feature of this level. Herein only when the testing and integration of the top-level modules is done, then only the tester can move to the lower-level modules. For instance, the big bang integration testing technique is used to check the system components side-by-side in one go. This means that the tester gets to check every component in one go. 

• Component testing, module testing, program testing, or unit testing level 

A component testing, module testing, program testing, or unit testing level involves testing each component and module mentioned. It uses a dummy model made for the purpose of emulating the module behavior by fetching a result that is either hard-coded or is predictable given the input values. These dummy models are called 'stubs'. 

• System testing level 

A system testing level determines the execution of fully integrated products and validates the test completion. This type of testing cannot be done as per one's own whims and fancies at any random stage or phase. It can only be conducted when everything is set in place. 

• User Acceptance testing level or the UAT level 

Also known by the term' end-user testing', user acceptance testing or UAT is a type of testing done once all the development-based tests have been cracked successfully. Herein, the clientele or the potential user base put the application to use before producing or releasing it and see if everything is working just fine or not. The testing has to meet the requirements laid out by the clientele and should satiate the needs of the potential user base. 

Also known by the name 'random testing', this methodology aims at testing the capabilities of an application or software with a random input value. The tester is supposed to generate a random value via an automated tool or something, then fetch an output and finally, analyze it to see the difference. Testers performing functional testing are inclined towards monkey testing because it comes with a plethora of advantages. The advantages of monkey testing include: 

• It helps in an easy and quick identification of defects, errors and faults that are out of the box. 
• Monkey tester is seamless to set-up and hassle-free to execute. 
• Even in the presence of poor-quality or unskilled resources, monkey testing can be performed effortlessly. 
• It is a wonderful and efficacious technique to see if the application or the software is reliable or not. 
• Monkey testing is popular for the identification of bugs that may leave an indelible impact on the application or the software i.e. bugs with high defect priority as well as high defect severity. 
• This technique is economical in nature as compared to other expensive tools and techniques used for functional testing. 

Despite having so many advantages, monkey testing comes with some drawbacks. These are: 

• Until and unless the tester stumbles upon a bug, monkey testing will go on and on. It's execution won't stop. 
• Frankly speaking, the number of bugs discovered is pretty less. 
• Even when the bugs are found, their reproductions become a daunting task for the tester. 
• Monkey testing might yield 'not expected' for some test scenarios thus eating up too much time for the testing team. 

On a whole, it is a great technique that testers have been using since its very inception. 

To collect information related to the performance of an application or software, testers perform baseline testing. The information obtained from baseline testing is used to aggravate the performance results of the project further by augmenting the previous setting. Baseline testing is conducted to garner the difference between the current performance of an application or software as well as its previous performance.

For a testing process to be conducted smoothly, some catalysts are required in the form of hardware, software, and other miscellaneous test items. These are known as testbeds. The testbed of a manual software testing technique also comes in the form of tools and techniques. With their association with a project, they help in controlling and monitoring various testing processes. In addition to that, they also offer ways to initiate certain performance tests. Some of the popular testbeds include databases like MySQL or PostgreSQL, Perl frameworks of Joomla and WordPress types, programming languages such as PHP, and to name a few.

Agile testing helps a test in evaluating the software from a potential user's point of view with the help of constant customer engagement. It is important because it doesn't require the developers to complete the coding to kickstart the process of the Quality Audit or QA. Herein, the coding, as well as the testing, take place simultaneously and this is the reason why testers are more in favor of agile testing than any other technique.

The context-driven testing is all about the adoption of the approaches, the methodologies, or the practices that can be used for testing. These approaches, methodologies, or practices should be open to customization as per what the project requires currently.

No, a program cannot be tested thoroughly by any tester. This is because a program, many a time, has laid-out software specifications that are extremely subjective in nature. This makes them lead the tester and his testing processes to a variety of interpretations. On the other hand, many a time, the program we are talking about might be laced with umpteen input values and fetches the tester with umpteen output values for them with the help of umpteen path combinations. So, it is next to impossible to thoroughly test a program.

The purpose of conducting mutation testing is the validation of the usefulness of a database written in the form of a test case or displayed as test data. Mutation testing is conducted by making a deliberate addition of numerous code changes including bugs. Later, testers perform retesting with the help of the original database written in the form of the original test case or displayed as the original test data.

Yes. If the requirement is to be frozen, this means that the requirements that have been specified are not available or not accessible at the moment for a particular product. If this is the case, then the product can be tested on the basis of the assumptions made by the tester for that product and should be marked as a risk. This should also be informed to the delivery manager.

There is no such specified limit on the number of cases that can be executed in a day. Frankly speaking, a tester can initiate real-time manual testing as many times as possible. It largely depends on the size of the test case and how complex it turns out to be since some tests are successful in just a few steps while others, might take some time. On a general basis, about 35 to 45 simple test cases can be generated in a day. Test cases that are medium might be around 15 to 19. From the bunch of those which are pretty complex in nature, barely 5 to 7 cases are executed every day.