Explore topic-wise InterviewSolutions in .

• Stub: Stubs are created by software developers to be used in place of modules if the respective modules have not been constructed, are missing in the development stage, or are currently unavailable during Top-down testing. A stub is a module that mimics the functionality of an unavailable module. Stubs are used when lower-level modules are required but are currently unavailable. For instance, suppose you have three different modules: Login, Home, and User. Assume that the login module is ready for testing, but the two minor modules Home and User, which are invoked by the login module, are not. At this point, a piece of fake code is written to replicate the Home and User functions. The stubs are the dummy parts of the code.
• Driver: Drivers are similar to stubs in that they SERVE the same goal, but they are more complicated and are utilised in Bottom-up integration testing. Drivers are also used to operate in the absence of essential modules when some modules are absent and unavailable at the time of testing a specific module due to unforeseen circumstances. When high-level modules are missing, drivers are utilised. They can also be used when lower-level modules are missing.
  • Let's use the same example as before. Assume that the User and Home modules are ready to test this time, but the Login module is not. Because the Login module returns data to Home and User, a dummy piece of code is developed to emulate the Login.

The following table lists the DIFFERENCES between Stub and Driver:

A rigorous quality assurance strategy yields a software product that is both high-quality and error-free. However, quality assurance entails a lot more. Quality assurance is vital for many parts of the BUSINESS, including client interactions and the company's reputation in the market, in addition to finding flaws and places for improvement in a product.

Useful Resources:

Software Testing

Automation Testing

Defect triage is a method of prioritising bugs BASED on their SEVERITY, frequency, risk, and other factors. The term "triage" is used in software testing and quality assurance to describe the severity and IMPORTANCE of new faults. Bug triage's purpose is to review, prioritise, and assign defect solutions. The team must confirm the severity of the fault, make necessary changes, conclude defect resolution, and assign resources. This method is PRIMARILY utilised in agile project management. The frequency of the Defect Triage Meeting isn't SET in stone. It is dependent on the circumstances of the project. 

The following are some key elements that influence the frequency of Defect Triage Meetings:

• According to the project's schedule.
• The number of flaws in the system.
• The impact on the availability of team members' schedules.
• The state of the project as a whole.

• WHITE box testing: White box testing examines the inside structures of the software, including the employed data structures, internal design, code structure, and how it works, rather than just the functionality, as black-box testing does. It's also known as structural testing, clear box testing, or GLASS box testing.
• Black box testing: Black box testing is a sort of software testing when the software's internal functionality is unknown. The testing is carried out with no knowledge of the products' internal workings. The following methods can be used to conduct black-box testing:
  • Syntax Driven Testing: This method of testing is used on systems that may be represented syntactically by a language. Compilers, for example, are a type of language that can be described using a context-free grammar. The test cases are created in such a way that each grammatical RULE is applied at least once.
  • Equivalence partitioning: Many types of inputs work similarly, so rather than give them all separately, we can group them together and test only one of each group's inputs. The aim is to divide the system's input domain into a number of equivalence classes, each of which works in a similar fashion, i.e., if a test case in one class results in an error, other test cases in other classes will also result in an error.

The following table illustrates the DIFFERENCES between white box and black box  testing:

• Functional Testing: Functional testing is a sort of software testing that involves comparing the system to its functional requirements and specifications. Functional testing guarantees that the application meets all of the CRITERIA or standards as specified in the specification requirement sheet. This form of testing is focused on the end product of the processing. It focuses on simulating actual system utilisation but makes no assumptions about system structure.
• NonFunctional Testing: Non-functional testing is a sort of software testing that verifies the application's non-functional requirements. It determines whether the system's behaviour is in accordance with the requirements. It examines all aspects that aren't covered by functional testing.

The FOLLOWING table lists the differences between functional and non-functional testing:

• LOAD Testing: Load testing is a type of performance testing that assesses a system's, software product's, or software application's performance under realistic load situations. It also demonstrates how the application would behave when there is increased network traffic on the application and multiple USERS are accessing the application.
• Stress Testing: Stress testing is a sort of software testing that ensures the system's stability and dependability. Under extremely HEAVY load conditions, this test examines the system's robustness and error handling.

The following table lists the differences between load testing and stress testing:

The Cyclomatic Complexity can be used to determine how much testing each piece of software requires in our application. The technique aids in the identification of the three QUESTIONS listed below for the programs/features.

• Is it possible to test the FEATURE or programme?
• Is everyone aware of the feature/program?
• Is the feature/program trustworthy?

We can use this technique to determine the "level" of testing required for our application. It is standard practice to consider a piece of functionality to be complex if the cyclomatic complexity RESULT is GREATER than or equal to a certain number, and to conclude as a tester that the piece of code/functionality requires in-depth testing. If the Cyclomatic Complexity result is a lesser value, we conclude as QA that the functionality is of lower complexity and adjust the scope accordingly. Understanding the full testing life cycle is critical, and we should be prepared to suggest modifications to our approach if necessary. The GOAL is to deliver high-quality software, so a QA should take all necessary steps to improve the testing process and the manner the testing team conducts the tests.

An audit is an on-site verification activity of a processor quality system, such as inspection or examination. An internal or external quality auditor, or an audit team, conducts a systematic analysis of a quality system as part of a quality audit. Quality audits are conducted at predetermined intervals to ensure that the INSTITUTION's internal system monitoring methods are well defined and linked to successful action. Audits are an important MANAGEMENT tool for confirming objective proof of processes.

In other words, a quality audit is a verification effort AIMED at determining the degree of compliance of a PRODUCT, design, process, or system to a standard specification or procedure. The quality audit includes two PARTS: the first is an examination of the system in which the products or services are created, known as the quality system audit. The other is a product or service quality audit, which is an examination of the products themselves.

• Severity: The severity of a flaw is defined as the degree to which it can affect the software. The severity of a defect is a metric that INDICATES how serious it is and how much it affects the software's functionality.
• Priority: Priority is a parameter that determines which defects should be addressed in what order. The higher-priority defects should be addressed first.

The following table lists the differences between severity and priority:

When it comes to software testing, Risks are POTENTIAL issues that COULD JEOPARDISE the project stakeholders' goals. It's the likelihood of a bad or UNFAVOURABLE result. A risk is something that has not yet occurred and may never occur; it is a potential concern. The likelihood of a risk becoming an outcome is proportional to the degree of risk linked with the potential for negative consequences.

Most people, for example, are expected to have a cold at some point in their lives, frequently multiple times. A healthy person, on the other hand, is spared any major effects. As a result, this individual's overall risk of catching a cold is low. On the other hand, for an elderly person with breathing issues, the risk of catching a cold is significant. As a result, the overall chance of catching a cold in his instance is significant.

Following are the five dimensions of risks:

• Schedule: Unrealistic schedules, the omission of important activities when drafting a schedule, and other factors could stymie project completion on time. If testing is done from a remote place, an unstable communication link can be regarded as a possible danger.
• Client: Ambiguous requirements description, lack of clarity on issues, frequent changes to requirements, and other factors could lead to chaos throughout project execution.
• Human Resources: Insufficient resources with the required skill level are not available for the project; Resource attrition - Appropriate training schedules for resources must be designed to balance the knowledge level with resources quitting. Underestimating the training effort could have a negative influence on project completion.
• System Resources: The inability to obtain or the delay in obtaining all key computer resources, such as hardware and software tools, or software licences, will have a negative impact.
• QUALITY: A combination of issues such as a shortage of resources, a tight delivery timetable, and frequent changes to requirements will have an impact on the product tested quality.

Regression Testing is a sort of software testing used to ensure that a recent program or code modification hasn't broken EXISTING functionality. Regression Testing is just a full or partial re-execution of previously EXECUTED test CASES to confirm that current functionality is working properly. This testing ensures that new code modifications do not have unintended consequences for current functionality. It ensures that the old code continues to function after the most recent code modifications have been made.

According to industry data, a large proportion of DEFECTS reported by customers were caused by last-minute bug patches that had unintended consequences, making selecting the Test Case for regression testing an art and not an easy task. The following test scenarios can be used to create effective regression tests :

• Test scenarios with a high NUMBER of flaws
• Test cases covering features that are more visible to the users
• Test cases that test the product's fundamental features
• Test cases of functionalities that have experienced significant and recent alterations
• All Test Cases for Integration
• All Complex Test Cases
• Cases of boundary value tests.