Selenium Certification Training Course
- 53k Enrolled Learners
- Weekend/Weekday
- Live Class
Testing is crucial to the success of any software product in this competitive world. Manual tests play a pivotal role in software development and come in handy whenever you have a case where you cannot use automated tests. Hence, there is still a lot of demand for people with skills relevant to manual testing. This Manual Testing Interview Questions article is the perfect guide for you to master software testing.
Let’s begin by taking a look at the most frequently asked Manual Testing Interview Questions.
For better understanding, the Interview Questions are divided into the following sections:
Software Testing is a process used to identify developed software’s correctness, completeness, and quality. It includes a series of activities conducted to find software errors so that it can be corrected before the product is released to the market.
Quality Control | Quality Assurance |
Quality control is a product-oriented approach of running a program to determine if it has any defects, as well as to make sure that the software meets all of the requirements put forth by the stakeholders. | Quality assurance is a process-oriented approach that focuses on making sure that the methods, techniques, and processes used to create quality deliverables are applied correctly. |
Software testing is a mandatory process that guarantees that the software product is safe and good enough to be released to the market. Here are some compelling reasons to prove testing is needed:
Software testing is a huge domain but it can be broadly categorized into two areas such as :
Quality control is a product-oriented approach of running a program to determine if it has any defects, as well as making sure that the software meets all of the requirements put forth by the stakeholders.
Different types of manual testing are;
Four levels of manual testing are:
User Acceptance Testing – The final level, acceptance testing, or UAT (user acceptance testing), determines whether or not the software is ready to be released.
The testbed is an environment configured for testing. It is an environment used for testing an application, including the hardware as well as any software needed to run the program to be tested. It consists of hardware, software, network configuration, an application under test, other related software.
The manual testing process comprises the following steps:
A test scenario in software testing is a detailed description of a specific functionality to be tested. It outlines conditions, inputs, and expected outcomes for testers to follow. By replicating real-world interactions, it helps uncover defects and ensures the software meets requirements. Test scenarios aid in identifying issues early, allowing timely resolution before release, contributing to a reliable software product.
GUI (Graphical User Interface) testing is a software testing technique focused on evaluating the visual and interactive aspects of a software application. It involves verifying that the user interface elements, such as buttons, menus, forms, and windows, function correctly and display accurately. GUI testing ensures that user interactions with the application are smooth, intuitive, and aligned with design specifications. Testers assess aspects like layout, font, color schemes, responsiveness, and alignment of graphical elements. GUI testing is essential to guarantee a positive user experience and identify any discrepancies between the intended design and the actual appearance and behavior of the application. By addressing issues early in the development cycle, GUI testing helps enhance usability, user satisfaction, and the overall quality of the software product.
Software testing should end when the predetermined testing objectives have been achieved and the software meets the specified quality criteria. Testing concludes when all test cases have been executed, defects have been identified and resolved, and the software functions as intended. However, it’s essential to consider factors such as time constraints, budget, and the acceptable level of risk. While complete elimination of defects is improbable, testing should halt when the benefits of additional testing no longer justify the resources expended. A balance between thorough testing and timely release is crucial, ensuring that the software is stable, functional, and aligns with user expectations.
Software testing encompasses various types aimed at ensuring the quality, functionality, and reliability of software applications. Unit testing verifies individual components in isolation. Integration testing assesses interactions between integrated components. Functional testing validates if the software functions as specified. Regression testing ensures new changes don’t adversely affect existing functionalities. Performance testing evaluates the system’s responsiveness and scalability under different conditions. Security testing examines vulnerabilities and safeguards against threats. User Acceptance Testing (UAT) involves end-users validating software suitability. Compatibility testing checks software behavior across different platforms. Usability testing assesses user-friendliness and overall user experience. Exploratory testing involves dynamic, ad hoc testing. Automation testing uses scripts to execute tests. Load testing gauges the application’s response under heavy load. Each type targets specific aspects, collectively ensuring a comprehensive evaluation of the software’s capabilities and performance before deployment.
Acceptance testing is a critical phase in software testing where a software application is evaluated to determine whether it meets the specified requirements and is ready for deployment. It involves validating that the software aligns with user expectations, functions as intended, and satisfies the defined criteria for acceptance.
There are two main categories of acceptance testing:
1. User Acceptance Testing (UAT): In UAT, end-users or stakeholders perform tests to ensure that the software meets their needs and requirements. This testing phase confirms that the software is user-friendly, fits into the users’ workflows, and provides the desired functionalities.
2. Business Acceptance Testing (BAT): BAT focuses on validating that the software fulfills the business objectives and goals. It ensures that the software aligns with the strategic goals of the organization and that it supports the intended business processes.
Acceptance testing acts as the final gate before software release. Its successful completion indicates that the software is ready for deployment to a wider audience. Any issues identified during acceptance testing are addressed, and once the software passes this testing phase, it signifies that it has met the necessary quality standards and is deemed acceptable for production use.
Bug Leakage:
Bug leakage occurs when a defect that was previously reported and fixed reappears in the software after it was thought to be resolved. This usually happens when the testing team fails to identify the recurrence of the bug during retesting or regression testing. It indicates that the bug was not completely fixed or that the testing process might have missed certain scenarios that trigger the bug. Bug leakage can lead to a decrease in user confidence and dissatisfaction if users encounter the same issue post-release.
Bug Release:
Bug release refers to the presence of defects or bugs in the software that are identified after the software has been released to the users or clients. These bugs were not detected during the testing process and were inadvertently included in the released version. Bug releases can happen due to various reasons, such as incomplete testing, inadequate test coverage, or unforeseen scenarios. They can result in user inconvenience, reputational damage, and the need for urgent patches or updates to fix the released bugs.
A test script is a set of instructions or lines of code written to automate the execution of test cases during software testing. It outlines the sequence of actions that need to be performed by the testing tool or framework to simulate user interactions with the software. Test scripts specify inputs, expected outcomes, and validation criteria for each step, allowing for repeatable and consistent testing. By automating test cases through scripts, testing efficiency is improved, and manual effort is reduced. Test scripts are particularly valuable for regression testing, where repetitive tests need to be executed to ensure that new changes haven’t introduced defects.
Commonly, applications have three separate layers:
API testing is performed at the most critical layer of software architecture, the Business Layer.
Verification | Validation |
It is a static analysis technique. Here, testing is done without executing the code. Examples include – Reviews, Inspection, and walkthrough. | It is a dynamic analysis technique where testing is done by executing the code. Examples include functional and non-functional testing techniques. |
A bug is a just fault in the software that’s detected during testing time. A defect is a variance between expected results and actual results, detected by the developer after the product goes live.
Merits of manual testing are:
De-merits of manual testing are:
Documentation plays a critical role in achieving effective software testing. Details like requirement specifications, designs, business rules, inspection reports, configurations, code changes, test plans, test cases, bug reports, user manuals, etc. should all be documented.
Documenting the test cases will facilitate you to estimate the testing effort you will need along with test coverage and tracking and tracing requirement. Some commonly applied documentation artifacts associated with software testing are:
With this, we have completed basic questions based on manual testing. In the next part of this Manual Testing Interview Questions article, let’s discuss advanced level questions related to manual testing.
Manual Testing | Automation Testing |
In manual testing, the accuracy, and reliability of test cases are low, as manual tests are more prone to human error. | Automated testing, on the other hand, is more reliable as tools and scripts are used to perform tests. |
The time required for manual testing is high as human resources perform all the tasks. | The time required is comparatively low as software tool execute the tests |
In manual testing investment cost is low, but Return of Investment(ROI) is low as well. | In automation testing investment cost and Return of Investment, both are high. |
Manual testing is preferred when the test cases are run once or twice. Also suitable for Exploratory, Usability and Adhoc Testing. | You can use test automation for Regression Testing, Performance Testing, Load Testing or highly repeatable functional test cases |
Allows for human observation to find out any glitches. Therefore manual testing helps in improving the customer experience. | As there is no human observation involved, there is no guarantee of positive customer experience. |
Alternatively, you can check out the Automation Engineer Course by Edureka and get certified!
There are a lot of cases when manual testing is best suited over automation testing, like:
The different phases involved in the software testing life cycle are:
Phases | Explanation |
Requirement Analysis | QA team understands the requirement in terms of what we will testing & figure out the testable requirements. |
Test Planning | In this phase, the test strategy is defined. Objective & the scope of the project is determined. |
Test Case Development | Here, detailed test cases are defined and developed. The testing team also prepares the test data for testing. |
Test Environment Setup | It is a setup of software and hardware for the testing teams to execute test cases. |
Test Execution | It is the process of executing the code and comparing the expected and actual results. |
Test Cycle Closure | It involves calling out the testing team member meeting & evaluating cycle completion criteria based on test coverage, quality, cost, time, critical business objectives, and software. |
If you face any challenges with these Manual Testing interview questions, please comment on your problems in the section below.
Bug – A bug is a fault in the software that’s detected during testing time. They occur because of some coding error and leads a program to malfunction. They may also lead to a functional issue in the product. These are fatal errors that could block a functionality, results in a crash, or cause performance bottlenecks
Defect – A defect is a variance between expected results and actual results, detected by the developer after the product goes live. The defect is an error found AFTER the application goes into production. In simple terms, it refers to several troubles with the software products, with its external behavior, or with its internal features.
Error – An error is a mistake, misunderstanding, or misconception, on the part of a software developer. The category of developers includes software engineers, programmers, analysts, and testers. For example, a developer may misunderstand a design notation, or a programmer might type a variable name incorrectly – leads to an error. An error normally arises in software, it leads to a change the functionality of the program.
You can even check out the details of Manual Testing with the Manual Testing course.
A software test engineer is a professional who determines how to create a process that would best test a particular product in the software industry.
“Testing of a previously tested program to ensure that defects have not been introduced or uncovered in unchanged areas of the software, as a result of the changes made is called Regression Testing.”
A regression test is a system-wide test whose main purpose is to ensure that a small change in one part of the system does not break existing functionality elsewhere in the system. It is recommended to perform regression testing on the occurrence of the following events:
System Testing | Integration Testing |
System Testing tests the software application as a whole to check if the system is compliant with the user requirements | Integration testing tests the interface between modules of the software application |
Involves both functional and non-functional testings like sanity, usability, performance, stress an load | Only functional testing is performed to check whether the two modules when combined give the right outcome |
It is high-level testing performed after integration testing | It is low-level testing performed after unit testing |
A defect life cycle is a process in which a defect goes through various phases during its whole lifetime. The cycle starts when a defect is found and ends when a defect is closed, after ensuring it’s not reproduced. Bug or defect life cycle includes the steps as shown in the below figure.
If you wish to learn in-depth about Bug Life Cycle then you can refer this article on Software Testing Tutorial.
A test harness is the gathering of software and test information arranged to test a program unit by running it under changing conditions like stress, load, data-driven, and monitoring its behavior and outputs. Test Harness contains two main parts:
– A Test Execution Engine
– Test script repository
Test Closure is a document which gives a summary of all the tests conducted during the software development life cycle and also gives a detailed analysis of the bugs removed and errors found. This memo contains the aggregate no. of experiments, total no. of experiments executed, total no. of imperfections discovered, add total no. of imperfections settled, total no. of bugs not settled, total no of bugs rejected and so forth.
Positive Testing | Negative Testing |
Positive testing determines that your application works as expected. If an error is encountered during positive testing, the test fails | Negative testing ensures that your application can gracefully handle invalid input or unexpected user behavior |
In this testing, tester always check for an only valid set of values | Testers apply as much creativity as possible and validating the application against invalid data |
When dealing with a severely buggy program, a systematic approach is essential to identify, prioritize, and resolve the issues effectively. Here’s how I would handle it:
Bug Triage: Start by categorizing and prioritizing the bugs based on their severity and impact on the program’s functionality. Critical bugs affecting core functionalities should be addressed first.
Isolate and Reproduce: Reproduce the bugs in a controlled environment to understand their triggers and conditions. Isolating the bugs helps in diagnosing the root causes.
Root Cause Analysis: Conduct a thorough investigation to identify the root causes of the bugs. This may involve reviewing the code, logs, and system behavior to pinpoint the areas requiring correction.
Fix the Bugs: Develop patches or fixes to address the identified issues. Implement solutions that not only resolve the immediate problems but also consider the potential implications on other parts of the program.
Unit Testing: Test the individual fixes rigorously through unit testing to ensure that they don’t introduce new problems or regressions.
According to pesticide paradox, if the same tests are repeated over and over again, eventually the same test cases will no longer find new bugs. Developers will be extra careful in those places where testers found more defects and might not look into other areas. Methods to prevent pesticide paradox:
Using these methods, it’s possible to find more defects in the area where defect numbers dropped.
In case you are facing any challenges with these Manual Testing interview questions, please comment on your problems in the section below.
Defect Cascading is the process of triggering other defects in the application. When a defect goes unnoticed while testing, it invokes other defects. As a result, multiple defects crop up in the later stages of development. If defect cascading continues to affect other features in the application, identifying the affected feature becomes challenging. You may make different test cases to solve this issue, even then it is difficult and time-consuming.
In general, quality software is reasonably bug-free, delivered on time and within budget, meets requirements and/or expectations, and is maintainable. But again ‘quality’ is a subjective term. It will depend on who the ‘customer’ is and their overall influence in the scheme of things. For example, each type of ‘customer’ will have their own slant on ‘quality’ – the accounting department might define quality in terms of profits while an end-user might define quality as user-friendly and bug-free.
Black-Box Testing, also known as specification-based testing, analyses the functionality of a software/application without knowing much about the internal structure/design of the item. The purpose of this testing is to check the system’s functionality as a whole to ensure that it works correctly and meets user demands. Various black-box testing techniques are:
White-Box Testing also known as structure-based testing, requires a profound knowledge of the code as it includes testing of some structural part of the application. The purpose of this testing is to enhance security, check the flow of inputs/outputs through application and to improve design and usability. Various white-box testing techniques are:
Experienced-based testing is all about discovery, investigation, and learning. The tester constantly studies and analyzes the product and accordingly applies his skills, traits, and experience to develop test strategies and test cases to perform necessary testing. Various experience-based testing techniques are:
Top-Down – Testing happens from top to bottom. That is, high-level modules are tested first, and after that low-level modules. Lastly, the low-level modules are incorporated into a high-level state to guarantee the framework is working as it is expected to.
Bottom-Up – Testing happens from base levels to high-up levels. The lowest level modules are tested first and afterward high-level state modules. Lastly, the high-level state modules are coordinated to a low level to guarantee the framework is filling in as it has been proposed to.
Features | Smoke Testing | Sanity Testing |
---|---|---|
System Builds | Tests are executed on initial builds of software product | Tests are done on builds that have passed smoke tests & rounds of regression tests |
Motive of Testing | To measure the stability of the newly created build to face off more rigorous testing | To evaluate rationality & originality of the functionalities of software builds |
Subset of? | Is a subset of acceptance testing | Is a subset of regression testing |
Documentation | Involves documentation and scripting work | Doesn’t emphasize any sort of documentation |
Test Coverage | Shallow & wide approach to include all the major functionalities without going too deep | Narrow & deep approach involving detailed testing of functionalities and features |
Performed By? | Executed by developers or testers | Executed by testers |
Static Testing | Dynamic Testing |
Static Testing is a white box testing technique, it includes the process of exploring the records to recognize the imperfections in the very early stages of SDLC. | Dynamic testing includes the process of execution of code and is done at the later stage of the software development lifecycle. It validates and approves the output with the expected results. |
Static Testing is implemented at the verification stage. | Dynamic testing starts during the validation stage. |
Static testing is performed before the code deployment. | Dynamic testing is performed after the code deployment |
The program’s code error detection and execution is not a concern in this type of testing. | Execution of code is necessary for dynamic testing. |
With this, we have completed theory questions. In the next part of this Manual Testing Interview Questions article, let’s discuss some real-world scenario-based questions.
Deciding when to stop testing can be quite difficult. Many modern software applications are so complex and run in such an interdependent environment, that complete testing can never be done. Some common factors in deciding when to stop testing are:
Often testers encounter a bug that can’t be resolved at all. In such situations, the best bet is for testers to go through the process of reporting whatever bugs or blocking-type problems initially show up, with the focus being on critical bugs. Since this type of problem can cause severe problems such as insufficient unit testing or insufficient integration testing, poor design, improper build or release procedures, etc managers should be notified and provided with some documentation as evidence of the problem.
If you face any challenges with these Manual Testing interview questions, please comment on your problems in the section below.
It’s possible that a requirement stack is not available for a piece of product. It might take serious effort to determine if an application has significant unexpected functionality, and it would indicate deeper problems in the software development process. If the functionality isn’t necessary to the purpose of the application, it should be removed. Else, create a test plan based on the assumptions made about the product. But make sure you get all assumptions well documented in the test plan.
This is a very common problem in the software industry, especially considering the new technologies that are being incorporated when developing the product. There is no easy solution in this situation, you could:
• Hire good and skilled people
• Management should ‘ruthlessly prioritize’ quality issues and maintain focus on the customer
• Everyone in the organization should be clear on what ‘quality’ means to the end-user
A cause-effect graph, also known as a cause-and-effect diagram or Ishikawa diagram, is a visual tool used for problem-solving and root cause analysis. It was developed by Japanese quality control expert Kaoru Ishikawa and is often referred to as the “fishbone diagram” due to its resemblance to a fish skeleton.
The diagram helps identify and explore the potential causes leading to a particular problem or effect. It’s particularly useful in understanding the complex relationships between various factors that contribute to an issue. The main components of a cause-effect graph include:
1. Effect: The problem or issue you’re trying to address is placed at the head of the diagram.
2. Major Causes: These are the main categories of factors that could contribute to the problem. They are typically categorized into branches stemming from the main horizontal line (the “spine” of the fishbone).
3. Sub-causes: Each major cause is further broken down into sub-causes or specific factors that could be contributing to the problem. These are detailed within the branches of the diagram.
Automated testing can be considered over manual testing during the following situations:
Every high-functioning organization has a “master plan” that details how they are supposed to operate and accomplish tasks. Software development and testing are no different. Software configuration management (SCM) is a set of processes, policies, and tools that organize, control, coordinate, and track:
In system testing, all the components of the software are tested as a whole in order to ensure that the overall product meets the requirements specified. So, no. The system testing must start only if all units are in place and are working properly. System testing usually happens before the UAT (User Acceptance Testing).
Few guidelines that you need to follow while writing test cases are:
The reason why boundary value analysis provides good test cases is that usually, a greater number of errors occur at the boundaries rather than in the center of the input domain for a test.
In boundary value analysis technique test cases are designed to include values at the boundaries. If the input is within the boundary value, it is considered ‘Positive testing.’ If the input is outside of the boundary value, it is considered ‘Negative testing.’ It includes maximum, minimum, inside or outside edge, typical values or error values.
Let’s suppose you are testing for an input box that accepts numbers from ’01 to 10′.
Using the boundary value analysis we can define three classes of test cases:
So the boundary values would be 0, 1, 2 and 9, 10, 11.
It is impossible to build a software product that is 100% bug-free. You can just minimize the error, flaw, failure, or fault in a computer program or system that causes it to produce an incorrect or unexpected result.
Here are the two principal reasons that make it impossible to test a program entirely.
Automation testing isn’t a replacement for manual testing. No matter how good automated tests are, you cannot automate everything. Manual tests play an important role in software development and come in handy whenever you have a case where you cannot use automation. Automated and manual testing each have their own strengths and weaknesses. Manual testing helps us understand the entire problem and more flexibly explore other angles of tests. On the other hand, automated testing helps save time in the long run by accomplishing a large number of surface-level tests in a short time.
That’s it, folks! We have reached the end of this ‘Manual Testing Interview Questions.’ You could also look at Automation Testing Interview Questions while you’re at it.
If you found this article relevant, check out the Selenium Certification by Edureka, a trusted online learning company with a network of more than 250,000 satisfied learners spread across the globe.
Got a question for us? Please mention it in the comments section on this “Manual Testing Interview Questions,” and we will get back to you.
Course Name | Date | |
---|---|---|
Selenium Certification Training Course | Class Starts on 30th September,2023 30th September SAT&SUN (Weekend Batch) | View Details |
Selenium Certification Training Course | Class Starts on 23rd October,2023 23rd October MON-FRI (Weekday Batch) | View Details |
Selenium Certification Training Course | Class Starts on 28th October,2023 28th October SAT&SUN (Weekend Batch) | View Details |
edureka.co