Introduction

The success of any software depends on its tests results. Testing is an important activity in the life-cycle of a software. This surely has created a situation of demand for people with an appropriate skillset in the field of software testing. 

Are you preparing for an interview for the position of Software Tester? 

Wouldn’t it be great if you knew the questions that you will be asked in the interview? Well, we wish we could read minds. But, here is what we have for you. Read on!! In this article, we present a comprehensive list of 100 possible questions that you may be asked in the interview.

 So, if you are getting sleepless nights preparing for this interview, keep all your anxiety at bay and read this article. Hey wait!! That’s not all. In this article, we will also suggest answers to these questions which will help you ace the interview and bag the position. 

So, what are waiting for? Let’s get started. 
‍

Q1. What do you understand by software testing and why do you think it is needed?

Ans:  This question has two parts. Let’s look at an appropriate answer for the first part of the question. So, software testing can be defined as an extremely important activity which takes place in the life cycle of a software. Now, you must discuss its importance. From an organization’s point of view, it is a vital solution aimed at ensuring that the real results of the software is same as the expected results and also identifies defects, gaps or bugs, if any. Testing is imperative before the launch of any software in the market as the goal is to deliver quality products to the customers and avoid breakdown in critical production environment. A software which is tested promises security and reliability and better performance. This promotes customer satisfaction. 

‍

Q2.  Can you talk about the various types of software testing?

Ans:  The best way to answer this question is to start with describing the two main categories of software testing- Manual and Automated.

• ‍Manual Testing - This refers to testing of a particular application or software, without the help of any automation tool to ensure it suits the requirements of the customer. 
  ‍
• ‍Automated Testing - This type of testing employs automated tools for the purpose of testing a particular software or application. 
  ‍

Alternatively, you can also begin to answer this question by reiterating the point that software testing aims to check the functionality of an application based on pre-defined requirements by the customer. In order to make sure the application is free of bugs and is stable and reliable, many types of software testing must be performed.  

Next, you can discuss a few popular types of software testing. Some of the common ones have been explained here. 

To make this simple to understand, look at the chart below which explains the various categories and types of software testing. Let’s understand each of these. 

‍

‍

As explained in the above picture, manual testing has three main types of testing namely - 

• White box testing - In this type of testing, the developer inspects or tests each line of the code before it is passed on to the testing team. During the process of testing, the code is noticeable by the developer. It aims to increase the security of the application. White box testing is known by multiple names like open box testing, glass box testing, structural testing etc. 
  ‍
• Black box testing - In this type of testing, it is the test engineer who analyzes the software and tests it against requirements, checks on possible bugs and defects and then sends it back to the development team. The development team works to fix the defects, conducts a round of white box testing and sends it to the testing team. This testing focuses on checking the functionality of the application against the requirements of the customer. It is called “Black Box Testing” because the source code is not visible. 
  ‍
•  Grey box testing - A collaboration of white and black box testing is called grey box testing. This type of testing is done by someone who has hands on experience in software development and testing. In other words, if one person or team conducts both white and black box testing, it is called Grey box testing. 
  ‍

Some of the other common types of testing are - 

• Functional testing - It is also called component testing in which all the components of the application are analyzed in a systematic manner against the pre-defined specifications.  Functional testing is a type of testing under the umbrella of Black box testing. 
  ‍
  The focus is on the requirement of the application and not as much on its code. Some popular types of functional testing are Unit testing, Integration testing and System testing. You can understand these as the stages of functional testing wherein Unit testing is the first stage where all independent module functionality are tested. This is followed by integration testing where the interface between two features is tested. Lastly, it is system testing where the test environment is parallel to the production environment and end to end testing of the software is conducted. This is imperative to check the completeness of the application as per the business requirement.  

• Non-functional testing - Non-functional testing is also a part of black- box testing and aims to yield details of software performance and technologies used. Some of the main types of testing under non-functional testing are- Performance testing, Usability testing and Compatibility testing. 
  ‍

Let us also understand these ones. 

1. Performance testing - This is the stage where the working of the application is assessed by the test engineer. The test engineer applies some load on the application and test multiple aspects of the application like response time, load, scalability etc. Performance testing comprises of some types of testing. For instance, Load testing, Stress testing, Scalability testing and Stability testing. 
   ‍
2. Usability testing - This type of testing aims to test the user-friendliness of the application and to identify any bugs in the interface of the end-user. 
   ‍
3. Compatibility testing - This type of testing is performed to ascertain the functional aspects of the application in a specific hardware and software environment.  
   ‍

Apart from manual testing, there is automation testing as well which is an integral part of software testing. Automation testing involves the use of specific tools for the purpose of automation of manual design tests. There is no human intervention in automation testing and has proven to be most effective for improving the efficiency and coverage for testing a software. It is most suitable in situations when there are multiple regression cycles or releases go on the software. 

Lastly, apart from the ones mentioned above, here is a comprehensive list of types of software testing which is good to know before you appear for an interview. 

• Incremental testing
• Non-incremental testing
• Load testing
• Stress testing 
• Scalability testing
• Stability testing
• Smoke testing
• Sanity testing
• Regression testing
• User acceptance testing
• Exploratory testing
• Ad-hoc testing 
• Security testing
  ‍

Q3. Can you give examples and explain the difference between Load, Stress and Performance testing?

Ans: To answer this question, first refer to the chart on types of software testing shown above. Next, while explaining these three types of testing, it is important to have a clear understanding of the purpose of each of these testing. 

Performance Testing is the parent umbrella which includes both load and stress testing. 

‍

‍

• ‍Performance testing is done to check the performance of various components of the application in a given situation. The aim of this testing is to ensure that the behavior of the application conforms to the industry set benchmark which must be met during this testing. 
  
  Under the performance test, various standards of the application like speed, response time, resource usage, stability etc. are tested. An example that better explains this is that of a Request-response model. In this, a benchmark in terms of time range (time taken from the generation of request to acknowledgment of response) can be set. 
  ‍
• ‍Load testing, on the other hand is a part of performance testing and aims to test the system in terms of its load handling capacity. The load on the system is constantly increased until it reaches a threshold. This testing helps to bring to light any defects or problems because of bandwidth or capacity of the system. It also identifies the load bearing capacity of various components like database, hardware etc. 
  
  A great example to explain load testing is in the case of identifying the maximum number of users a system can handle. Let’s assume, in a given situation 100 users are added every 30 seconds. This continues till the load reaches 1000 users. Each time, new users are added, the system waits for 30 seconds before adding a fresh lot. This continues until the load touches 1000 threads, all run for 300 seconds together and after 300 seconds, 10 threads stop after 3 seconds. This way we are able to anticipate load for future. 
  ‍
• ‍Stress testing aims to identify the stability of an application by overloading the existing resources. It evaluates how an application behaves in beyond peak load situations. The main purpose of this test is to find out the behavior of the application after its failure and monitor its process of recovery thereafter. 
  
  For example, a travel website may experience a large number of visitors during a particular season. In order to perform stress testing, tools are used in a simulated environment where the website has an overly large number of visitors as compared to the day to day visitors. The number of visitors are increased to a level of failure where the website crashes and cannot handle any additional traffic. The behavior of the website at this point is studied carefully to check if the website recovers. This test yields important information regarding improvement areas for performance and mechanism for recovery.  A very important factor for stress testing to be successful is that the application should signal an error when in condition of stress and there must be recovery of the system as soon as the load gets back to normal. 

‍

Q4. Could you explain happy path testing? Please discuss its advantages and limitations. 

Ans: To explain this in the simplest language, you should say” Happy path testing is a test which gives positive results. A very basic example can be using the correct user name and password on the login page. In case of a situation in which we get stuck and does not go further, it is a sad path. It is a default situation with no errors as the inputs used in the test case are known and therefore the results generated are expected. This is usually the first type of test done on the application. 

This testing is extremely important in the entire process of testing. It is pivotal to ensure stability of the application before proceeding to complex situations. Happy path testing yields only positive results and failure of this testing indicates problem with the fundamental functionality of the application which also highlights the need for an alternate path which can be used for the purpose of testing. This test is advantageous as it is quick to detect potential problems which saves time and effort. 

In the interview, you must also mention limitations of happy path testing. As mentioned above, the process of testing uses only positive situations, there is no guarantee of the quality of testing. It is not easy for the test engineer to predict behavior of the application in unplanned situations. 

‍

Q5. Can you explain component testing?

Ans: Component testing has many synonyms and is often referred to as Unit testing, Module testing or program testing. The aim of component testing is to identify defects and ensure functioning of the software in terms of its various modules, programs etc. which can be tested separately. Component testing is conducted as a segregated process from the rest of the system. It is based on the development cycle. 

‍

Q6. How do you explain a bug? 

Ans: During the process of testing the software when a fault is observed in the software product which causes the product to function in an unexpected manner, we call it a bug. 

‍

Q7. What tool do you use for managing bugs? And what are the various stages through which a bug undergoes?

Ans: There will always be some questions in the interview to check that you are not an imposter, but a real software tester. This question is one of those. It may sound simple, however, the way you answer will tell the interviewer whether you really use the tool and understand the bug lifecycle. 

There is no right, or wrong answer here as there could be many different bug management tools, and there could be customized flow of bug stages as per organization’s standard or a team’s need. We will tell you one practical answer here which is based on a real project.

So, in my project, we use Azure DevOps tool to manage all work items, including bugs. Our project is configured on scrum template in ADO which has some predefined state for bugs, but we have also got some customized fields added as our team decided that it will be helpful to manage the flow of bugs efficiently. So, here are the various states of bugs –

1. To Do – This is the initial state of the bug. Whenever a bug is created, it by default comes in ToDo state.
   ‍
2. In Progress – Once the developer starts addressing the bug, it is brought into in progress state. Developers keep the bug in this state until they deploy the fix on QA environment.
   ‍
3. Ready for testing – Once the fix is deployed to QA, developers move it to ready for testing state, so that testers can pick it up for verification.
   ‍
4. Testing in progress – As soon as tester starts verifying the fix, they bring the bug to testing in progress state.
   ‍
5. Closed – This is the final state of the bug. If the fix is verified and working fine, tester moves the bug from ‘testing in progress’ to ‘closed’ state.
   ‍

A usual flow of bug goes from state 1 to state 5 explained above. Furthermore, we have two more special states for bugs –

6. Blocked – A bug is moved into blocked state at any point of time when we are not able to proceed on it due to any reason like dependency on any other work item, environment issue, access issue, etc. When the blocker is resolved, bug is brought back to the state in which it was just before it got blocked. 
   ‍
7. Removed – We use this state for some special scenarios, for example, if the tester raises a bug which is later identified as a duplicate of an existing bug, then we put the bug in removed state. Similarly, if there is any invalid bug or non-reproducible bug, then we put it in removed state. This state indicates that no action needs to be taken on the bug. 

‍

Q8. How does your team handle the flow of re-opened or re-occurring bugs? How is it tracked that some rework is done on a bug?

Ans: You need to explain the practice based on upon how you have actually experienced it in your projects. One possible way could be this:

If the fix fails the verification, then the tester changes the state of bug back from ‘testing in progress’ to ‘To Do’, provides the supporting details, assigns it to the respective developer and adds a ‘redo’ tag on the bug. This redo tag helps in tracking rework. The entire cycle of bug workflow is repeated once the bug is sent back to To Do state. 

If any previously closed bug starts re-appearing then we open a new bug, and give the link to the previous similar bug under related links option in Azure DevOps. On this new bug, we also add a ‘re-appear’ tag, so that we can track how many bugs have re-appeared after closure. 

‍

Q9. What is your understanding of intermittent bug? In your opinion, what is the best way to deal with it?

Ans: This is not only a great question but also an opportunity for you to showcase your skills as an excellent tester. You can begin your answer by explaining that intermittent bugs are those types of bugs which do not show a consistent behavior.  Also, when applications are tested, the same test will yield a different result each time. This inconsistent behavior makes it difficult to reproduce. It occurs under unknown conditions which makes it difficult to identify it. 

One way to tackle this issue is to record the circumstances in which the bug occurs. This helps to understand the variability, particularly data values. If this does not seem to be the source, next check to run is for any concurrency not synchronized properly. The bug must be reproduced in a controlled way and logs must be carefully analyzed to understand where the bug is. Every time, the bug re-occurs, the logs will give additional information which helps to improvise the logging system. 

‍

Q10. What is your understanding of a defect? 

Ans: Once the Software product goes live and there is a non-conformance with the requirement of the product, it is called a defect. 
‍

Q11. Are you aware of some of the attributes of defect reporting?

Ans: This is usually a follow up question where you have the opportunity to showcase your knowledge and understanding of a defect report.  You must answer this question by explaining in brief about a defect report. This report is aims to state the issue or the defect clearly for the developers to replicate and fix the defect. The report captures details about the occurrence and status of the defect.  Let us now talk about the main question which is regarding the attributes of defect reporting. These elements have been listed below- 

• Unique identification of the defect (called Defect ID) which is usually assigned automatically. 
• Name of the project
• Name of the Product
• Version of Release of the product. 
• Be specific about the module of the product in which the defect was captured. 
• The build version of the product where the defect was identified. 
• Clear and concise summary of the defect. 
• Explanation of the defect covering all the details. It is advisable to keep the description easy to understand and devoid of repetitions. 
• Step wise explanation of the process to reproduce the defect. 
• Final results achieved at the end of following the steps mentioned above. 
• Description of the expected result.
• Attachment containing additional information like logs and screenshots. 
• Any additional comments.
• Specify the name and details of the person who identified the defect. 
• Name of the person who is responsible for fixing the defect, in other words whoever it is assigned to.
• Status of the defect.
• Defect probability
• Defect Severity
• Defect Priority 
• Build version of the product in which the defect was fixed. 

‍

Q12. What advise will you give to a team member for effectively reporting defects?

Ans: It is very important to ensure that defects are reported in an effective manner to avoid any wastage of time and effort while trying to reproduce the defect. The below mentioned points can be kept in mind for effective reporting of defects. 

• Be clear and specific while giving details of the action. Clear, stepwise explanation must be specified. In case there were more than one path, describe the path that was followed and the details of the alternative paths can be mentioned separately in the report. Avoid usage of any vague terms like “it”. Always be specific.
   
• Ensure the report is detailed. Share all the information with the developers so that they do not have a need to seek additional information. 
  ‍
• Keep the report objective and ensure to mention required facts and not emotions. 
  ‍
• Do not be in a rush to file the defect report as soon as a defect is reported. Instead, make efforts to replicate the defect at least one more time to be double sure of the defect. In case replication of the defect is not possible, it is advisable to submit the report for further investigation along with the detailed information of the defect which was gathered. 
  ‍
• Before submission of the report, make sure the report has been thoroughly reviewed for any errors. 

‍

Q13. Are there any drawbacks of manual testing?

Ans: This is also a very important question which is commonly asked in interviews. This helps the interviewer gauge if you know in which situations manual testing is not advisable. You can mention the following limitations of manual testing- 

• Manual testing is not a suitable option for projects from large organizations which are time- bound. 
• Manual testing has high chances of human errors. 
• There is no option to record the testing process thus making this process less efficient and reliable.  
• All the aspects of testing are not covered. 
• It is not always a cost- efficient method and turns out to be expensive in the long run. 

‍

Q14. What is your understanding of automated testing? 

Ans: All tests which involve use of software tools for execution, without the need of any manual intervention are automated tests.  

You can also say that tests which use software to not only execute the test but also compare the results of test with predicted results and set up suitable preconditions for the test are automated tests. 

‍

Q15. According to you, which type of tests must be done manually and should not be automated?

Ans: Not all tests can be automated as automation does not guarantee 100% efficiency in terms of results. Also, if we talk about time, there is certainly an investment in terms writing the automation test. Additionally, there is a cost of maintenance. 

Automated tests also do not seem to be a sure shot answer for all problems and can sometimes create more problems. In my opinion, tests which need to be executed only once and involve human discretion for validating success should be done manually. Tests which can be executed quickly must be done manually.

 You can take an example to explain this. We have taken the example of Usability testing which is usually recommended to be done manually. This test cannot be automated as the computer lacks efficiency and judgement to assess if the application is of use for users. This test is usually done only once. Only in certain situations, while dealing with huge dataset, automating Usability test is recommended.”

To cut the long story short, if the need is of a quick test, it should be done manually unless it needs to be run regularly which calls for it to be automated. 

‍

Q16. Is there a difference between a SDET, a Test Engineer and a Developer? 

Ans: The best way to understand this is to first get clarity on the skillset required for each of these roles and then talk about the functional aspect of these roles. In order to explain this, we have used a table. 

‍

Q17. Explain about some of the challenges you face in testing.

Ans: There is no right or wrong answer for this. You may have a different set of challenges depending upon in which project, company, and culture you are working with. It is highly likely that there would be definitely some challenges you must be facing, because we don’t work in perfect world. So, just go ahead and tell the reality here.

Let us give some example challenges-

1. Insufficient Unit testing & smoke testing: not Developers pass on the product to testers without proper unit testing and smoke testing. This in turn blocks and delays the testing and kills testers’ time in going through the basic verification steps which ideally the developers should had addressed in unit testing and smoke testing. This makes the bug or user story to go to & fro and ultimately impacts the delivery timeline. 
2. Status of work items not updated: Sometimes, team members who do the development forget to update the state of work item to ready for testing, which delays the work because until & unless the state is not updated, testers won’t get to know that this particular work item is ready for them to be picked up.
3. Delay in giving user stories to testing queue: If any work item gets development finished very late in the sprint, then it is difficult for us (testers) to pick up that item and finish the testing in the same sprint. For example, in a 10 working days sprint, if something is given to us on 9^th day or 10^th day then it is difficult to close that work item, especially when it encounters any bug, because it needs significant to get the bug resolved by developer and then a re-verification is needed from testing end.  

‍

Q18. How do you deal with these challenges?

Ans: Expect this question to naturally flow in after the previous question. If you are talking about challenges, then you will be surely asked how you handle these challenges. 

Let us give an approach to deal with each of the challenges we mentioned in previous question:

‍

Q19. What do you understand by a test plan? Explain what a test plan includes. Also, how do you create & manage test plans in the tool you use?

Ans: The answer to this question must be to the point as it is a direct question. You can say- 

In order to make sure the quality standards of a product are met, all the activities pertaining to testing are compiled and stored under one plan which is called the test plan. These tests collect information about description of the product, its requirements and case documents. The various inclusions of this plan range from the objectives and scope of testing to the testing environment, reasons for testing and other risk factors.

 It is also important to highlight the importance of a test plan while answering this question. You can say- A test plan is essentially a blueprint used for performing various software testing activities which the test manager monitors and controls.

 You can take the example of a test plan which is created in a situation when a new version of a product is being built. In this case, there will be multiple test cases for this version. These test cases can be updated as required. Whenever there is a new release of the product, a test plan is prepared and the test cases created earlier can be imported into the test plan. These test cases can also be divided into different test suites for easy monitoring. 

Once the test plan is created , the next step is to assign test configurations and testers. The testers are responsible for evaluating the quality of the product by following a continuous process of testing until the expectations from the product are met. A fresh test plan can be created for the next release however some test cases can be reused. This chain of development, testing and release can be repeated by using the existing test cases into new test plans. 

The below mentioned steps can be followed for creating a test plan. 

• Step 1 - Open the project on the web portal and click on Test Plan. In case of a pre-existing test plan, select Test Plans to navigate to the page that lists test plans. 

• ‍Step 2 - On the page that displays Test Plan, select New Test Plan to create a new test plan. 

• Step 3 -On the New Test Plan, select a name for the test plan. Confirm if Area path and iteration are correct and click on Create. 

• Step 4 - The next step is to add a suite to a test plan. Click on + new drop- down list and select type of test suite. 
  

We use requirement bases suite to combine test cases together. This allows to keep a check the status of testing for a backlog item. As soon as a test case is added to requirement- based suite, it also automatically linked to the backlog item. 

• Step 5 - Under Create requirement-based suites, additional clauses can be added to filter the work items basis the iteration path for the sprint. Next click on RUN Query to see the backlog items which match. 

• ‍Step 6 - After running the query, the list of work items returned, choose the backlog items which need to be tested in the sprint. Click on Create Suites for creating a requirement based-suite. 

‍

Q20. What do you understand by Test coverage? 

Ans: Test coverage one of the most important parameters which refers to the completion percentage of testing for a given product. It plays an important role not only for functional but also non-functional activities of testing and is used for addition of missed test cases. 

‍

Q21. Do you think achieving 100% test coverage is possible? What measures would you take to make sure 100% test coverage? 

Ans: This is a follow up question on Test coverage and both aspects of the question must be answered. Firstly, you can start by answering the first part of the question which asks about test coverage. It is generally not possible to conduct 100% of testing for a particular product. However, there surely are a few steps which can bring us closer to the completion percentage. 

One of these important things is to ensure a strict limit on the total percentage of passed test cases and the number of bugs identified. It is also strongly recommended to red flag any breach of deadlines and also in case of scarcity of test budget. Similarly, green flag for highlighting situations when a test case has covered all functionalities and the status for all the bugs thus identified is closed.

‍

Q22. What do you understand by SDLC?

Ans: This is a very critical question asked by the interviewer mainly to gauge if you have a clear understanding of various stages in software development . You can start your answer to this question by explaining that SDLC refers to Software Development Life Cycle which includes activities which are conducted in the entire process of development of a software. The process begins from the stage of collecting information regarding the requirement, analyzing the requirement followed by stages of designing and implementation. The last stages of this cycle are testing and deploying the software followed by its maintenance respectively. 
‍

Refer to the image below for the various stages of development of a software. 

‍

Q23. What is your understanding of STLC i.e. Software Testing Life Cycle? 

Ans: To answer this question, first it is very important to not confuse Software Testing and Software development. 

Note*- We have discussed Software Development Life cycle earlier in this article. 

Software Testing Life Cycle includes the entire chain of activities conducted in the process of testing a software product. The various stages are - 

• Stage 1 - Analyzing and validating the requirement stated in the document and defining the scope of testing. 
  ‍
• Stage 2 - The next stage is where the planning of the test takes place. This is the stage to clearly lay down the strategy of the test plan in terms of estimation of test efforts, automation plan etc. along with the selection of tools. 
  ‍
• Stage 3 - Designing of test cases along with preparation of test data and implementation of scripts for automation. 
  ‍
•  Stage 4 - Set up of test environment which closely simulates the real production environment. 
  ‍
• Stage 5 - Preparation of test cases, reporting of bugs if any and re-testing after resolving. 
  ‍
• Stage 6 - At the final stage, there is a test closure report which is prepared with the details of final tests and their results, summary and learnings. 

Refer to the image below- 

‍

Q24. How do you explain Error in the world of Software Testing? How is it different from a defect? 

Ans: In the process of software testing, when a scenario is missed in requirements or there are some problems with either the design or the implementation of a software, we call it an error. In simple words, error refers to a human mistake that may take place at any stage of software development. It could be because of basic reasons like mis-interpretation of the client’s requirements, insufficient information from the client or may be a few logical errors by the developer in the program. However, a defect is a consequence of the error. A defect happens when the actual software developed does not behave as per the client’s expectation. 

‍

Q25. Can you name some popular tools for manual software testing?

Ans: The best way to answer this question is to briefly discuss the various categories for which these tools are best suited. Here are a few of these categories with a quick list of popular tools under each category. 
‍

1. Test Case Management Tools: This category of tools takes precedence all the others tools as it aids organization, measurement, reporting and collaborating projects which are manually tested. The process of testing may be rendered and futile if there is mismanagement of documentation. This is likely to happen in case of absence of right tools and processes. Test Case Management tools help to bring in the element of organization thereby keeping these assets up to date. 
   ‍
   Some of the popular tools in this category are- 

• Test Lodge - It helps to organize testing documents and enables smooth writing and management of test cases and test plans. It also provides great reporting interface in collaboration with tools like Jira and Trello. 
• Zephyr - This is yet another popular tool which assists the testing teams to create and spreadsheets thereby increasing visibility for their test results. 
• Test Link - This tool is an open source tool which supports manual and automated testing. 
  ‍

2. Issue Tracking tools - This category of tools aims to assist in tracking issues and integrate with teams on projects. These tools have proven to be extremely helpful for software testers. Once the defect has been identified, testers prepare a bug report which is sent to design and development team to work on.
   
   Some of the popular tools in the category are - 

• Trello - This tool assists testers in the creation of issues on a board. Its set up ranges from basic to complex rules and automation.
• Jira - This tool has a flexible framework and is popular among software testers. 
• Basecamp - This tool is a popular project management tool which has simplified the process of tracking. 
• Teamwork - This tool is popularly used for project and work management. It allows customization and allows flexibility to teams. 
  ‍

3. Cross Browser tools - The usage of these tools usually includes the process of manual testing because of the nature of the process. In order to make sure that the UI components are functioning properly in all the browsers, it is important to manually inspect the functionality and response of respective codes in each browser. These tools help testers to ensure proper functionality of the web applications in all browsers.
   
   Some popular tools in this category are - 

• Browser Stack - This is a popular tool used for manual testing using which testers are able to load their application onto browsers on demand thereby saving time. 
• Sauce Labs - This tool provides testing solutions for cross browsers. 
• Browser Shots - This tool is available for free which enables testers to upload URL and then get screenshots of the appearance of the site on multiple browsers. 
  ‍

4. API Testing tools - These tools typically help to confirm that API is in sync with the functionality, security and performance of the application. API testing ensures testers save time and get organized with the usage of API calls and scripts. 
   
   Some popular tools in the category are - 

• SoapUI - It assists with making the process of API testing more effective. API load testing and API functional testing are supported by SoapUI. 
• Postman - This tool allows writing and saving API requests for the purpose of testing which can be run manually or automatically. 
  ‍

5. Screen Capture tools - There are a lot of defects which can be best understood visually an this is where Screen capture testing tools play an important role in the process of manual testing. Some of these tools also allow an option to call out specific notes by marking the image.
   
   Some popular tools in this category are - 

• Cloud App - This tools enables the tester to record the screen, capture screenshots and share it with the development team. 
• Loom - This tool is similar to Cloud App and allows testers to record screen. 
• Skitch - This tool allows testers to take screenshot and annotate to provide additional information to the development team. 

‍