QA Interview Questions

Every process in Quality Assurance involves the PDCA (Plan Do Check Act) cycle, often known as the Deming cycle. The following are the phases of this cycle:

• Plan: The organisation should plan and develop process-related objectives, as well as the methods necessary to provide a high-quality final product. Here, Quality Assurance ensures that the planning made takes into consideration the quality of the product.
• Do: This phase involves process development and testing, as well as "doing" changes to processes. Here, Quality Assurance ensures that the processes followed during development maintain the quality of the product.
• Check: In this phase, processes are monitored, modified, and checked to see if they achieve the intended goals. Here, Quality Assurance ensures that the processes are checked thoroughly so that no defects might be missed.
• Act: In this phase, a Quality Assurance tester should take the steps that are required to improve the processes.

These stages are done to guarantee that the organization's procedures are assessed and improved on a regular basis.

Software Testing: Software testing is a method of investigating a system to see how it works according to product requirements and customer expectations and identify potential flaws. To test the product, find bugs, and see if they've been fixed, a variety of methods are utilised. Customers can use testing to check if the generated product satisfies their expectations in terms of design, compatibility, and functionality, among other things.

Validating the product against specifications and client requirements, as well as detecting and reporting flaws, are all part of the testing process. To detect software flaws, it uses a variety of testing methodologies such as functional, non-functional, and acceptability testing. Furthermore, before the product is released to the client, the purpose of software testing is to ensure that any found faults are entirely corrected with no side effects.

The following table lists the differences between Quality Assurance and Testing:

• Test Plan: A test plan is a document that illustrates the test procedure, destinations, timetable, estimation, and expectations, as well as the assets needed for testing. It motivates us to determine the effort required to approve the kind of application being tested. The test plan serves as a diagram to guide software testing exercises as a well-defined method that the test manager closely monitors and controls. Test plan id, highlights to be tested, test systems, testing assignments, highlights pass or bomb criteria, test expectations, duties, and timeline, and so on are all included in the test plan.
• Test Strategy: In software testing, a test strategy is a collection of guiding principles that specifies the test design and control how the software testing process is carried out. The Test Strategy's goal is to give a systematic method to software testing so that quality, traceability, reliability, and better planning may be assured.

The following table lists the differences between Test Plan and Test Strategy:

• Build: A build is a software or application that is ready to be tested. Developers create software, which they then hand over to testers to test. It's a broad phrase that refers to any application that will be examined. Developers can either create a complete program or add a new feature to an existing one. Then that program, together with the new functionality, is dubbed BUILD, and it is put through its tests by testers.
• Release: After development and testing, the release is the finalized application. The testing team verifies the program and releases it to the customer after testing it. It's possible that a single release will have many builds. As a result, it is the program that is supplied to the customer when the development and testing phases are completed. Furthermore, the release is based on builds, and there may be multiple builds.

The following table lists the differences between build and release:

• Bug Leakage: When a bug is discovered by an end-user, that should have been caught in earlier builds/versions of the application, a bug leakage occurs. Bug leaking refers to a fault that exists during testing but is not discovered by the tester and is subsequently discovered by the end-user.
• Bug Release: When a particular version of the software is released with a collection of known bugs/defects, it is referred to as a bug release (s). Bugs of this type are frequently of low severity and/or priority. When the company can afford the existence of a bug in the released software rather than the time/cost of repairing it in that version, this is done. In most cases, these bugs are disclosed in the Release Notes.

A Traceability Matrix is a document that connects any two baseline documents that require a many-to-many link to ensure that the relationship is complete. It's used to keep track of requirements and make sure they're being met on the present project.

The following are the three major components of a traceability matrix:

• Forward Traceability: This matrix is used to determine whether the project is progressing in the appropriate direction and for the correct product. It ensures that each specification is applied to the product and that each specification is adequately tested. It connects test cases to requirements.
• Backward or reverse Traceability: It is used to verify that the present product is still on track. The goal of this form of traceability is to ensure that we are not expanding the project's scope by adding code, design features, testing, or other activities not stated in the requirements. It connects requirements to test cases.
• Bidirectional Traceability: This traceability matrix ensures that all criteria are covered by test cases in both directions (forward and backward). It examines the impact of a change in requirements caused by a work product defect, and vice versa.

Software testers utilise defect leakage as a metric to determine the effectiveness of Quality Assurance (QA) testing. It's the ratio of the total number of flaws attributed to a stage (which are captured in subsequent stages) to the sum of the total number of defects captured in that stage and the total number of defects assigned to a stage (which are captured in subsequent stages). Defect leakage is a metric that counts the percentage of faults that leak from one testing stage to the next, as well as demonstrating the effectiveness of software testers' testing. The testing team's worth, on the other hand, is only confirmed when defect leaking is small or non-existent.

Quality Control (QC): A systematic set of techniques used to assure the quality of software products or services is known as quality control in software testing. By testing and reviewing the software product's functional and non-functional requirements, the quality control process ensures that it fulfils the actual needs.

The following table lists the differences between Quality Assurance (QA) and Quality Control (QC):

Monkey testing is a software testing technique in which the tester inserts any random inputs into the software application without using predefined test cases and observes the software program's behaviour to see if it crashes. The goal of monkey testing is to use experimental ways to uncover faults and problems in software applications. Monkey testing is a sort of black-box testing that involves supplying random inputs to a system in order to check its behaviour, such as whether it is crashing or not. Monkey testing does not necessitate the creation of test cases. It can also be automated, in the sense that we can develop programs or scripts to produce random inputs in order to test the system's behaviour. When undertaking stress or load testing, this technique comes in handy.

Monkeys are divided into two categories:

• Smart Monkeys: The smart monkeys are those who have a basic understanding of the application. They know which of an application's pages will redirect to which page. They also know whether the inputs they're giving are valid or not. If they discover an error, they are wise enough to report it as a bug. They are also aware of the menus and buttons.
• Dumb Monkeys: Dumb Monkeys are individuals who are completely unaware of the application. They have no idea where an application's pages will reroute. They give random inputs and are unaware of the application's beginning and finish points. Despite the fact that they have no knowledge of the application, they discover bugs such as environmental failure or hardware failure. They also have limited knowledge of an application's functioning and user interface.

Gorilla Testing:

Gorilla testing is a method of software testing in which a module is frequently tested based on some random inputs, ensuring that the module's operations are checked and that there are no problems in the module. So it's also known as Torture Testing, Fault Tolerance Testing, or Frustrating Testing because of the Gorilla Testing pattern. It's a manual test that's done over and over again. In Gorilla Testing, testers and developers work together to regularly evaluate a module's functionality.

The following table lists the differences between gorilla testing and monkey testing:

Testware is a collection of software created for the specific purpose of software testing, particularly software testing automation. 

For example, automation testware is created to run on automation frameworks. All utilities and application software that work together to test a software package but do not necessarily contribute to operational purposes are referred to as testware. As a result, testware is only a working environment for application software or portions thereof, rather than a static configuration. It contains artifacts created during the testing process that is needed to plan, develop, and execute tests, such as documentation, scripts, inputs, expected outcomes, set-up and clear-up processes, files, databases, environment, and any other software or tools used during testing. Both verification and validation testing methodologies are used to create testware. Testware, like software, consists of codes and binaries, as well as test cases, test plans, and test reports. Testware should be preserved and faithfully maintained under the direction of a configuration management system.

Data-Driven Testing is a software testing technique that stores test data in a table or spreadsheet format. Testers can use data-driven testing to enter a single test script that can run tests for all test data from a table and expect the test results to be returned in the same table. It's also known as parameterized testing or table-driven testing.

Because testers usually have several data sets for a single test, Data-Driven Testing is critical. Creating different tests for each data set can be time-consuming. Data-driven testing allows data to be kept separate from test scripts, and the same test scripts can be run for multiple combinations of input test data, resulting in more efficient test results.

The above image depicts the process of data-driven testing. Test data is taken from a data file and tested on the application and then the produced output is compared with the actual output. 

The Requirement Traceability Matrix and Test Coverage Matrix will assist us in determining whether or not our test cases are adequately covered. The requirement traceability matrix will assist us in determining whether the test conditions are sufficient to fulfil all of the requirements. Coverage matrices will assist us in determining whether the test cases are sufficient to satisfy all of the Requirement Traceability Matrix test conditions.

The below image shows a sample Requirement Traceability Matrix:

The below image shows a sample Test Coverage Matrix:

Following are the various artifacts that we can refer to while writing test cases :

• Specification of functional requirements.
• Document that explains what the requirements are.
• Wireframes.
• Use Cases.
• User Stories.
• Acceptance criteria.
• User Acceptance Testing Test cases.

A test case is a collection of actions performed to ensure that a specific feature or operation of your software program is working properly. A Test Case is a set of test procedures, data, preconditions, and postconditions created for a specific test scenario in order to verify any requirement. The test case contains specified variables or conditions that a testing engineer might use to compare expected and actual outcomes in order to assess whether a software product meets the customer's needs.

Following are some good practices for writing test cases : 

• Simple and transparent test cases are required: Make your test cases as simple as possible. They must be clear and straightforward because the test case author may not be able to perform them. Use declarative language such as "go to the main page," "input data," "click here," and so on. This makes it easier to understand the test stages and speeds up the testing process.
• Create a test case that considers the end-user: Any software project's ultimate goal is to produce test cases that fulfil client requirements and are simple to use and run. A tester must write test cases from the standpoint of the end-user.
• Repetition of test cases should be avoided: Test instances should not be repeated. If a test case is required for the execution of another test case, use the test case id in the preconditioned column to refer to it.
• Make certain you have complete coverage: Make sure you write test cases to ensure you've covered all of the software requirements in the specification document. To verify that no functions or conditions are left untested, use the Traceability Matrix.
• Don't Make Assumptions: When creating a test case, don't make assumptions about the functioning and features of your software application. Follow the specifications in the specification documents.
• Self-cleaning: The test case you write must restore the Test Environment to its previous condition and should not render it unusable. This is particularly true when it comes to configuration testing.

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.

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.

• 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:

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.

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.

• 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:

• 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:

• 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:

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.

• 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:

Conclusion

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:

• Quality Assurance Engineer Salary
• Difference Between Quality Assurance and Quality Control
• Software Testing
• Automation Testing
• Manual Testing
• JMeter Interview Questions
• Smoke vs Sanity Testing