Software Testing Interview Questions

A- Software testing is a process used to identify the correctness, completeness, and quality of developed computer software. In other words software testing is an activity to check whether the actual results match the expected results and to ensure that the software system is defect free.

Q) What is need software testing?

A- There are many reasons that we need software testing-

To check the reliability of the software. To be ensured that the software does not contain any bug which can become a reason for failure. To check the software was made according to its specification. To check that the software meets its requirements. To check that users are capable of using the software. To check software works with other software and hardware it needs to work with

Q) What are the types of testing?

A-

Black Box Testing

White box Testing

Gray Box Testing

Q) What is White box testing?

A- White box testing is a process of testing in which we do code level testing. White box testing is performed based on the knowledge of how the system is implemented. White box testing includes analyzing data flow, control flow, information flow, coding practices, and exception and error handling within the system. White box testing requires access to the source code. Though white box testing can be performed any time in the life cycle after the code is developed, it is a good practice to perform white box testing during the unit testing phase.

Q) What is Black Box testing?

A- Black-box testing is a method of testing that examines the functionality of an application (e.g. what the software does) without knowing the internal structure of the application.

The types of testing under this strategy are totally based/focused on the testing for requirements and functionality of the work product/software application.

Q) What is Gray Box testing?

A- Gray Box Testing is a software testing method which is a combination of Black Box Testing method and White Box Testing method. In Black Box Testing, the internal structure of the item being tested is unknown to the tester and in White Box Testing the internal structure in known. In Gray Box Testing, the internal structure is partially known. This involves having access to internal data structures and algorithms for purposes of designing the test cases, but testing at the user, or black-box level.

Gray Box Testing is named so because the software program, in the eyes of the tester is like a gray/semi-transparent box; inside which one can partially see.
EXAMPLE

An example of Gray Box Testing would be when the codes for two units/modules are studied (White Box Testing method) for designing test cases and actual tests are conducted using the exposed interfaces (Black Box Testing method).

Q) What is Alpha testing?

A- Alpha testing is executed after completion of the formal test plan, but before the software is deployed in the market, and this can encompass white box as well as black box testing. The purpose of alpha testing is to measure the real users’ abilities to use and navigate the software application, and this is typically performed by internal employees and done in a lab environment so that user actions can be measured and analyzed.

Q) What is Beta testing?

A- Beta testing comes after alpha testing and primarily utilizes black box tactics. Beta testing is where real users outside the organization are solicited to play around with the software. This is normally the final “check and balance” system before the software is released en masse, although sometimes the beta version of a software application is released to the general public during this phase. This process helps identify and mitigate defects that were missed during the formal test plan, and helps configure the customer support resources and processes that will be needed post-launch.

Q) Who does white box testing?

A- White box testing is done by both Developer & tester. But tester should have coding knowledge. White box testing helps testers to find the location of bugs! When they look inside the code. Testers find the location of bugs, where the bug is & Developer debugs & fixes the bug .Finds why the bug has occurred. White box testing helps the tester to write test cases, remove unnecessary test cases, and add more required test cases which can cause the software to crash.

Q) What is unit testing?

A- The primary goal of unit testing is to take the smallest piece of testable software in the application, isolate it from the remainder of the code, and determine whether it behaves exactly as you expect. Each unit is tested separately before integrating them into modules to test the interfaces between modules. Unit testing has proven its value in that a large percentage of defects are identified during its use.

Unit Testing is a level of the software testing process where individual units/components of a software/system are tested. The purpose is to validate that each unit of the software performs as designed.

Q) Who does unit testing?

A- Unit tests should ideally be the Developer’s responsibility, since the tests are designed to validate methods/functionality as designed/desired by the developer. They would be short tests to validate that what he/she meant to do, is indeed what the code is doing.

In addition, changes to the code will be made by the developer in most cases, so it would be his /her responsibility to ensure that the unit tests are updated and reflect accurately the intended changes.

A- Agile as the name refers implies something to do very quickly. Hence Agile Testing refers to validate the client requirements as soon as possible and make it customer friendly. As soon as the build is out, testing is expected to get started and report the bugs quickly if any found. As a Tester, you need to provide your thoughts on the client requirements rather than just being in the audience at the other end. Emphasis has to be laid down on the quality of the deliverable in spite of short time frame which will further help in reducing the cost of development and your feed backs will be implemented in the code which will avoid the defects coming from the end user.

A- When there are some minor issues with software and a new build is obtained after fixing the issues then instead of doing complete regression testing a sanity is performed on that build. You can say that sanity testing is a subset of regression testing.

Sanity testing is done after thorough regression testing is over, it is done to make sure that any defect fixes or changes after regression testing does not break the core functionality of the product. It is done towards the end of the product release phase.

Sanity testing follows a narrow and deep approach with detailed testing of some limited features.

Sanity testing is like doing some specialized testing which is used to find problems in particular functionality.

Sanity testing is done with an intent to verify that end user requirements are met with not.

Sanity tests are mostly non scripted.

Q) What is Smoke testing?

A- In software testing, a smoke test is a collection of written tests that are performed on a system prior to being accepted for further testing. This is also known as a build verification test.

Smoke test refers to the first test made after repairs or first assembly to provide some assurance that the system under test will not catastrophically fail. This is a “shallow and wide” approach to the application. The tester “touches” all areas of the application without getting too deep, looking for answers to basic questions like, “Can I launch the test item at all?”, “Does it open to a window?”, “Do the buttons on the window do things?”. There is no need to get down to field validation or business flows. If you get a “No” answer to basic questions like these, then the application is so badly broken, there’s effectively nothing there to allow further testing.

Q) What is Integration testing?

A- In integration testing the individual tested units are grouped as one and the interface between them is tested. Integration testing identifies the problems that occur when the individual units are combined i.e. it detects the problem in the interface of the two units. Integration testing is done after unit testing.

There are mainly three approaches to do integration testing.

Top-down Approach

Top down approach tests the integration from top to bottom, it follows the architectural structure.

Example: Integration can start with GUI and the missing components will be substituted by stubs and integration will go on.

Bottom-up approach

In the bottom up approach testing takes place from the bottom of the control flow, the higher level components are substituted with drivers

Big bang approach

With the big bang approach most or all of the developed modules are coupled together to form a complete system and then used for integration testing.

Q) What is Regression testing?

A- Regression testing is the process of testing changes to computer programs to make sure that the older programming still works with the new changes. Regression testing is a normal part of the program development process and, in larger companies, is done by code testing specialists. Test department coders develop code test scenarios and exercises that will test new units of code after they have been written. These test cases form what becomes the test bucket. Before a new version of a software product is released, the old test cases are run against the new version to make sure that all the old capabilities still work. The reason they might not work is because changing or adding new code to a program can easily introduce errors into code that is not intended to be changed.

Q) What is the difference between regression and retesting?

A-

Re-Testing: Testing some functions, Feature or module again and again is called re-testing. It is usually done using a different set of data each time. Example: like if you are testing some login form with different combination of data then it is Re-testing. This term is generally used when we perform the test (re-test) after some changes (changes can be either in the form of Bug fixing or enhancement).

Regression testing: It is same as re-testing but it is done to check if any changes made to code (again it can be bug fixing, enhancement or some code clean up) doesn’t bring some abnormal changes to other un-changed part.

See Re-testing is regression testing in itself but just differ in the intent it used to perform.

Lets take an example:

There is project P. It has some modules say M1, M2, M3…. And so on Now you found some bug in M2 (or there are some changes in any form)

Now after bug fixing when you test M2 to verify that bug is called Re-testing but when you test M1 & M3 (or other modules as well) then it is called Regression testing because here you are testing for some IMPACT that M2 is making on M1 & M3.

A- A software bug is an error in the program that prevents it from operating properly. Some bugs may only affect a program under specific circumstances. Others may be more serious and cause the program to be unstable or even unusable. A simple mistake in the software code can cause major problems. For example, if the programmer accidentally coded a program to multiply two numbers together when it should only add them, the rest of the program will give a faulty result.

Q) What is the difference between bug and defect?

A- A bug is getting a problem at the time of testing, whereas a defect is a problem that got from the customer in production time. A bug is a fault in a program which causes it to behave abruptly. Bugs are usually found either during unit testing done by the developer of module testing by testers. A defect is found when the application does not conform to the requirement specification. A defect can also be found when the client or user is testing.

In boundary value analysis we check the range of the values. We select the set of data and check how the application behaves. For each range we set upper and lower boundaries. If an application gives the expected result after giving the upper and lower values than we make sure the application will work for all the values given.

For ex-

A user ID text box has to accept alphabet characters ( a-z ) with a length of 4 to 10 characters.

BVA is done like this, max value:10 pass; max-1: 9 pass;

max+1=11 fail ;min=4 pass;min+1=5 pass;min-1=3 fail;

Like wise we check the corner values and come out with a conclusion whether the application is accepting correct range of values.

Equivalence testing is normally used to check the type of the object.

Ex. A user ID text box has to accept alphabet characters ( a – z ) with length of 4 to 10 characters.

In +ve condition we have test the object by giving alphabets. i.e a-z char only, after that we need to check whether the object accepts the value, it will pass.

In -ve condition we have to test by giving other than alphabets (a-z) i.e A-Z,0-9,blank etc, it will fail.

Q) What is equivalence partitioning?

A- Dividing the test input data into a range of values and selecting one input value from each range is called Equivalence Partitioning. This is a black box test design technique used to calculate the effectiveness of test cases and which can be applied to all levels of testing from unit, integration, system testing and so forth.

We cannot test all the possible input domain values, because if we attempted this, the number of test cases would be too large. In this method, input data is divided into different classes, each class representing the input criteria from the equivalence class. We then select one input from each class.

This technique is used to reduce an infinite number of test cases to a finite number, while ensuring that the selected test cases are still effective test cases which will cover all possible scenarios.

Let’s take a very basic and simple example to understand the Equivalence partitioning concept:

If one application is accepting input range from 1 to 100, using equivalence class we can divide inputs into the classes, for example, one for valid input and another for invalid input and design one test case from each class.

In this example test cases are chosen as below:

One is for valid input class i.e. selects any value from input between ranges 1 to 100. So here we are not writing hundreds of test cases for each value. Any one value from this equivalence class should give you the same result.

A- System testing is performed after integration testing. Using system testing we verify the functionality of the whole application. Also by performing system testing as whole we confirm the system or software is fulfilling all the functional and non-functional requirements.

Q) What is Performance testing?

A- Using performance testing we check the performance, behavior, stability and scalability of the application.

Performance testing is very important and assure that the application is ready to go to market. Without performance testing, software is likely to suffer from issues such as: running slow while several users use it simultaneously, inconsistencies across different operating systems and poor usability. Performance testing will determine whether or not their software meets speed, scalability and stability requirements under expected workloads. Applications sent to market with poor performance metrics due to nonexistent or poor performance testing are likely to gain a bad reputation and fail to meet expected sales goals. Also, mission critical applications like space launch programs or lifesaving medical equipment should be performance tested to ensure that they run for a long period of time without deviations.

Q) What is Load testing?

A– Load testing is nothing but monitoring the behavior of the application by different increasing or decreasing load on the application. Increasing or decreasing number of loads mean increasing or decreasing number of users. So using load test we confirm application is behaving as expected even after increasing or decreasing loads on the server. Generally load testing is performed by automation tools such as Jmeter or Neoload etc.

Q) What is Test metrics?

A-

The objective of Test Metrics is to capture the planned and actual quantities the effort, time and resources required to complete all the phases of Testing of the Software Project, software Metric is a measure of some property of a piece of software or its specification. Metrics generally of 2 types: (1) Process Metric & (2) Product Metric

Process Metric: Measuring the characteristics of the method, tools and techniques employed in developing, implementing and maintaining the software system.

Product Metric: A metric used to measure the characteristics of the documentation & code.

Q) What is Test plan?

A-

Test plan: A document describing the scope, approach, resources and schedule of intended test activities. It identifies amongst others test items, the features to be tested, the testing tasks, who will do each task, degree of tester independence, the test environment, the test design techniques and entry and exit criteria to be used, and the rationale for their choice, and any risks requiring contingency planning. It is a record of the test planning process.

A- Whenever we do some changes in the application or software we send the release details to the user of to our team members that describe what additional feature are added or if any bug has been fixed. Also sometimes we keep tracking information in release details so that if any changes have to be done next time we can track a review that what changes were done on last release.

Q) What is negative testing?

A- Ensures that your application can gracefully handle invalid input or unexpected user behavior. For example, if a user tries to type a letter in a numeric field, the correct behavior in this case would be to display the “Incorrect data type, please enter a number” message. The purpose of negative testing is to detect such situations and prevent applications from crashing. Also, negative testing helps you improve the quality of your application and find its weak points.

Q) What is usability testing?

A- Usability testing is a technique used in user-cantered interaction design to evaluate a product by testing it on users. This can be seen as an irreplaceable usability practice, since it gives direct input on how real users use the system. This is in contrast with usability inspection methods where experts use different methods to evaluate a user interface without involving users.

Usability testing focuses on measuring a human-made product’s capacity to meet its intended purpose. Examples of products that commonly benefit from usability testing are foods, consumer products, web sites or web applications, computer interfaces, documents, and devices. Usability testing measures the usability, or ease of use, of a specific object or set of objects, whereas general human-computer interaction studies attempt to formulate universal principles.

Q) What is difference between bug defect and error?

A–

Bug: Assume that the programmer has actually understood the intended requirement correctly but has declared/stored the result as an integer to show a result of 5 instead of 5.75 – this is called a Bug. Here the programmer has to declare the variable as “double or float” and not “int”.

Defect: A defect is any of the above but found/un-covered in the “released-application” – running in the “Production Servers” [gone “Live”] or may be in “Beta-Release”.

“Defect Trackers” have been christened as such, because they are used to report “Defects” in the software post-release; whereas the issues reported by the Testing Team are predominantly called “Incident Reports” and not “Defect Reports”!

However each organization follows its own terminologies for different contexts and processes; many individuals, may want to contradict and confront me with his/her opinion, on this. But that is a fact-of-life in Software Industry and an Occupational Hazard at that!!!

Error: When the application runs without any issues in the intended Production Environment under normal circumstances, but misbehaves after continuously running for about a month or after performing about a million transactions, then we call this condition as Error.

Let me explain this with an example – Let’s say an ‘Order Entry cum Processing’ application has been deployed in a server accessed by public to place orders for movie tickets. Initially when the application starts running – that is when the Application Server is re-started with old log files trashed/removed – the application runs with a throughput of 100 transactions per minute. But after about one million transactions, if the application’s throughput reduces to about 50 transactions per minute, then, we call this condition as an Error.

Q) What is testing tool?

A- We use testing tool to automate software testing. It makes easy testing and report could be generated automatically. There are several tools that could be used to test unit testing, functional testing, load testing etc.

Q) What is End to End testing?

A- End-to-End Testing is when you take a process from the very beginning all the way to the end – like accepting an order from a customer and then processing that order all the way through fulfilment, accounting and shipping. This is basically exercising an entire “workflow”. Although System Testing is similar, in System Testing you do not have to complete the entire workflow but may exercise individual interfaces one at a time. However by the end of System Testing most test environments will exercise (or should exercise) an entire end-to-end test.

A– In validation we confirm we are doing the right thing. In simple word we can say Validation ensures that functionality, as defined in requirements, is the intended behavior of the product; validation typically involves actual testing and takes place after verifications are completed.

Q) What is verification?

A- In verification we confirm we are doing the thing right. In simple word we can say Verification makes sure that the product is designed to deliver all functionality to the customer; it includes reviews and meetings to evaluate documents, plans, code, requirements and specifications; this can be done with checklists, walkthroughs, inspection meetings, etc.

Q) Give the example of Verification and Validation?

A- Example: Let’s say we are writing a program for addition. a+b = c

Verification: Are we getting some output for a+b? 1+1 = 6Validation: Are we getting correct output for a+b? 1+1=2?

Verification basically asks if the program is correct. To use your simple example, a=x + Y is correct if x=1 and y=2 yields a = 3.

Validation asks if the correct program was produced. For example, calculate the area of a rectangle with length x and width y. If x=1 and y =2, the result should be 2. The first program is correct but not valid given the requirement. It is not the right program.

Q) What is Ad-Hoc testing?

A- Ad-Hoc testing is the process of testing in which testing is performed without any plan or test cases. In this testing process we don’t follow any rules. So this testing is generally followed by the tester who has good knowledge about the product which tester is going to test.

Q) What is compatibility testing?

A–

Using the compatibility test we test and confirm whether software is compatible with other elements of a system with which it should operate, e.g. browsers, Operating Systems, or hardware

Compatibility testing means the application is test with software and hardware site. Software site than “How can working for different browsers and operating systems” and Hardware based testing into Changed for configuration for resource.

Test the application is worked in different environmental is called compatibility. Ex: test app will work in diff browsers and different OS.

A- Security testing is the testing the application for unauthorized access. Means application should not be accessible without proper authentication and authorization. And Smoke Testing is the testing an application for testability. In Smoke testing we check whether the application is capable enough to test further or not.

Security testing is perhaps the most conclusive determinant of whether a system is configured and continues to be configured to the correct security controls and policy. If the following testing activities are followed they can be highly cost-effective in preventing incidents and uncovering unknown vulnerabilities.

Q) What is top down approach?

A- Top down Testing is an approach to integrated testing where the top integrated modules are tested and the branch of the module is tested step by step until the end of the related module. This allows high-level logic and data flow to be tested early in the process and it tends to minimize the need for drivers. However, the need for stubs complicates test management and low-level utilities are tested relatively late in the development cycle.

Advantages

The advantages of top down testing can be

Does not require drivers to be written

Provides early working module of the program and so design defects can be found and corrected early

Disadvantages

The disadvantages can be summarized as

It enables testing only for the limited functionality

Stubs are required in a way that it takes care of the integrated functionality

Performed by Developers, which wastes time.

Q) What is bottom up approach?

A- Bottom Up testing is an approach to integrated 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.

Advantages

The advantages of the Bottom-Up Testing are:

The objects to be tested are known to the developer. So, it is easy to understand the scope of the test case creation and test data.

Psychologically more satisfying because the tester can be certain that the foundations for the test objects have been tested in full detail.

Does not require stubs to be created

Disadvantages

The disadvantages are summarized below:

The quality of the software can be guaranteed only when the testing is fully completed. Issue is, defects in the upper levels are detected very late.

Drivers creates complication in the test management.

Testing individual levels also inflicts high costs for providing a suitable test environment.

Q) What is acceptance testing?

A- Acceptance testing is a final stage of testing that is performed on a system prior to the system being delivered to a live environment. Systems subjected to acceptance testing might include such deliverables as a software system or a mechanical hardware system. Acceptance tests are generally performed as “black box” tests. Black box testing means that the tester uses specified inputs into the system and verifies that the resulting outputs are correct, without knowledge of the system’s internal workings.

User acceptance testing (UAT), is the term used when the acceptance tests are performed by the person or persons who will be using the live system once it is delivered. If the system is being built or developed by an external supplier, this is sometimes called customer acceptance testing (CAT). The UAT or CAT acts as a final confirmation that the system is ready for go-live. A successful acceptance test at this stage may be a contractual requirement prior to the system being signed off by the client.

In some industries, such as manufacturing, factory acceptance testing (FAT), is the term usually used for the formal acceptance test stage. A factory acceptance test may be performed by the vendor or supplier of the system and observed by the client. This is often done in a very formal manner, with each factory or site acceptance test being documented in detail, and each portion of the test signed off.

Q) What is test scenario?

A- Test scenario is the approach to created step by step process to reproduce the issues so that anyone could easily understand and could reproduce the bugs by following the steps.

Q) What is walkthrough?

A- Walkthrough is overall idea of an application. Before development or testing we just walk through or discuss about possible errors, violation of development standards, and other problems present the documents both within and outside the software discipline in order to gather the information regarding the topic under documentation. The goal of walk through is to explain or do the knowledge transfer and evaluate the contents of the document .To achieve a common understanding and to gather feedback. To examine and discuss the validity of the proposed solutions.

Q) What is the purpose of the testing?

A- Software testing provide and assure the quality of the product whether it is usable or not. Also it assures the software meets the requirements or not. Analyzing and finding the bugs and reporting to the development can make the software more usable, reliable and compatible.

Q) How do you scope, organize, and execute a test project?

A-

To SCOPE the project-

1) Learn as much about the application as possible by studding the Business Requirements Document (BRD), Technical Specifications, Work-Flow Diagrams, Wireframes, System Architectural Diagrams, Marketing and Legal documents, and any other relevant information that is available. 2) Request additional information from expert stakeholders internal and external to the company if necessary. 3) Estimate the amount of time it will take to create test cases and to execute them. 4) Determine how the test environment should be configured. 5) Determine whether any test tools are needed. 6) Create a Test Plan that covers test strategies, test scope, etc. 7) Request that expert stakeholders review my Test Plan and provide feedback to improve it. 8) Revise the Test Plan.

To ORGANIZE the project-

1) Break the application down into functional areas. 2) Create a test suite that includes folders for each functional area to be tested. 3) Create test cases corresponding to each functional area and place them under their proper folders. 4) Map the requirements to test cases. 5) Prioritize the test cases.

To EXECUTE the project –

1) Ensure the test environment is ready for test. 2) Ensure the test tools are ready for test. 3) Ensure I have all supporting documentation required for testing. 4) Access my test suite and begin testing!

Q) How do you determine what to test?

A- It depends on the specification given for the application. Before determining what to test we need to understand the project or module thoroughly so that we could understand the dependencies of the module on other modules or project. Also first we should try to determine the production level impact of the module and then we could decide which part of the module should be tested first.

A- QA is involved in the project from the beginning. This helps the teams communicate and understand the problems and concerns, also gives time to set up the testing environment and configuration. On the other hand, actual testing starts after the test plans are written, reviewed and approved based on the design documentation.

Q) What is the difference between a test strategy and test planning?

A-

A Test Strategy is a higher-level document, it defines the overall scope of a test project, the overall approach, the levels of testing to be performed, the procedures to be followed, the tools to be used, the reporting structure, and the key stakeholders. It sets the scene and defines all the material that would otherwise need to be repeated across each individual Test Plan. The real aim of the Test Strategy though is to get ‘buy-in‘ from all the stakeholders. You can have a test strategy across the whole project that defines the levels of testing, e.g., unit, integration, systems defining what is to occur at each level. This is often an enterprise wide standard in large organizations. You can also have a level specific test strategy, e.g., a test strategy just for systems testing, this would happen when you have a large project and the particular testing level may require multiple test plans.

A Test Plan provides more detail about the particular items and their features to be tested. It describes the approach to be taken to testing those features, the schedule, the resources, the pass/fail criteria for those features.

In cases where you do not need to prepare a separate Test Strategy document the information is instead incorporated into the Test Plan. Every project must have a strategy.

Q) How do you decide when you have tested enough?

A- Testing is a never ending process. Testing can be stopped when maximum number of test cases are executed and have been passed, when deadlines are reached, when testing budget depletes, when basic functionalities are working.

This is usually not a difficult decision. When all critical, serious and blocking issues have been fixed we have to test until the product is shipped and even after. The testing cycle is an endless process. Only the type of testing might vary from one stage to another in the development cycle of the product.

Q) What is test log?

A- A test log is nothing but, what are the test cases we have been executed, in what order we executed, who executed that test cases and what is the status of the test case(pass/fail).

A- Stress testing is a form of testing that is used to determine the stability of a given system or entity. It involves testing beyond normal operational capacity, often to a breaking point, in order toobserve the results.

Q) What is a Software bug?

A-

A software bug is the common term used to describe an error, flaw, mistake, failure, or fault in a computer program or system that produces an incorrect or unexpected result, or causes it to behave in unintended ways.

Q) What is unit testing?

A-

Unit testing is a method by which individual units of source code are tested to determine if they are fit for use. A unit is the smallest testable part of an application.