21
Explain Path Coverage.
This measure reports whether each of the possible paths in each function have been followed. A path is a unique sequence of branches from the function entry to the exit. Also known as predicate coverage. Predicate coverage views paths as possible combination of logical conditions.
22
Explain Race Coverage.
This measure reports whether multiple threads execute the same code at the same time. It helps detect failure to synchronize access to resources. It is useful for testing multi-threaded programs such as in an operating system.
23
Explain Relational Operator Coverage.
This measure reports whether boundary situations occur with relational operators (<, <=, >, >=). The hypothesis is that boundary test cases find off-by-one errors and mistaken uses of wrong relational operators such as < instead of <=. For example, consider the following C/C++ code fragment:if (a < b) statement; Relational operator coverage reports whether the situation a==b occurs. If a==b occurs and the program behaves correctly, you can assume the relational operator is not suppose to be <=.
24
Explain Statement Coverage.
This measure reports whether each executable statement is encountered. The chief advantage of this measure is that it can be applied directly to object code and does not require processing source code. Performance profilers commonly implement this measure. The chief disadvantage of statement coverage is that it is insensitive to some control structures. For example, consider the following C/C++ code fragment:Int* p = NULL;if (condition)p = &variable;*p = 123;Without a test case that causes condition to evaluate false, statement coverage rates this code fully covered. In fact, if condition ever evaluates false, this code fails. This is the most serious shortcoming of statement coverage. If-statements are very common.
25
What is stress testing?
Test conducted to evaluate a system or component at or beyond the limits of its specified requirements to determine the load under which it fails and how. Stress testing is testing that investigates the behavior of software (and hardware) under extraordinary operating conditions.
For example, when a web server is stress tested, testing aims to find out how many users can be on-line, at the same time, without crashing the server. Stress testing tests the stability of a given system or entity.
26
What is Security Testing?Security Testing: Testing which confirms that the program can restrict access to authorized personnel and that the authorized personnel can access the functions available to their security level. Security/penetration testing is testing how well the system is protected against unauthorized internal or external access, or willful damage. For example: Firewall Test, Port Scan, Internet Security, database security
27
What is regression testing?Testing repeatedly the same thing is called Regression. This happens when there exist a bug, reported to the Dev.team, fixed and given back to the Tester. Now the tester will test not only the bug fixed but also the other stuff which was right earlier. The reason to do this is, because of the fixing of the bug reported, there is a danger that this might have resulted somewhere else as a bug.So to make sure that when ever the new build is given to the Testing Team, the full cycle of testing will be carried out. That is testing the same which already tested. In other words 'Regression testing'.
28
What is Soak Testing?
Soak testing is running a system at high levels of load for prolonged periods of time. A soak test would normally execute several times more transactions in an entire day (or night) than would be expected in a busy day, to identify and performance problems that appear after a large number of transactions have been executed. Also, due to memory leaks and other defects, it is possible that a system may ‘stop’ working after a certain number of transactions have been processed. It is important to identify such situations in a test environment.
29
What is the difference between Product Testing and Application Testing?A product is developed software which is generic to all; the changes in the software will be made when the new requests/change requests raised by the client. Testing this type of product is known as product testing. A project is particularly or specifically related to one and only one client. Testing this application is known as project testing.
30
What is Database Testing?Testing the tables, data in tables, relationship between the tables, does the data is saved in a proper way in tables is known as database testing.
31
What is Configuration Testing?Testing whether the applications specified configuration is working properly or not, i.e the configurable details of the application.
32
Difference between UAT and Alpha testing and Beta testing.User Acceptance Testing (UAT): A formal product evaluation performed by a customer as a condition of purchase. The testing can be based upon the User Requirements Specification to which the system should conform. Use Acceptance testing is black box testing. User Acceptance Testing is the last stage of the Software Development Lifecycle. User acceptance testing we validating all the user requirements specified in SRS is met after code freeze. The acceptance test is the responsibility of the client/customer or project manager; however, it is conducted with the full support of the project team. Before the software goes live determining if software is satisfactory to an end-user or customer. Alpha testing is done during software development to test changes and new features of the software. The purpose of alpha testing is to check the operation of the code in order to find and fix problems before the code is sent for verification and release. Because this is the first test of code that is still under development, problems are to be expected.Beta testing occurs after development and alpha testing are complete. The purpose of beta testing is to verify the operation of the software in a working environment (on live), after development and alpha testing are complete, but before the software is officially released. Software in beta test status is believed to be fully functional with no known malfunctions (bugs). Beta testing is done concurrently with the verification process.
33
What is BVT?BVT is a Build Verification Test and is normally performed, after the integration of all modules/components with the corresponding backend has been completed taken from the repository using some perl scripts (usually). Also it can be considered to be given for alpha/beta testing.
34
What is TQM?Total Quality Management (TQM) Total = Quality involves everyone and all activities in the company. Quality = Conformance to Requirements (Meeting Customer Requirements). Management = Quality can and must be managed. TQM = A process for managing quality; it must be a continuous way of life; a philosophy of perpetual improvement in everything we do.
35
Explain Walkthrough.
During a project's development, it will frequently be necessary to confirm that the individual elements of the design or work packages have been satisfied. This is design verification. This is also known as design walkthrough. A walkthrough is where the designer walks through the design or code explaining to his peers how the design works. Design verification normally takes place at intermediate stages between formal reviews and will often be a precursor to signing off a work package or a design document. Design verification may include but is not limited to: • Low Level Design • Source Code • Unit Test Plans • Unit Test Scripts • Functional Test Plans Although design verification is a less formal process than design review, actions arising during design verification shall nevertheless be recorded
36
Explain Review
Like other development activities, test strategy, planning and test design are themselves subject to errors and omissions. Therefore the test strategy, planning, specifications, etc. must have a review prior to testing. The formality of such a review will clearly vary with the level of testing applicable. What is important is that someone other than the author of a test document examines it for adequacy, feasibility and trace ability. It is widely accepted that static testing, in the form of inspections (peer review), is a very efficient method of identifying defects in code, with the additional benefit of improving team learning and speeding up knowledge transfer. Formal reviews, rather than inspections, tend to identify more defects but are more costly in terms of time and effort. Therefore any team will need to find the right balance for the product being inspected depending on the associated risk. At the end of each testing phase, a review of actual against expected test results must be undertaken to ensure that testing has been successful.
37
Explain Boundary Value Analysis
This complements equivalence partitioning by looking at the boundaries of the input equivalence classes. Test cases are devised that exercise the module with data chosen at these boundaries and also with data chosen to exercise the module on the boundaries of output data as well. For example, if an input is specified from zero to 255, the equivalence partitioning leads to values of less than 0, between 0 and 255 and greater than 255 as test input. Boundary-value analysis would suggest adding the following values:
-1 0 1
254 255 256
38
Explain Cause Effect Analysis
This requires that one must write sufficient test cases to explore the entire set of output conditions caused by a combination of input conditions, or equivalence classes of input conditions. This approach is necessary where required behavior depends upon a number of related factors or a sequence of events.
39
Explain Equivalence Partitioning
This technique relies on looking at the set of valid inputs specified for a module and dividing it up into classes of data that should, according to the specification, be treated identically. One set of test data is then devised to represent each equivalence class. The premise is that any representative will be as good as any other in finding faults in the handling of that class.
40
Explain the use of test tools.
Software testing tools can provide assistance with a number of testing activities. Examples of the types of assistance which can be provided are:
· Automation of test scripts There is a basic need for all tests to be repeatable. The repetition of tests can be made much easier by the user of test automation tools, which are able to capture and execute system-testing activities. Such activities may take the form of keyboard entry and mouse activity as well as execution of system procedures. These tools can be particularly useful for regression testing, or for stress testing where they can perhaps be used to simulate multiple user activity.
· Fault logging and tracking Faults discovered during testing must be recorded and processed methodically. Software tools can assist with the capture of fault details, assignment of a priority to each, allocation of responsibility for fixing faults, tracking of progress on fixing faults, etc
· Static code analysis A number of tools exist which will analyse program code and report on a number of characteristics, e.g. program structure, conformance with standards, use of comments, etc. These can be used as a pro-active measure to ensure the quality of maintainability of code.
Read More about Software Testing Tutorials
Explain Path Coverage.
This measure reports whether each of the possible paths in each function have been followed. A path is a unique sequence of branches from the function entry to the exit. Also known as predicate coverage. Predicate coverage views paths as possible combination of logical conditions.
22
Explain Race Coverage.
This measure reports whether multiple threads execute the same code at the same time. It helps detect failure to synchronize access to resources. It is useful for testing multi-threaded programs such as in an operating system.
23
Explain Relational Operator Coverage.
This measure reports whether boundary situations occur with relational operators (<, <=, >, >=). The hypothesis is that boundary test cases find off-by-one errors and mistaken uses of wrong relational operators such as < instead of <=. For example, consider the following C/C++ code fragment:if (a < b) statement; Relational operator coverage reports whether the situation a==b occurs. If a==b occurs and the program behaves correctly, you can assume the relational operator is not suppose to be <=.
24
Explain Statement Coverage.
This measure reports whether each executable statement is encountered. The chief advantage of this measure is that it can be applied directly to object code and does not require processing source code. Performance profilers commonly implement this measure. The chief disadvantage of statement coverage is that it is insensitive to some control structures. For example, consider the following C/C++ code fragment:Int* p = NULL;if (condition)p = &variable;*p = 123;Without a test case that causes condition to evaluate false, statement coverage rates this code fully covered. In fact, if condition ever evaluates false, this code fails. This is the most serious shortcoming of statement coverage. If-statements are very common.
25
What is stress testing?
Test conducted to evaluate a system or component at or beyond the limits of its specified requirements to determine the load under which it fails and how. Stress testing is testing that investigates the behavior of software (and hardware) under extraordinary operating conditions.
For example, when a web server is stress tested, testing aims to find out how many users can be on-line, at the same time, without crashing the server. Stress testing tests the stability of a given system or entity.
26
What is Security Testing?Security Testing: Testing which confirms that the program can restrict access to authorized personnel and that the authorized personnel can access the functions available to their security level. Security/penetration testing is testing how well the system is protected against unauthorized internal or external access, or willful damage. For example: Firewall Test, Port Scan, Internet Security, database security
27
What is regression testing?Testing repeatedly the same thing is called Regression. This happens when there exist a bug, reported to the Dev.team, fixed and given back to the Tester. Now the tester will test not only the bug fixed but also the other stuff which was right earlier. The reason to do this is, because of the fixing of the bug reported, there is a danger that this might have resulted somewhere else as a bug.So to make sure that when ever the new build is given to the Testing Team, the full cycle of testing will be carried out. That is testing the same which already tested. In other words 'Regression testing'.
28
What is Soak Testing?
Soak testing is running a system at high levels of load for prolonged periods of time. A soak test would normally execute several times more transactions in an entire day (or night) than would be expected in a busy day, to identify and performance problems that appear after a large number of transactions have been executed. Also, due to memory leaks and other defects, it is possible that a system may ‘stop’ working after a certain number of transactions have been processed. It is important to identify such situations in a test environment.
29
What is the difference between Product Testing and Application Testing?A product is developed software which is generic to all; the changes in the software will be made when the new requests/change requests raised by the client. Testing this type of product is known as product testing. A project is particularly or specifically related to one and only one client. Testing this application is known as project testing.
30
What is Database Testing?Testing the tables, data in tables, relationship between the tables, does the data is saved in a proper way in tables is known as database testing.
31
What is Configuration Testing?Testing whether the applications specified configuration is working properly or not, i.e the configurable details of the application.
32
Difference between UAT and Alpha testing and Beta testing.User Acceptance Testing (UAT): A formal product evaluation performed by a customer as a condition of purchase. The testing can be based upon the User Requirements Specification to which the system should conform. Use Acceptance testing is black box testing. User Acceptance Testing is the last stage of the Software Development Lifecycle. User acceptance testing we validating all the user requirements specified in SRS is met after code freeze. The acceptance test is the responsibility of the client/customer or project manager; however, it is conducted with the full support of the project team. Before the software goes live determining if software is satisfactory to an end-user or customer. Alpha testing is done during software development to test changes and new features of the software. The purpose of alpha testing is to check the operation of the code in order to find and fix problems before the code is sent for verification and release. Because this is the first test of code that is still under development, problems are to be expected.Beta testing occurs after development and alpha testing are complete. The purpose of beta testing is to verify the operation of the software in a working environment (on live), after development and alpha testing are complete, but before the software is officially released. Software in beta test status is believed to be fully functional with no known malfunctions (bugs). Beta testing is done concurrently with the verification process.
33
What is BVT?BVT is a Build Verification Test and is normally performed, after the integration of all modules/components with the corresponding backend has been completed taken from the repository using some perl scripts (usually). Also it can be considered to be given for alpha/beta testing.
34
What is TQM?Total Quality Management (TQM) Total = Quality involves everyone and all activities in the company. Quality = Conformance to Requirements (Meeting Customer Requirements). Management = Quality can and must be managed. TQM = A process for managing quality; it must be a continuous way of life; a philosophy of perpetual improvement in everything we do.
35
Explain Walkthrough.
During a project's development, it will frequently be necessary to confirm that the individual elements of the design or work packages have been satisfied. This is design verification. This is also known as design walkthrough. A walkthrough is where the designer walks through the design or code explaining to his peers how the design works. Design verification normally takes place at intermediate stages between formal reviews and will often be a precursor to signing off a work package or a design document. Design verification may include but is not limited to: • Low Level Design • Source Code • Unit Test Plans • Unit Test Scripts • Functional Test Plans Although design verification is a less formal process than design review, actions arising during design verification shall nevertheless be recorded
36
Explain Review
Like other development activities, test strategy, planning and test design are themselves subject to errors and omissions. Therefore the test strategy, planning, specifications, etc. must have a review prior to testing. The formality of such a review will clearly vary with the level of testing applicable. What is important is that someone other than the author of a test document examines it for adequacy, feasibility and trace ability. It is widely accepted that static testing, in the form of inspections (peer review), is a very efficient method of identifying defects in code, with the additional benefit of improving team learning and speeding up knowledge transfer. Formal reviews, rather than inspections, tend to identify more defects but are more costly in terms of time and effort. Therefore any team will need to find the right balance for the product being inspected depending on the associated risk. At the end of each testing phase, a review of actual against expected test results must be undertaken to ensure that testing has been successful.
37
Explain Boundary Value Analysis
This complements equivalence partitioning by looking at the boundaries of the input equivalence classes. Test cases are devised that exercise the module with data chosen at these boundaries and also with data chosen to exercise the module on the boundaries of output data as well. For example, if an input is specified from zero to 255, the equivalence partitioning leads to values of less than 0, between 0 and 255 and greater than 255 as test input. Boundary-value analysis would suggest adding the following values:
-1 0 1
254 255 256
38
Explain Cause Effect Analysis
This requires that one must write sufficient test cases to explore the entire set of output conditions caused by a combination of input conditions, or equivalence classes of input conditions. This approach is necessary where required behavior depends upon a number of related factors or a sequence of events.
39
Explain Equivalence Partitioning
This technique relies on looking at the set of valid inputs specified for a module and dividing it up into classes of data that should, according to the specification, be treated identically. One set of test data is then devised to represent each equivalence class. The premise is that any representative will be as good as any other in finding faults in the handling of that class.
40
Explain the use of test tools.
Software testing tools can provide assistance with a number of testing activities. Examples of the types of assistance which can be provided are:
· Automation of test scripts There is a basic need for all tests to be repeatable. The repetition of tests can be made much easier by the user of test automation tools, which are able to capture and execute system-testing activities. Such activities may take the form of keyboard entry and mouse activity as well as execution of system procedures. These tools can be particularly useful for regression testing, or for stress testing where they can perhaps be used to simulate multiple user activity.
· Fault logging and tracking Faults discovered during testing must be recorded and processed methodically. Software tools can assist with the capture of fault details, assignment of a priority to each, allocation of responsibility for fixing faults, tracking of progress on fixing faults, etc
· Static code analysis A number of tools exist which will analyse program code and report on a number of characteristics, e.g. program structure, conformance with standards, use of comments, etc. These can be used as a pro-active measure to ensure the quality of maintainability of code.
Read More about Software Testing Tutorials
1 comment:
http://www.ittestpapers.com/interviewquestions/testing1.htm?gclid=CLzFo7zIkJACFQgkegod1HX1-w
Post a Comment