Explore topic-wise InterviewSolutions in .

The following steps can assist in resolving issues during testing:

• Record: Keep track of any problems that arise and resolve them.


• Report: Inform higher-level managers of the issues.


• Control: Establish a process for managing issues.

Prioritizing the order of your test methods can be accomplished by defining a priority order. Consequently, the test will execute in accordance with the priority set.

Syntax: @Test(priority=2)

Example: The following code demonstrates how to set the priority of a test case in TestNG.

Test Execution Sequence:

Yes, you can skip a particular test method or code by setting the 'enabled' parameter to ‘false’ in test annotations.

@Test(enabled = false).

The TestNG framework for Java is an open-source advanced test automation framework that is designed to benefit both testers and developers. The purpose of TestNG is to provide an easy-to-use, readable, structured, maintainable, and user-friendly environment for automated tests. NG stands for 'Next Generation' in TestNG. The high-end annotations, such as data providers, make cross-browser testing easier since you can test across multiple devices and browsers. Furthermore, the framework has an inbuilt mechanism for handling exceptions that prevent the program from terminating unexpectedly.

The term 'sanity testing' refers to a subset of regression testing. The sanity testing ensures that the changes made to the code do not adversely affect the system's performance. After the software build is received, a sanity test is conducted to ensure that the changes made to the code are working correctly. As a checkpoint, this testing is used to determine whether the build can proceed with further testing. Sanity testing focuses on validating the functionality of the application rather than detailed testing.

Features

• It focuses on a smaller section of the application and is a subset of regression testing.


• The process is undocumented.


• Sanity testing is often unscripted.


• In this approach, limited functionalities are deeply tested.


• A tester is usually responsible for performing this task.

• 
  Latent Defect: Latent defects are defects that exist but have not yet been invoked because the conditions required to invoke them have not been met. As a systematic flaw, it encompasses the entire production process of the software, including all pre-production testing and extended testing. When users perform a particular task in an unusual or rare situation or without the presence of usual scenarios, latent defects are revealed.


• 
  Masked Defect: These are the defects that have not yet resulted in a failure since another defect hides that portion of the code from being executed. It can only be discovered when the defect hiding it is exposed by the user through a specific operation. There are defects that are hidden or marked by another defect and remain hidden until the other defect is detected.

SPICE stands for Software Process Improvement and Capability Determination. In the field of software development processes, SPICE is a standard framework for assessing the efficiency and effectiveness of the development process. IEC (International Electrotechnical Commission) and ISO (International Organization for Standardization) jointly developed SPICE.

The term defect refers to a system error that prevents the intended action from being accomplished. Testing is most important when it comes to finding defects. Testing needs to begin early in the development process since defects can be found throughout. As shown in the following figure, defects are divided into three main categories:

• 
  Wrong: It implies incorrect implementation of requirements. There is a variance between the specifications and what was expected, resulting in this defect.


• 
  Missing: This indicates that a specification has not been implemented, or a requirement of the customer has not been properly noted.


• 
  Extra: In this case, the defect is caused by a requirement incorporated into the product that was not provided by the end-user. 

1. Selenium: a web browser automation tool that automates the test suites you need to run on a web browser.


2. Protractor: An end-to-end test framework for Angular and AngularJS applications. Protractor runs tests against your application running in a real browser, interacting with it as a user would.


3. Cypress: A modern front-end testing tool built for the modern web. Though it’s similar to Selenium and Protractor, it’s architecturally different from them.


4. Jasmine: This is an open-source JavaScript testing framework that allows you to write behaviour-driven tests.


5. JUnit and NUnit: These are unit testing frameworks for Java and C# programming languages, respectively.

Bugs and errors differ in the following ways:

A software bug is an error in the software that produces wrong results. A software tester tests the software to find bugs in it.

There are many causes for the bugs—for example, poor design, sloppy programming, lack of version control, or miscommunication. Throughout development, developers introduce hundreds or thousands of bugs in the system. The goal of the tester is to uncover those bugs.

You can find a bug in many different ways, regardless of your role. When building the software, the software developer might notice the bug in another module, written by another developer or by themselves. The tester actively tries to find the bugs as part of a routine testing process. Finally, the users could see the bugs when the software is in production.

All bugs, no matter how they are found, are recorded into a bug-tracking system. A triage team triages the bugs and assigns a priority to the bug, and assigns the bug to a software developer to fix it. Once the developer resolves the problem, they check in the code and mark that bug as ready for testing. Once a bug is ready for testing, it goes to the tester, who tests the software to verify if it’s indeed fixed. If it is, then it’s closed. If not, they assign it to the same developer with a description of the exact steps to reproduce the bug. Some examples of popular bug-tracking systems include BugZilla, FogBugz, etc.

Trivia:

The first software bug was discovered by Admiral Grace Hopper, on September 9, 1947. After they opened a malfunctioning piece of hardware, they found an insect stuck in the relay. Image Source: Link

• 
  Test Case: Test Cases are a series of actions executed during software development to verify a particular feature or function. A test case consists of test steps, test data, preconditions, and postconditions designed to verify a specific requirement.


• 
  Test Scenario: Usually, a test scenario consists of a set of test cases covering the end-to-end functionality of a software application. A test scenario provides a high-level overview of what needs to be tested.


• 
  Test Scripts: When it comes to software testing, a test script refers to the set of instructions that will be followed in order to verify that the system under test performs as expected. The document outlines each step to be taken and the expected results. 

It is extremely beneficial to use automation testing when using the agile model in software testing. It helps in achieving maximum test coverage in a lesser time of the sprint.

• 
  Black-box testing in software testing: In black-box testing, the system is tested only in terms of its external behaviour; it does not consider how the software functions on the inside. This is the only limitation of the black-box test. It is used in Acceptance Testing and System Testing.


• 
  White-box testing in software testing: A white-box test is a method of testing a program that takes into account its internal workings as part of its review. It is used in integration testing and unit testing.


• 
  Grey-box testing in software testing: A Gray Box Testing technique can be characterized as a combination of a black box as well as a white box testing technique used in the software testing process. Using this technique, you can test a software product or application with a partial understanding of its internal structure.

Among the different types of test coverage techniques are:

• 
  Statement/Block Coverage: Measures how many statements in the source code have been successfully executed and tested.


• 
  Decision/Branch Coverage: This metric measures how many decision control structures were successfully executed and tested.


• 
  Path Coverage: This ensures that the tests are conducted on every possible route through a section of the code.


• 
  Function coverage: It measures how many functions in the source code have been executed and tested at least once.

When software is being tested, the code coverage measures how much of the program's source code is covered by the test plan. Code coverage testing runs in parallel with actual product testing. Using the code coverage tool, you can monitor the execution of statements in your source code. A complete report of the pending statements, along with the coverage percentage, is provided at the end of the final testing.

The dictionary definition of regression is the act of going back to a previous place or state. In software, regression implies that a feature that used to work suddenly stopped working after a developer added a new code or functionality to the software.

Regression problems are pervasive in the software industry, as new features are getting added all the time. Developers don't build these features in isolation, separate from the existing code. Instead, the new code interacts with the legacy code and modifies it in various ways, introducing side effects, whether intended or not.

As a result, there is always a chance that introducing new changes may negatively impact a working feature. It's important to keep in mind that even a small change has the potential to cause regression.

Regression testing helps ensure that the new code or modifications to the existing code don't break the present behaviour. It allows the tester to verify that the new code plays well with the legacy code.

Software testing is governed by seven principles:  

• 
  Absence of errors fallacy: Even if the software is 99% bug-free, it is unusable if it does not conform to the user's requirements. Software needs to be bug-free 99% of the time, and it must also meet all customer requirements.


• 
  Testing shows the presence of errors: Testing can verify the presence of defects in software, but it cannot guarantee that the software is defect-free. Testing can minimize the number of defects, but it can't remove them all. 


• 
  Exhaustive testing is not possible: The software cannot be tested exhaustively, which means all possible test cases cannot be covered. Testing can only be done with a select few test cases, and it's assumed that the software will produce the right output in all cases. Taking the software through every test case will cost more, take more effort, etc., which makes it impractical.


• 
  Defect clustering: The majority of defects are typically found in a small number of modules in a project. According to the Pareto Principle, 80% of software defects arise from 20% of modules.


• 
  Pesticide Paradox: It is impossible to find new bugs by re-running the same test cases over and over again. Thus, updating or adding new test cases is necessary in order to find new bugs.


• 
  Early testing: Early testing is crucial to finding the defect in the software. In the early stages of SDLC, defects will be detected more easily and at a lower cost. Software testing should start at the initial phase of software development, which is the requirement analysis phase.


• 
  Testing is context-dependent: The testing approach varies depending on the software development context. Software needs to be tested differently depending on its type. For instance, an ed-tech site is tested differently than an Android app.