Q6: When should you stop the testing process?

Ans: When the testing team has completed the following milestones, the testing activity will be completed.

Test case execution

The conclusion of the testing phase is marked by the successful completion of a full test cycle following the last issue repair.

Testing deadline

The validation stage's end date also proclaims the validation's completion if no critical or high-priority faults remain in the system.

Code Coverage(CC) ratio

It is the amount of code hidden behind automated testing. The validation can be terminated if the team reaches the desired degree of code coverage (CC) ratio.

Mean Time Between Failure (MTBF) rate

The average time between failures (MTBF) is the average amount of time a device or product operates before failing. This unit of measurement covers just operating time between failures and excludes repair periods, provided the item is fixed and resumes normal operation. MTBF statistics are frequently used to predict how likely a single unit fails within a given time frame.

Q7: What is the difference between a test driver and a test stub?

Ans: A test driver is a piece of code that invokes a software component under test. It's handy for testing that takes a bottom-up strategy.

A test stub is a dummy programme that works alongside an application to complete its functionality. It applies to testing that employs a top-down approach.

For example:

• Consider the following scenario: we need to verify the interface between Modules A and B. We have only completed Module A. If we have the genuine Module B or a fake module, we may test Module A here. Module B is the test stub in this scenario.
• Module B can no longer send or receive data directly from Module A. In such a case, we must transfer data from one module to another by utilizing certain external features known as test drivers.

Q8: How will you overcome the challenges faced due to the unavailability of proper documentation for testing?

Ans: If standard papers such as System Requirement Specification or Feature Description Document are not accessible, QAs may have to rely on the references listed below if they are available.

• Screenshots
• A previous version of the application
• Wireframes

Another reliable method is to consult with the developer and the business analyst. It aids in the resolution of doubts and creates a channel for bringing clarity to the requirements. Furthermore, the emails exchanged may be valuable as a testing reference.

Smoke testing is yet another option for validating the application's main functionality. It would expose some fundamental flaws in the application. If none of these work, we can use our previous experiences to test the application.

Q9: Is there any difference between quality assurance, quality control, and software testing. If so, what is it?

Ans:

Quality Assurance (QA) is a planned and systematic method of checking the quality of the process used to generate a quality product. QA monitors test reports and adjusts the procedure to meet expectations.

Quality Control (QC) is concerned with the product's quality. QC not only detects flaws but also offers changes. As a result, QC implements a method established by QA. The testing team is in charge of quality control.

Software testing is the process of verifying that the product created by developers fulfils the needs of the users. The goal of testing is to discover flaws and ensure that they are corrected. As a result, it aids in the maintenance of the quality of the product to be given to the client.

Q10: Is there any difference between bug leakage and bug release?

Ans:

• Bug leakage: Bug leaking occurs when a bug is identified by the end-user/customer but is missed by the testing team when testing the product. It is a fault in the application that is not noticed by the tester and is finally discovered by the customer/end-user.
• Bug release: A bug release occurs when a certain version of the software is published with a collection of known bugs (s). These defects are often of low severity and priority. It is used when a software business can afford problems in published software but not the time/cost of correcting them in that specific version.