FAQ'S Of Software Testing

Q106. What metrics are used for bug tracking?
A: Metrics that can be used for bug tracking include: total number of bugs, total number of bugs that have been fixed, number of new bugs per week, and number of fixes per week. Metrics for bug tracking can be used to determine when to stop testing, e.g. when bug rate falls below a certain level. You CAN learn to use defect tracking software, with little or no outside help. Get CAN get free information. Click on a link!
Q107. What is role of the QA engineer?
A: The QA Engineer's function is to use the system much like real users would, find all the bugs, find ways to replicate the bugs, submit bug reports to the developers, and to provide feedback to the developers, i.e. tell them if they've achieved the desired level of quality.
Q108. What are the responsibilities of a QA engineer?
A: Let's say, an engineer is hired for a small software company's QA role, and there is no QA team. Should he take responsibility to set up a QA infrastructure/process, testing and quality of the entire product? No, because taking this responsibility is a classic trap that QA people get caught in. Why? Because we QA engineers cannot assure quality. And because QA departments cannot create quality. What we CAN do is to detect lack of quality, and prevent low-quality products from going out the door. What is the solution? We need to drop the QA label, and tell the developers, they are responsible for the quality of their own work. The problem is, sometimes, as soon as the developers learn that there is a test department, they will slack off on their testing. We need to offer to help with quality assessment only.

Q109. What metrics can be used in software development?
A: Metrics refer to statistical process control. The idea of statistical process control is a great one, but it has only a limited use in software development. On the negative side, statistical process control works only with processes that are sufficiently well defined AND unvaried, so that they can be analyzed in terms of statistics. The problem is, most software development projects are NOT sufficiently well defined and NOT sufficiently unvaried. On the positive side, one CAN use statistics. Statistics are excellent tools that project managers can use. Statistics can be used, for example, to determine when to stop testing, i.e. test cases completed with certain percentage passed, or when bug rate falls below a certain level. But, if these are project management tools, why should we label them quality assurance tools?
Q110. How do you perform integration testing?
A: First, unit testing has to be completed. Upon completion of unit testing, integration testing begins. Integration testing is black box testing. The purpose of integration testing is to ensure distinct components of the application still work in accordance to customer requirements. Test cases are developed with the express purpose of exercising the interfaces between the components. This activity is carried out by the test team. Integration testing is considered complete, when actual results and expected results are either in line or differences are explainable/acceptable based on client input. You CAN learn to perform integration testing, with little or no outside help. Get CAN get free information. Click on a link!
Q111. What is integration testing?
A: Integration testing is black box testing. The purpose of integration testing is to ensure distinct components of the application still work in accordance to customer requirements. Test cases are developed with the express purpose of exercising the interfaces between the components. This activity is carried out by the test team. Integration testing is considered complete, when actual results and expected results are either in line or differences are explainable/acceptable based on client input.
Q112. What metrics are used for test report generation?
A: Metrics refer to statistical process control. The idea of statistical process control is a great one, but it has only a limited use in software development.
On the negative side, statistical process control works only with processes that are sufficiently well defined AND unvaried, so that they can be analyzed in terms of statistics. The problem is, most software development projects are NOT sufficiently well defined and NOT sufficiently unvaried.
On the positive side, one CAN use statistics. Statistics are excellent tools that project managers can use. Statistics can be used, for example, to determine when to stop testing, i.e. test cases completed with certain percentage passed, or when bug rate falls below a certain level. But, if these are project management tools, why should we label them quality assurance tools?
The followings describe some of the metrics in quality assurance:
McCabe Metrics
1. Cyclomatic Complexity Metric (v(G)). Cyclomatic Complexity is a measure of the complexity of a module's decision structure. It's the number of linearly independent paths and therefore, the minimum number of paths that should be tested.
2. Actual Complexity Metric (AC). Actual Complexity is the number of independent paths traversed during testing.
3. Module Design Complexity Metric (iv(G)). Module Design Complexity is the complexity of the design-reduced module, and reflects the complexity of the module's calling patterns to its immediate subordinate modules. This metric differentiates between modules that seriously complicate the design of a program they are part of, and modules that simply contain complex computational logic. It is the basis upon which program design and integration complexities (S0 and S1) are calculated.
4. Essential Complexity Metric (ev(G)). Essential Complexity is a measure of the degree to which a module contains unstructured constructs. This metric measures the degree of structuredness and the quality of the code. This metric is used to predict the required maintenance effort and to help in the modularization process.
5. Pathological Complexity Metric (pv(G)). Pathological Complexity Metric is a measure of the degree to which a module contains extremely unstructured constructs.
6. Design Complexity Metric (S0). Design Complexity Metric measures the amount of interaction between modules in a system.
7. Integration Complexity Metric (S1). Integration Complexity Metric measures the amount of integration testing necessary to guard against errors.
8. Object Integration Complexity Metric (OS1). Object Integration Complexity Metric quantifies the number of tests necessary to fully integrate an object or class into an OO system.
9. Global Data Complexity Metric (gdv(G)). Global Data Complexity Metric quantifies the cyclomatic complexity of a module's structure as it relates to global/parameter data. It can be no less than one and no more than the cyclomatic complexity of the original flowgraph.
McCabe Data-Related Software Metrics
1. Data Complexity Metric (DV). Data Complexity Metric quantifies the complexity of a module's structure as it relates to data-related variables. It is the number of independent paths through data logic, and therefore, a measure of the testing effort with respect to data-related variables.
2. Tested Data Complexity Metric (TDV). Tested Data Complexity Metric quantifies the complexity of a module's structure as it relates to data-related variables. It is the number of independent paths through data logic that have been tested.
3. Data Reference Metric (DR). Data Reference Metric measures references to data-related variables independently of control flow. It is the total number of times that data-related variables are used in a module.
4. Tested Data Reference Metric (TDR). Tested Data Reference Metric is the total number of tested references to data-related variables.
5. Maintenance Severity Metric (maint_severity). Maintenance Severity Metric measures how difficult it is to maintain a module.
6. Data Reference Severity Metric (DR_severity). Data Reference Severity Metric measures the level of data intensity within a module. It is an indicator of high levels of data related code; therefore, a module is data intense if it contains a large number of data-related variables.
7. Data Complexity Severity Metric (DV_severity). Data Complexity Severity Metric measures the level of data density within a module. It is an indicator of high levels of data logic in test paths, therefore, a module is data dense if it contains data-related variables in a large proportion of its structures.
8. Global Data Severity Metric (gdv_severity). Global Data Severity Metric measures the potential impact of testing data-related basis paths across modules. It is based on global data test paths.
McCabe Object-Oriented Software Metrics; Encapsulation
1. Percent Public Data (PCTPUB). PCTPUB is the percentage of public and proteced data within a class.
2. Access to Public Data (PUBDATA) PUBDATA indicates the number of accesses to public and protected data.
McCabe Object-Oriented Software Metrics; Polymorphism
1. Percent of Unoverloaded Calls (PCTCALL). PCTCALL is the number of non-overloaded calls in a system.
2. Number of Roots (ROOTCNT). ROOTCNT is the total number of class hierarchy roots within a program.
3. Fan-in (FANIN). FANIN is the number of classes from which a class is derived.
McCabe Object-Oriented Software Metrics; Quality
1. Maximum v(G) (MAXV). MAXV is the maximum cyclomatic complexity value for any single method within a class.
2. Maximum ev(G) (MAXEV). MAXEV is the maximum essential complexity value for any single method within a class.
3. Hierarchy Quality(QUAL). QUAL counts the number of classes within a system that are dependent upon their descendants.
Other Object-Oriented Software Metrics
1. Depth (DEPTH). Depth indicates at what level a class is located within its class hierarchy.
2. Lack of Cohesion of Methods (LOCM). LOCM is a measure of how the methods of a class interact with the data in a class.
3. Number of Children (NOC). NOC is the number of classes that are derived directly from a specified class.
4. Response For a Class (RFC). RFC is a count of methods implemented within a class plus the number of methods accessible to an object of this class type due to inheritance.
5. Weighted Methods Per Class (WMC). WMC is a count of methods implemented within a class.
Halstead Software Metrics
1. Program Length. Program length is the total number of operator occurences and the total number of operand occurences.
2. Program Volume. Program volume is the minimum number of bits required for coding the program.
3. Program Level and Program Difficulty. Program level and program difficulty is a measure of how easily a program is comprehended.
4. Intelligent Content. Intelligent content shows the complexity of a given algorithm independent of the language used to express the algorithm.
5. Programming Effort. Programming effort is the estimated mental effort required to develop a program.
6. Error Estimate. Error estimate calculates the number of errors in a program.
7. Programming Time. Programming time is the estimated amount of time to implement an algorithm.
Line Count Software Metrics
1. Lines of Code
2. Lines of Comment
3. Lines of Mixed Code and Comments
4. Lines Left Blank

Q113. How do test plan templates look like?
A: The test plan document template helps to generate test plan documents that describe the objectives, scope, approach and focus of a software testing effort. Test document templates are often in the form of documents that are divided into sections and subsections. One example of this template is a 4-section document, where section 1 is the description of the "Test Objective", section 2 is the the description of "Scope of Testing", section 3 is the the description of the "Test Approach", and section 4 is the "Focus of the Testing Effort". All documents should be written to a certain standard and template. Standards and templates maintain document uniformity. They also help in learning where information is located, making it easier for a user to find what they want. With standards and templates, information will not be accidentally omitted from a document. Once Rob Davis has learned and reviewed your standards and templates, he will use them. He will also recommend improvements and/or additions. A software pro
ject test plan is a document that describes the objectives, scope, approach and focus of a software testing effort. The process of preparing a test plan is a useful way to think through the efforts needed to validate the acceptability of a software product. The completed document will help people outside the test group understand the why and how of product validation. You CAN learn to generate test plan templates, with little or no outside help. Get CAN get free information. Click on a link!
Q114. What is a "bug life cycle"?
A: Bug life cycles are similar to software development life cycles. At any time during the software development life cycle errors can be made during the gathering of requirements, requirements analysis, functional design, internal design, documentation planning, document preparation, coding, unit testing, test planning, integration, testing, maintenance, updates, re-testing and phase-out. Bug life cycle begins when a programmer, software developer, or architect makes a mistake, creates an unintentional software defect, i.e. a bug, and ends when the bug is fixed, and the bug is no longer in existence. What should be done after a bug is found? When a bug is found, it needs to be communicated and assigned to developers that can fix it. After the problem is resolved, fixes should be re-tested. Additionally, determinations should be made regarding requirements, software, hardware, safety impact, etc., for regression testing to check the fixes didn't create other problems elsewhere. If a problem-tracking system is in place, it should encapsulate these determinations. A variety of commercial, problem-tracking/management software tools are available. These tools, with the detailed input of software test engineers, will give the team complete information so developers can understand the bug, get an idea of its severity, reproduce it and fix it.
Q115. When do you choose automated testing?
A: For larger projects, or ongoing long-term projects, automated testing can be valuable. But for small projects, the time needed to learn and implement the automated testing tools is usually not worthwhile. Automated testing tools sometimes do not make testing easier. One problem with automated testing tools is that if there are continual changes to the product being tested, the recordings have to be changed so often, that it becomes a very time-consuming task to continuously update the scripts. Another problem with such tools is the interpretation of the results (screens, data, logs, etc.) that can be a time-consuming task. You CAN learn to use automated tools, with little or no outside help. Get CAN get free information. Click on a link!
Q116. What is the ratio of developers and testers?
A: This ratio is not a fixed one, but depends on what phase of the software development life cycle the project is in. When a product is first conceived, organized, and developed, this ratio tends to be 10:1, 5:1, or 3:1, i.e. heavily in favor of developers. In sharp contrast, when the product is near the end of the software development life cycle, this ratio tends to be 1:1, or even 1:2, in favor of testers.
Q117. What is your role in your current organization?
A: I'm a Software QA Engineer. I use the system much like real users would. I find all the bugs, find ways to replicate the bugs, submit bug reports to developers, and provides feedback to the developers, i.e. tell them if they've achieved the desired level of quality.
Q118. Should I take a course in manual testing?
A: Learning how to perform manual testing is an important part of one's education. I see no reason why one should skip an important part of an academic program.
Q119. How can I learn to use WinRunner, without any outside help?
A: I suggest you read all you can, and that includes reading product description pamphlets, manuals, books, information on the Internet, and whatever information you can lay your hands on. Then the next step is getting some hands-on experience on how to use WinRunner. If there is a will, there is a way! You CAN do it, if you put your mind to it! You CAN learn to use WinRunner, with little or no outside help. Get CAN get free information. Click on a link!
Q120. To learn to use WinRunner, should I sign up for a course at a nearby educational institution?
A: The cheapest, or free, education is sometimes provided on the job, by an employer, while one is getting paid to do a job that requires the use of WinRunner and many other software testing tools. In lieu of a job, it is often a good idea to sign up for courses at nearby educational institutions. Classroom education, especially non-degree courses in local, community colleges, tends to be cheap.
Q121. I don't have a lot of money. How can I become a good tester with little or no cost to me?
A: The cheapest, or free, education is sometimes provided on the job, by an employer, while one is getting paid to do a job that requires the use of WinRunner and many other software testing tools.

Previous Software FAQ'S             More Software FAQ'S