Set 3 of Interview FAQs
Q: 1 What is the role of the test engineer?
A: We, test engineers, speed up the work of the development staff, and reduce the risk of your company's legal liability.
We also give your company the evidence that the software is correct and operates properly.
We, test engineers, improve problem tracking and reporting, maximize the value of the software, and the value of the devices that use it.
We, test engineers, assure the successful launch of the product by discovering bugs and design flaws, before users get discouraged, before shareholders loose their cool and before employees get bogged down.
We, test engineers, help the work of the software development staff, so the development team can devote its time to build up the product.
We, test engineers, promote continual improvement.
We provide documentation required by FDA, FAA, other regulatory agencies, and your customers.
We, test engineers, save your company money by discovering defects EARLY in the design process, before failures occur in production, or in the field. We save the reputation of your company by discovering bugs and design flaws, before bugs and design flaws damage the reputation of your company.
Q: 2 What are the QA engineer's responsibilities?
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 that 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.
Q: 3 What metrics can be used in for 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?
Q: 4 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.
Q: 5 What metrics can be used for bug tracking?
A: Metrics that can be used for bug tracking include the total number of bugs, total number of bugs that have been fixed, number of new bugs per week, and number of fixes per week.
Other metrics in quality assurance include...
McCabe metrics: cyclomatic complexity metric (v(G)), actual complexity metric (AC), module design complexity metric (iv(G)), essential complexity metric (ev(G)), pathological complexity metric (pv(G)), design complexity metric (S0), integration complexity metric (S1), object integration complexity metric (OS1), global data complexity metric (gdv(G)), data complexity metric (DV), tested data complexity metric (TDV), data reference metric (DR), tested data reference metric (TDR), maintenance severity metric (maint_severity), data reference severity metric (DR_severity), data complexity severity metric (DV_severity), global data severity metric (gdv_severity).
Q: 6 What metrics can be used for bug tracking? (Cont'd...)
McCabe object-oriented software metrics: encapsulation percent public data (PCTPUB), access to public data (PUBDATA), polymorphism percent of unoverloaded calls (PCTCALL), number of roots (ROOTCNT), fan-in (FANIN), quality maximum v(G) (MAXV), maximum ev(G) (MAXEV), and hierarchy quality (QUAL).
Other object-oriented software metrics: depth (DEPTH), lack of cohesion of methods (LOCM), number of children (NOC), response for a class (RFC), weighted methods per class (WMC), Halstead software metrics program length, program volume, program level and program difficulty, intelligent content, programming effort, error estimate, and programming time.
Line count software metrics: lines of code, lines of comment, lines of mixed code and comments, and lines left blank.
Q: 7 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.
Q: 8 What metrics are used for test report generation?
A: Metrics that can be used for test report generation include...
McCabe metrics: Cyclomatic complexity metric (v(G)), Actual complexity metric (AC), Module design complexity metric (iv(G)), Essential complexity metric (ev(G)), Pathological complexity metric (pv(G)), design complexity metric (S0), Integration complexity metric (S1), Object integration complexity metric (OS1), Global data complexity metric (gdv(G)), Data complexity metric (DV), Tested data complexity metric (TDV), Data reference metric (DR), Tested data reference metric (TDR), Maintenance severity metric (maint_severity), Data reference severity metric (DR_severity), Data complexity severity metric (DV_severity), Global data severity metric (gdv_severity).
McCabe object oriented software metrics: Encapsulation percent public data (PCTPUB), and Access to public data (PUBDATA), Polymorphism percent of unoverloaded calls (PCTCALL), Number of roots (ROOTCNT), Fan-in (FANIN), quality maximum v(G) (MAXV), Maximum ev(G) (MAXEV), and Hierarchy quality(QUAL).
Other object oriented software metrics: Depth (DEPTH), Lack of cohesion of methods (LOCM), Number of children (NOC), Response for a class (RFC), Weighted methods per class (WMC), Halstead software metrics program length, Program volume, Program level and program difficulty, Intelligent content, Programming effort, Error estimate, and Programming time.
Line count software metrics: Lines of code, Lines of comment, Lines of mixed code and comments, and Lines left blank.
Q: 9 What is the "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.
Q: 10 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.
Q: 11 How do test plan templates look like?
A: The test plan document template describes 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 "Test Objective", section 2 is the "Scope of Testing", section 3 is 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. It also helps 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
Q: 12 What is a software project test plan?
A: A software project 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. It should be thorough enough to be useful, but not so thorough that no one outside the test group will be able to read it.
Q: 13 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.
Q: 14 What's the ratio between 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 software is near the end of alpha testing, this ratio tends to be 1:1 or 1:2, in favor of testers.
Q: 15 What is your role in your current organization?
A: I'm a QA Engineer. 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.
Q: 16 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 actual practice, the gathering of 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.
Q: 17 Should I take a course in manual testing?
A: Yes, you want to consider taking a course in manual testing. Why? Because learning how to perform manual testing is an important part of one's education. Unless you have a significant personal reason for not taking a course, you do not want to skip an important part of an academic program.
Q: 18 To learn to use WinRunner, should I sign up for a course at a nearby educational institution?
A: Free, or inexpensive, education is often 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 institutes. Classes, especially non-degree courses in community colleges, tend to be inexpensive.
Q: 19 How can I become a good tester? I have little or no money.
A: The cheapest i.e. "free education" is often provided on the job, by an employer, while one is getting paid to do a testing job, where one is able to use many different software testing tools.
A: We, test engineers, speed up the work of the development staff, and reduce the risk of your company's legal liability.
We also give your company the evidence that the software is correct and operates properly.
We, test engineers, improve problem tracking and reporting, maximize the value of the software, and the value of the devices that use it.
We, test engineers, assure the successful launch of the product by discovering bugs and design flaws, before users get discouraged, before shareholders loose their cool and before employees get bogged down.
We, test engineers, help the work of the software development staff, so the development team can devote its time to build up the product.
We, test engineers, promote continual improvement.
We provide documentation required by FDA, FAA, other regulatory agencies, and your customers.
We, test engineers, save your company money by discovering defects EARLY in the design process, before failures occur in production, or in the field. We save the reputation of your company by discovering bugs and design flaws, before bugs and design flaws damage the reputation of your company.
Q: 2 What are the QA engineer's responsibilities?
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 that 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.
Q: 3 What metrics can be used in for 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?
Q: 4 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.
Q: 5 What metrics can be used for bug tracking?
A: Metrics that can be used for bug tracking include the total number of bugs, total number of bugs that have been fixed, number of new bugs per week, and number of fixes per week.
Other metrics in quality assurance include...
McCabe metrics: cyclomatic complexity metric (v(G)), actual complexity metric (AC), module design complexity metric (iv(G)), essential complexity metric (ev(G)), pathological complexity metric (pv(G)), design complexity metric (S0), integration complexity metric (S1), object integration complexity metric (OS1), global data complexity metric (gdv(G)), data complexity metric (DV), tested data complexity metric (TDV), data reference metric (DR), tested data reference metric (TDR), maintenance severity metric (maint_severity), data reference severity metric (DR_severity), data complexity severity metric (DV_severity), global data severity metric (gdv_severity).
Q: 6 What metrics can be used for bug tracking? (Cont'd...)
McCabe object-oriented software metrics: encapsulation percent public data (PCTPUB), access to public data (PUBDATA), polymorphism percent of unoverloaded calls (PCTCALL), number of roots (ROOTCNT), fan-in (FANIN), quality maximum v(G) (MAXV), maximum ev(G) (MAXEV), and hierarchy quality (QUAL).
Other object-oriented software metrics: depth (DEPTH), lack of cohesion of methods (LOCM), number of children (NOC), response for a class (RFC), weighted methods per class (WMC), Halstead software metrics program length, program volume, program level and program difficulty, intelligent content, programming effort, error estimate, and programming time.
Line count software metrics: lines of code, lines of comment, lines of mixed code and comments, and lines left blank.
Q: 7 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.
Q: 8 What metrics are used for test report generation?
A: Metrics that can be used for test report generation include...
McCabe metrics: Cyclomatic complexity metric (v(G)), Actual complexity metric (AC), Module design complexity metric (iv(G)), Essential complexity metric (ev(G)), Pathological complexity metric (pv(G)), design complexity metric (S0), Integration complexity metric (S1), Object integration complexity metric (OS1), Global data complexity metric (gdv(G)), Data complexity metric (DV), Tested data complexity metric (TDV), Data reference metric (DR), Tested data reference metric (TDR), Maintenance severity metric (maint_severity), Data reference severity metric (DR_severity), Data complexity severity metric (DV_severity), Global data severity metric (gdv_severity).
McCabe object oriented software metrics: Encapsulation percent public data (PCTPUB), and Access to public data (PUBDATA), Polymorphism percent of unoverloaded calls (PCTCALL), Number of roots (ROOTCNT), Fan-in (FANIN), quality maximum v(G) (MAXV), Maximum ev(G) (MAXEV), and Hierarchy quality(QUAL).
Other object oriented software metrics: Depth (DEPTH), Lack of cohesion of methods (LOCM), Number of children (NOC), Response for a class (RFC), Weighted methods per class (WMC), Halstead software metrics program length, Program volume, Program level and program difficulty, Intelligent content, Programming effort, Error estimate, and Programming time.
Line count software metrics: Lines of code, Lines of comment, Lines of mixed code and comments, and Lines left blank.
Q: 9 What is the "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.
Q: 10 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.
Q: 11 How do test plan templates look like?
A: The test plan document template describes 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 "Test Objective", section 2 is the "Scope of Testing", section 3 is 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. It also helps 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
Q: 12 What is a software project test plan?
A: A software project 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. It should be thorough enough to be useful, but not so thorough that no one outside the test group will be able to read it.
Q: 13 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.
Q: 14 What's the ratio between 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 software is near the end of alpha testing, this ratio tends to be 1:1 or 1:2, in favor of testers.
Q: 15 What is your role in your current organization?
A: I'm a QA Engineer. 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.
Q: 16 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 actual practice, the gathering of 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.
Q: 17 Should I take a course in manual testing?
A: Yes, you want to consider taking a course in manual testing. Why? Because learning how to perform manual testing is an important part of one's education. Unless you have a significant personal reason for not taking a course, you do not want to skip an important part of an academic program.
Q: 18 To learn to use WinRunner, should I sign up for a course at a nearby educational institution?
A: Free, or inexpensive, education is often 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 institutes. Classes, especially non-degree courses in community colleges, tend to be inexpensive.
Q: 19 How can I become a good tester? I have little or no money.
A: The cheapest i.e. "free education" is often provided on the job, by an employer, while one is getting paid to do a testing job, where one is able to use many different software testing tools.
0 comments:
Post a Comment