Explore topic-wise InterviewSolutions in .

Automation enables the avoidance of repetitive manual work, faster feedback, and a reduction of time spent RUNNING tests repeatedly. DESPITE this, automated testing cannot cover all test cases, so determining which test cases to automate is important.   

It can be difficult, however, to figure out which tests need to be automated since it is pretty much dependent on the functionality of the software product. Here are some of the parameters to select test cases for automated testing. 

• Different data set for the test case.
• Execution of a test case with a different browser.
• Execution of test cases in different environments.
• Execution of a test case with complex business logic.
• Execution of the test case with different users.
• Test case with a lot of data, etc.

Functional testing is a quality assurance procedure used to evaluate whether a software application or component conforms with its stated functional requirements. It is clear that functional testing is essential to BUILDING a top-quality software product. 

The purpose of functional testing interviews is to assess candidates' skill sets and DETERMINE whether they are suited for the position. Throughout this article, we've covered 30+ functional testing interview questions with answers, which will help you nail the interview. Hopefully, you FOUND the article informative and helpful. 

Useful Resources:

• Automation Testing Interview Questions
• API Testing Interview Questions
• Database Testing Interview Questions
• Performance Testing Interview Questions

The most likely scenario is that you NEED to conduct regression testing in order to cover parts of the product that MAY be impacted by any new UPDATES or product releases. The tester, in addition to testing the product's core features or functionality, should also list any AREAS that are affected by this function or prone to breaking due to high usage and complexity of coding.  

In order to get a fresh perspective on test coverage, test cycles should be scheduled over TWO or three days. When strategizing and writing test cases, testers should open the app so they can ensure they aren't overlooking a function or feature they would have missed otherwise.

Listed below are the possible scenarios you can use to test an application's login feature: 

• Input fields, such as username and password, should be validated both with valid and invalid values. 
• You can also try entering a valid email address with an incorrect/invalid password, as well as entering an invalid email address with a valid password. Verify that a proper error message APPEARS. 
• Get logged in to the application by entering valid credentials. Check if you are still logged in by CLOSING and reopening the browser. 
• Once the user has logged in, navigate again to the login page to see whether he or she needs to log in again. 
• If you are signed in through one browser, open the application through another browser to verify that you are signed in through the other browser. 
• You should CHANGE your password after logging into the application and then try to login again with the OLD password.

Here is an example of functional TEST cases:  

• The new task to be assigned:  Consider the case of assigning a new task to an appropriate user. 
• Description: Create a new task and assign it to an appropriate user.  
• Preconditions: When the user gets assigned, he/she should be ENABLED to receive email notifications.  
• Steps:
  • Create TWO separate user profiles, each with an email address.  
  • Create a new task using one of the accounts.  
  • Assign the task to your other user account.  
• EXPECTED result: The user should receive an email CONFIRMING that they are assigned a task. 

Having understood what functional test cases are, let's take a look at how they're written. Below is a list of points you should consider while writing test cases: 

• The first step is to have a broad overview of the testing project and determine what should be tested.  
• Now it’s time to write the test cases. Before writing test cases, it is important to understand the client's requirements clearly. According to the REQUIREMENT DOCUMENT specifications, every functional and nonfunctional requirement should be covered, from UI interfaces to compatibility. Normally, a traceability matrix is maintained to ensure that all requirements are implemented and tested.  
• It is a good IDEA to periodically check test cases to ensure that they are not redundant. 
• While writing a test case, priority is an important CONSIDERATION. In this way, the tester is able to begin testing the application with the high priority test cases, followed by the medium and then the low priority test cases.
• Test cases should be written in a simple LANGUAGE and in a structure that is easy to understand. For test cases, the input data values should be valid and within a wide range. 

Every feature/function of a piece of software should be tested thoroughly before it's released, and many of them should be continually tested. The functional test CASES are the documents written by QA managers for the purpose of conducting functional testing. Functional test cases inspect the software's functionality across a range of actions or CONDITIONS to ensure the desired outcome. Following are the features of a functional test case: 

• Name or description of the function/feature.  
• The preconditions for testing. 
• The STEPS needed to test. 
• The expected outcome/result.  

All of these provide the TESTER with everything they need to satisfy the test case requirements. It is also a good idea to write the location of the function in the description section, especially if the app is very large and complex, or if the same function is found in some different areas of the app. 

Automating functional tests can certainly save time and EFFORT. Testing can be done continuously without human intervention. Furthermore, human errors can be reduced, which prevents bugs from slipping through the test PHASE. It is especially useful during the development phase because it helps you find bugs and problems earlier, increasing your team's efficiency. As there are various automation tools available, it is essential to identify the right automation tool for the job. 

Now the QUESTION is how do you choose the right automation tool? The following points should be taken into account when choosing an automation tool. 

• All members of your QA team should be able to use the tool easily.   
• It must be able to operate in different ENVIRONMENTS seamlessly.  
• The tool should support the reusability of test cases in CASE the UI is changed. 
• Ensure that it has features specific to your team's needs. If, for instance, your testing team needs specific reporting or logging, or if it needs to use different scripting languages, then the tool must have these features as well.

BAT (Build Acceptance Testing), also known as BVT (Build Verification Testing), is a type of software testing intended to ENSURE the most important functions are working properly when new code is implemented. Based on the results of this testing, a software build can be CONSIDERED stable enough to continue for further testing. Basically, it's a set of tests that are run on each new build in order to verify that it conforms to the REQUIREMENTS of the build before sending it to the testing team for further examination. BAT processes are TYPICALLY automated. In the event BAT fails, then that build will be assigned to a developer for the fix once again. 

Advantages:

• Enhanced coverage and efficiency of testing.  
• Testers are less concerned with the possibility of unstable builds.  
• All builds are tested daily, so any major issues can be caught early.  
• Testing is automated, so there is no need for manual intervention.

Accessibility Testing refers to the process of testing the usability of a software application by ensuring that it can be accessed by people with all abilities and disabilities. The intent of this testing is to verify both the usability and the accessibility of the application. The accessibility of the application should allow for people with all types of disabilities INCLUDING: 

• Visual Impairments 
• Physical IMPAIRMENT 
• Hearing Impairment 
• Cognitive Impairment 
• Learning Impairment

In the present scenario, the web has acquired a major position in our lives with e-commerce sites, e-learning, e-payments, etc. Therefore, EVERYONE should be able to use technology to a greater degree, ESPECIALLY people with disabilities. Accessibility testing can be performed both manually and automatically. 

Defect Severity: This is the degree or extent to which a defect impacts the application being TESTED. The severity of the defect is a measure of its impact on the software's functionality. A defect with a higher severity level will have a greater impact on the application. Defect severity is classified into four categories: 

• Critical
• Major
• Medium
• Low

Defect PRIORITY: It is a parameter determining the order in which defects MUST be fixed. A high priority defect will more likely RESULT in an unusable or stuck application, and it should be corrected as soon as POSSIBLE. Defect priority is classified into three categories: 

• High
• Medium
• Low

Regression testing differs from re-testing in the following ways:  

Each tester should be responsible for understanding the client's requirements and ensuring that the output product is error-free. To accomplish this goal, the QA team must create test cases after thoroughly analyzing the requirements. As a result, the client's software requirements need to be divided further into different scenarios and finally into test cases. Each of these cases needs to be tested separately.  

Here is a question: how can one make sure that the requirement is tested in all possible scenarios? Are any requirements left out of the testing process? 

The simplest way is to trace the requirements to their corresponding test cases and scenarios and it is termed as ‘Requirement Traceability Matrix.’ Typically, the traceability matrix is a worksheet that contains the requirements and their associated test cases and scenarios as well as the CURRENT status of those tests, WHETHER they were SUCCESSFULLY executed or not. This will AID the testing team in understanding the extent to which testing has been done for the specific product. 

For example, The following is an example of different test cases that have different requirements to be tested. A matrix shows the requirements as columns on top and the test data as rows. The "X" here indicates which test cases relate to which requirements.

The Requirement Traceability Matrix, or RTM, is a TOOL that KEEPS track of REQUIREMENTS as a system or application progress through a testing process. As soon as the requirements document is received, the RTM is created and maintained until the system or application is released. RTM is used to ensure that all requirements in the requirements specification have been implemented before the RELEASE of the system.

• Smoke testing: This test only examines the basic functionality of a system to ensure the software works PROPERLY (or is not plagued with too many problems) so that the next test can proceed.
• SANITY testing: This type of testing is also known as a build-verification test and is usually performed after a smoke test. The testing is performed after a complete software build with minor changes is released to VERIFY that the code changes introduced continue to work as intended.

Smoke VS Sanity Testing: Learn More

A data-driven testing approach is a method of functional testing where a series of test scripts are executed repeatedly with the use of data sources like Excel, CSV FILES, Spreadsheets, XML files, and SQL databases. Data sources like these are USED as inputs for generating output. Next, the output is compared to what was expected to verify the system or software. 

A data-driven approach is preferable because testers often have multiple data sets for a single test, and it can be time-consuming to create individual tests for each data set. By using data-driven testing, data and test scripts can be separated, and the same test script can be RUN for different combinations of input data, resulting in efficient testing results. 

Example: Let's assume we want to test the login system with 100 different data sets and multiple input fields. We can have the below three approaches: 

• Approach 1: Write 100 scripts, one for each DATASET, and run each test individually.  
• Approach 2: Change the value in the script manually and run it SEVERAL times.  
• Approach 3: Import Excel data and pull test data one by one from Excel rows, and then run the script.  

The first two scenarios listed are arduous and time-consuming. As a result, it would be best to utilize the third approach (data-driven testing).

UFT (Unified Functional Testing), also known as QTP (QuickTest Professional), is an automated functional testing tool that helps testers to conduct automated tests to identify errors, defects, and other deviations from the expected behaviour of a software application.

• Specifically, it is used for functional, regression, and service testing.   
• This tool runs UI-based test cases and also automated non-UI test cases, such as DATABASE testing and file operations.  
• It is compatible with Windows platforms and multiple browsers like Firefox, Chrome, etc. 
• It supports a wide variety of software development environments, including SAP, Oracle, etc.  
• Also, it allows for Quality ASSURANCE checks to be run on the software being tested.  
• This tool provides easy navigation, validation of RESULTS, and REPORT generation. etc.

Functional testing differs from structural testing in the FOLLOWING ways: 

The boundary value analysis is a technique for testing the boundary value of an equivalence class partition. A boundary value analysis identifies errors at the boundaries, opposed to WITHIN ranges in equivalence partitioning.  

Example: Consider an input field in an application that can accept a minimum of 5 characters and a maximum of 10 characters. We were able to SPLIT our test CASES into three equivalence classes COMPOSED of invalid and VALID input. Then 5-10 is considered as valid and <4 and >10 is considered as invalid. 

Test cases for application input field accepting numbers between 5-10 using boundary value analysis: 

• The valid partition: Between values 5-10 (For this test case, we will use the same test data as the input boundaries of the input domain, namely values 5 and 10). 
• The first invalid partition: <5 (The test data value for this case will be just below the edge/boundary of the input domain, i.e., value 4). 
• The second invalid partition: >10 (The test data value for this case will be just above the edge/boundary of the input domain, i.e., value 11). 

Equivalence Partitioning is also CALLED Equivalence Class Partitioning (ECP) and is a form of black-box testing. In this method, input domain data is divided into equivalence classes (partitions) and test cases are derived using these classes of data. Then, while testing, one sample value is picked from each class. By using this method, test cases are generally reduced to a finite set of testable cases that still cover the maximum requirements. 

A technique of equivalence partitioning is APPLIED only when input data values can be divided into ranges. For each range PARTITION, only one condition will be tested, assuming that all other conditions within the same partition will behave similarly. 

Example: Let's say you have an input field that can accept only percentage values between 50 and 90%. In that case, it would be pointless to write THOUSANDS of test cases for 50-90 valid input numbers, plus others for INVALID data.  

The Equivalence Partitioning method outlined above can be used to divide test cases into three classes of input data. Each test case represents a class. As you can see, in the example provided above, we were able to split our test cases into three equivalence classes (can be more) composed of invalid and valid inputs. 

Test cases for input box accepting percentages between 50 and 90 using equivalence partitioning: 

• The valid partition: Between 50%-90% (The expectation is that the text field would handle all input percentages between 50%-90%, the same way).
• The first invalid partition: <=50% (We’d expect the text field to reject all values greater than or equal to 50%).
• The second invalid partition: >= 90% (We’d expect the text field to reject all values greater than or equal to 90%).