Interview questions manual testing software

UAT: User Acceptance Testing UAT involves running a product through a series of specific tests which determines whether the product will meet the needs of its users. Retesting: It is a process of checking bugs that are actioned by the development team to verify that they are fixed.

The application is tested with a different set of values. Test Scenarios: A Test Scenario is any functionality that can be tested. It is also called Test Condition or Test Possibility. Test Cases: It is a document that contains the steps that have to be executed; it has been planned earlier.

In other words a written set of steps that should be performed manually. Latent defect: This defect is an existing defect in the system which does not cause any failure as the exact set of conditions has never been met. Phantom is a freeware and is used for windows GUI automation scripting language. It allows us to take control of windows and functions automatically.

It can simulate any combination of keystrokes and mouse clicks as well as menus, lists and more. Test Deliverables are a set of documents, tools and other components that have to be developed and maintained in support of testing.

When the presence of one defect hides the presence of another defect in the system, it is known as fault masking. This will resolve the issue and hide the defect of unhandled exception firing. A test plan can be defined as a document describing the scope, approach, resources, and schedule of testing activities and a test plan should cover the following details. It helps you to eliminate product risk in your project, and there is a simple yet crucial step that can reduce the product risk in your project.

To get an expected test outcome, a standard procedure is followed which is referred to as Testing Type. SQA focusses more on the software process rather than the software work products. It is a set of activities designed to make sure that the project manager follows the standard process. SQA helps test manager to benchmark the project against the set standards. RTM is prepared before test case designing. Requirements should be traceable from review activities. Test Matrix : Test matrix is used to capture actual quality, effort, the plan, resources and time required to capture all phases of software testing.

Traceability Matrix : Mapping between test cases and customer requirements is known as Traceability Matrix. Both stubs and drivers are part of incremental testing. In incremental testing, there are two approaches namely bottom-up and top-down approach. Drivers are used in bottom-up testing and stub is used for a top-down approach. In order to test the main module, the stub is used, which is a dummy code or program. The key words control the processing. It is also used for the visualization of data processing.

The cycle is repeated unless there are no errors found. Fuzz testing is used to detect security loopholes and coding errors in software. In this technique, random data is added to the system in an attempt to crash the system. If vulnerability persists, a tool called fuzz tester is used to determine potential causes. This technique is more useful for bigger projects but only detects a major fault.

None of the characters should get truncated. Junk characters should not be added. The code coverage testing tool runs parallel while performing testing on the actual product. The code coverage tool monitors the executed statements of the source code.

When the final testing is done, we get a complete report of the pending statements and also get the coverage percentage. In simple terms when a defect reaches the end customer, it is called a failure while the defect is identified internally and resolved; then it is referred to as a defect.

Black box test cases are written first as to write black box test cases; it requires project plan and requirement document all these documents are easily available at the beginning of the project. While writing white box test cases requires more architectural understanding and is not available at the start of the project. Bottom-up testing is an approach to integration testing, where the lowest level components are tested first, then used to facilitate the testing of higher level components.

The process is repeated until the component at the top of the hierarchy is tested. Breath testing is a test suite that exercises the full functionality of a product but does not test features in detail.

Code Walk Through is the informal analysis of the program source code to find defects and verify coding techniques.

End-to-end testing is done after functional testing. The purpose behind doing end-to-end testing is that. A test harness is configuring a set of tools and test data to test an application in various conditions, and it involves monitoring the output with expected output for correctness. Risk-based Testing is the term used for an approach to creating a Test Strategy that is based on prioritizing tests by risk. The basis of the approach is a detailed risk analysis and prioritizing of risks by risk level.

When a defect is not identified or goes unnoticed while testing, it invokes other defects. It leads to multiple defects in the later stages and results in an increase in a number of defects in the application. A walkthrough is an informal meeting conducts to learn, gain understanding, and find defects.

The author leads the meeting and clarifies the queries raised by the peers in the meeting. Inspection is a formal meeting lead by a trained moderator, certainly not by the author. The document under inspection is prepared and checked thoroughly by the reviewers before the meeting.

In the inspection meeting, the defects found are logged and shared with the author for appropriate actions. Post inspection, a formal follow-up process is used to ensure a timely and corrective action. The variation between the actual results and expected results is known as a defect. If a developer unable to successfully compile or run a program then they call it as an error. Once the product is deployed and customers find any issues then they call the product as a failure product.

After release, if an end user finds an issue then that particular issue is called as a failure. It can be Critical, Major or Minor. In simple words, how much effect will be there on the system because of a particular defect.

Defect priority can be defined as how soon the defect should be fixed. It gives the order in which a defect should be resolved. Developers decide which defect they should take up next based on the priority. It can be High, Medium or Low. Most of the times the priority status is set based on the customer requirement. A critical bug is a show stopper which means a large piece of functionality or major system component is completely broken and there is no workaround to move further.

For example, Due to a bug in one module, we cannot test the other modules because that blocker bug has blocked other modules. Bugs which affects the customers business are considered as critical. An error message pops up when a customer clicks on transfer money button in a Banking website.

Standalone applications follow one-tier architecture. Presentation, Business, and Database layer are in one system for a single user. Client-server applications follow two-tier architecture. Presentation and Business layer are in a client system and Database layer on another server. It works majorly in Intranet. Web server applications follow three-tier or n-tier architecture.

The presentation layer is in a client system, a Business layer is in an application server and Database layer is in a Database server. It works both in Intranet and Internet. Bug life cycle is also known as Defect life cycle. In Software Development process, the bug has a life cycle. The bug should go through the life cycle to be closed. A bug which is actually missed by the testing team while testing and the build was released to the Production.

If now that bug which was missed by the testing team was found by the end user or customer then we call it as Bug Leakage. Releasing the software to the Production with the known bugs then we call it as Bug Release. These known bugs should be included in the release note. Defect age can be defined as the time interval between date of defect detection and date of defect closure.

Assume, a tester found a bug and reported it on 1 Jan and it was successfully fixed on 5 Jan So the defect age is 5 days. Error seeding is a process of adding known errors intendedly in a program to identify the rate of error detection. It helps in the process of estimating the tester skills of finding bugs and also to know the ability of the application how well the application is working when it has errors.

Error guessing is also a method of test case design similar to error seeding. In error guessing, testers design test cases by guessing the possible errors that might occur in the software application.

The intention is to catch the errors immediately. Assume that login button is not working. Even though you have a valid username and valid password, you could not move further because the login button is not functioning. At times, a build executed in the production evironment would have some critical errors and it would be rolled back. Now development team kept all their work aside and focus on fixing these errors immediately and release a new build to fix that in the production.

This build is referred as a hotfix. Patches and hotfixes are two distinct types of software updates. Patches are available to the public, while hotfixes are not. A bugfix is a build aimed at resolving a bug which is detected by the testers in the testing cycle. A bug bounty program lets an organization offer reward to a person who find errors in their software and report them. Bug bounty is a concept that has existed since the internet was created. Companies started to understand how expensive it is for them to hire experts in penetration testing every time they want to find vulnerabilities on their website or application.

So recently, bug bounty programs become mainstream. The first company to catch on to this concept was Google. There are four strategies to be followed for the rollout of any software testing project are as follows:. Boundary value analysis BVA is based on testing the boundary values of valid and invalid partitions.

The Behavior at the edge of each equivalence partition is more likely to be incorrect than the behavior within the partition, so boundaries are an area where testing is likely to yield defects. Every partition has its maximum and minimum values and these maximum and minimum values are the boundary values of a partition. A boundary value for a valid partition is a valid boundary value. Similarly, a boundary value for an invalid partition is an invalid boundary value.

Equivalence Partitioning is also known as Equivalence Class Partitioning. In equivalence partitioning, inputs to the software or system are divided into groups that are expected to exhibit similar behavior, so they are likely to be proposed in the same way. Hence selecting one input from each group to design the test cases. Decision Table is aka Cause-Effect Table. This test technique is appropriate for functionalities which has logical relationships between inputs if-else logic.

In the Decision table technique, we deal with combinations of inputs. To identify the test cases with a decision table, we consider conditions and actions. We take conditions as inputs and actions as outputs. Using state transition testing, we pick test cases from an application where we need to test different system transitions. We can apply this when an application gives a different output for the same input, depending on what has happened in the earlier state.

The prerequisites that must be achieved before commencing the testing process. The conditions that must be met before testing should be concluded. Software Development Life Cycle SDLC aims to produce a high-quality system that meets or exceeds customer expectations, works effectively and efficiently in the current and planned information technology infrastructure, and is inexpensive to maintain and cost-effective to enhance.

We can do System Testing only when all the units are in place and working properly. Manual testing is crucial for testing software applications more thoroughly. The procedure of manual testing comprises of the following. Planning and Control 2. Analysis and Design 3. Implementation and Execution 4. Evaluating and Reporting 5. Test Closure activities. Even though testing differs between Organizations, there is a testing life cycle. Requirements Traceability Matrix RTM is used to trace the requirements to the tests that are needed to verify whether the requirements are fulfilled.

We have to ensure that every requirement has atleast 1 test case. Software test metrics is to monitor and control process and product. It helps to drive the project towards our planned goals without deviation. Metrics answer different questions.

API testing is a type of software testing that involves testing APIs directly and also as a part of integration testing to check whether the API meets expectations in terms of functionality, reliability, performance, and security of an application. Prerequisites to start writing black-box test cases are Requirement documents or design documents. These documents will be available before initiating a project.

Prerequisites to start writing white box test cases are the internal architecture of the application. The internal architecture of the application will be available in the later part of the project i.

Workbench is a practice of documenting how a specific activity must be performed. It is often referred to as phases, steps, and tasks. In random testing is a form of black-box software testing technique where the application is testing by generating random data. After reading this Interview Questions for Manual Testing, if you find that we missed some important questions, please comment below we would try to include those with answers.

Here I have hand-picked a few posts which will help you to learn more interview related stuff along with these interview questions on manual testing. If you have any more manual interview questions, feel free to ask via comments. If you find this post useful, do share it with your friends on Social Networking.

He has extensive experience in the field of Software Testing. Furthermore, he loves to be with his wife and a cute little kid 'Freedom'. Sure Shahi… we will do it. Could you please explain : 1. Testing process.. Challenges — for examples repeated testing which we overcome using automation tool 3. Bug life cycle is almost same in all the tools.. Raj Kumar you have done a great job.

You have covered every single topic from Manual Testing syllabus.. Your answer was right, but you need to give them the right logic as below: If HDFC net banking website Bank name is misspelled then it may leads to ward the doubt that the site is not authentic and we cant risk with login.

It may expose the login credentials to the frauds. So i will not take risk and avoid login to the portal. Hi, I have read your Manual Testing Materials. It looks like very helpful for the job seeker for preparing interview.

Thanks for helping out people by providing such a quality document. Good Work.. Hoping for some new tutorials on Tosca, UFT etc. I liked your blog and its have excellent information about Software testing.

It gathers data from the product description, requirement, and use case documents. Test coverage is a quality metric to represent the amount in percentage of testing completed for a product. It is relevant for both functional and non-functional testing activities.

This metric is used to add missing test cases. But you can follow the below steps to come closer. Many times, it is the developers who test individual units or modules to check if they are working correctly. Whereas, integration testing validates how well two or more units of software interact with each other.

System testing should start only if all modules are in place and they work correctly. However, it should be performed before UAT user acceptance testing. The test driver is a section of code that calls a software component under test. It is useful in testing that follows the bottom-up approach. The test stub is a dummy program that integrates with an application to complete its functionality. It is relevant for testing that uses the top-down approach.

It is favorable as it does not require the development team to complete coding for starting QA. Instead, both coding and testing go hand in hand. However, it may require continuous customer interaction. Data flow testing emphasizes for designing test cases that cover control flow paths around variable definitions and their uses in the modules.

It expects test cases to have the following attributes:. End-to-end testing is a testing strategy to execute tests that cover every possible flow of an application from its start to finish.

The objective of performing end-to-end tests is to discover software dependencies and to assert that the correct input is getting passed between various software modules and sub-systems. If the required specifications are not available for a product, then a test plan can be created based on the assumptions made about the product. But we should get all assumptions well-documented in the test plan.

It is suggested to perform a regression testing and run tests for all the other modules as well. Finally, the QA should also carry out a system testing.

If the standard documents like System Requirement Specification or Feature Description Document are not available, then QAs may have to rely on the following references, if available. Another reliable way is to have discussions with the developer and the business analyst. It helps in solving the doubts, and it opens a channel for bringing clarity on the requirements.

Also, the emails exchanged could be useful as a testing reference. Smoke testing is yet another option that would help verify the main functionality of the application. It would reveal some very basic bugs in the application.

If none of these work, then we can just test the application from our previous experiences. It tests the behavior of the software under test. Based on the requirement of the client, a document called a software specification or requirement specification is used as a guide to test the application. Based on quality, it is very critical to test these parameters. This type of testing is called non-functional testing.

Software testing life cycle STLC proposes the test execution in a planned and systematic manner. In the STLC model, many activities occur to improve the quality of the product. Fault is a condition that makes the software fail to execute while performing the considered function. A slip in coding is indicated as an error. The error spotted by a manual tester becomes a defect. The defect which the development team admits is known as a bug.

If a built code misses on the requirements, then it is a functional failure.