Explore topic-wise InterviewSolutions in Current Affairs.

• Load TESTING is a CATEGORY of Performance Testing that is used for checking an application’s capability to perform under various user loads.
• This is done for identifying bottlenecks in performance before the application becomes live.
• It is done by simulating many users hit the API at the same time or in other words, artificial traffic is simulated to identify if the application is capable of handling the load by maintaining consistency in the response times and not impacting the functionality.
• One such tool to perform Load Testing is JMeter. It provides flexibility to create a TEST plan, define the thread groups and record test scripts to simulate artificial load to the API. It finally provides a feature to visualize the result of load testing done. For more information about using JMeter, you can refer here.

Automation Testing

Web Services

Web API

REST API

The big BANG approach is the approach of combining all modules at once and then PERFORMING verification of the FUNCTIONALITY after the individual modules are tested. It belongs to the category of integration TESTING of the APPLICATIONS.

To test the security of the API during API testing, we need to validate 2 things:

• Authentication: Whether the identity of the end-USER is correct.
• Authorization: Whether the user is allowed to ACCESS the resource.

We can ALSO validate whether the TLS or the SSL CERTIFICATE used over the HTTPS protocol is valid or not.

Yes, it is possible. This is because we are sending requests over the internet which mostly follows HTTP protocol. This protocol is text-based and is easier to READ. HENCE, it is required to perform SECURITY testing of the APIS to ensure SAFER systems.

The test environment is an environment that helps test the APIs developed by providing a FEATURE to SEND requests and get the responses from the server. It is similar to the production environment where the Quality Analyst has enough data to PERFORM their functionality testing. In a test environment, we can have a test DATABASE, a localized gateway, a server and a LOAD balancer.

Input INJECTION is the act of SIMULATING inputs for testing APIs. It can be simulated in DIFFERENT ways:

• Direct METHOD Invocation
• Accessibility INTERFACE invocation
• Low-level input simulation
• Device driver simulation
• Robot Simulation.

Automated testing is useful in the long RUN as it HELPS to maximize the TEST coverage of the applications in a SHORTER period of time meaning it helps to test large test sets very easily and quickly. It enables parallel execution and helps to reduce human-generated errors in testing. It saves the time required to test applications thereby saving the overall cost.

CACHING mechanism is the practice of storing data TEMPORARILY to retrieve data for repeated requests. This increases the performance of the system by obtaining the data from the cached COPY instead of hitting the database and getting the original data.

Run SCOPE is an API testing tool that is typically a web application SUPPORTING an EASIER user INTERFACE PLATFORM to test back-end services. For more information, visit here.

Payload is the most common TERM used in the CASE of REST APIs. It refers to the actual data sent to the server in the API request in different formats like JSON, XML etc.

Test API refers to a SET of APIs or library utilities that helps developers to create AUTOMATED test CASES for testing .NET or WIN 32 systems. It has a set of basic DATA building blocks, data types, data structures ETC.

We can FIND the below bugs at the time of API testing:

• Duplicate or missing API functionality
• Failure to handle negative TEST cases
• Failure to handle a SUDDEN spike in load or stress
• Reliability of the application behavior
• Failure to handle requests securely
• Unused flags
• Unimplemented errors
• Poor Performance
• Issues in Multi-threading
• Improper error responses
• Improper status CODES

There are 7 principles in API testing design. They are:

• Optimal Testing: Since it is not possible to test anything exhaustively, there needs to be at least some optimal amount of testing depending on the risk assessment PERFORMED on the application.
• Defect Clustering: This represents the clustering of modules containing most DEFECTS. As a GENERAL rule, almost 80% of the defects are found in 20% of the application modules. These risky modules can be identified by following this approach.
  • However this principle has a problem. We might have to perform API testing repeatedly on the application which might be obstructive to finding new bugs.
• Pesticide Paradox: This paradox states that if the testers use the same test cases repeatedly, then they would not be capable of finding new bugs over a period of time. Hence, the testers NEED to be fully equipped by reviewing and revising the test cases regularly. New test cases are more effective in finding new bugs. However, no amount of testing can ensure that the product is 100% bug-free.
• Presence of defects: Another principle of testing is that the aim of testing should be the presence of bugs and not the ABSENCE of defects. The goal of testing is to reduce the probability of finding undiscovered bugs. In case 0 defects are found, yet we cannot fully claim that our software is 100% bug-free.
• Error absence fallacy: There can be an increased possibility of software being unusable even if it is 99% bug-free which can be wrong. The main focus of software testing is to ensure that the software addresses the business requirements correctly. This principle states that even if we identify and fix the defects if the software does not fulfil the business requirements, then the system is unusable.
• Early Testing: This principle states that it is easier to fix bugs early in the software development lifecycle. Hence, it is recommended to start testing the application as early as possible.
• Context Dependent Testing: The way we test an application depending on the type of the system. We use different techniques, methodologies and test cases to test the applications depending on the type. For example, the way we test e-commerce applications is different from the way we test online streaming applications.

Some of the CHALLENGES faced while doing API testing are:

• PROPER Parameter Selection
• Proper Parameter Combination
• Knowing which API NEEDS to be CALLED in what sequence
• Proper knowledge of output verification
• Knowing what are the proper input VALUES that needs to be provided to the API inputs.

UI TESTING REPRESENTS testing by using GRAPHICAL User Interface. The main area of focus in this is to test the look and feel of the software application by focusing on how the application is feasible for the end-users, do the functionalities of all the items shown on the UI screen - images, fonts, buttons, layouts etc are APPEARING properly as expected.
On the other hand, API testing ensures the testing of communication of data between various software SYSTEMS. It mostly falls under the validation of back-end functionality.

API documentation REPRESENTS any DESCRIPTION of the functionality of the API. Since this documentation will be used by external developers, we need to follow some best practices. They are:

• Plan what needs to be shown in your documentation.
• Do not exclude any fundamental sections of the API functionality.
• Use simple words by AVOIDING technical jargon.
• Include various interactive examples and resources to UNDERSTAND the API functionality clearly.
• Consistently maintain the documentation as and when the functionality gets updated.

Some of the popular TOOLS used for achieving API documentation are:

• JavaDoc
• Doxygen
• OpenAPI
• Redoc
• Swagger UI