Set 6 of Interview FAQs
Q: 1 Can you give me more information on software QA/testing, from a tester's point of view?
A: Yes, I can. You can visit my web site, and on pages robdavispe.com/free and robdavispe.com/free2 you can find answers to many questions on software QA, documentation, and software testing, from a tester's point of view. As to questions and answers that are not on my web site now, please be patient, as I am going to add more answers, as soon as time permits.
Q: 2 What are the parameters of performance testing?
A: Performance testing verifies loads, volumes, and response times, as defined by requirements. Performance testing is a part of system testing, but it is also a distinct level of testing.
The term 'performance testing' is often used synonymously with stress testing, load testing, reliability testing, and volume testing.
Q: 3 What types of testing can you tell me about?
A: Each of the followings represents a different type of testing approach: black box testing, white box testing, unit testing, incremental testing, integration testing, functional testing, system testing, end-to-end testing, sanity testing, regression testing, acceptance testing, load testing, performance testing, usability testing, install/uninstall testing, recovery testing, security testing, compatibility testing, exploratory testing, ad-hoc testing, user acceptance testing, comparison testing, alpha testing, beta testing, and mutation testing.
Q: What is disaster recovery testing?
A: Disaster recovery testing is testing how well the system recovers from disasters, crashes, hardware failures, or other catastrophic problems.
Q: 4 How do you conduct peer reviews?
A: Peer reviews, sometimes called PDR, are formal meeting, more formalized than a walk-through, and typically consists of 3-10 people including the test lead, task lead (the author of whatever is being reviewed) and a facilitator (to make notes).
The subject of the PDR is typically a code block, release, or feature, or document. The purpose of the PDR is to find problems and see what is missing, not to fix anything.
The result of the meeting is documented in a written report. Attendees should prepare for PDRs by reading through documents, before the meeting starts; most problems are found during this preparation.
Why are PDRs so useful? Because PDRs are cost-effective methods of ensuring quality, because bug prevention is more cost effective than bug detection.
Q: 5 How do you test the password field?
A: To test the password field, we do boundary value testing.
Q: 6 How do you check the security of your application?
A: To check the security of an application, we can use security/penetration testing. Security/penetration testing is testing how well the system is protected against unauthorized internal or external access, or willful damage.
This type of testing usually requires sophisticated testing techniques.
Q: 7 When testing the password field, what is your focus?
A: When testing the password field, one needs to verify that passwords are encrypted.
Q: 8 What is the objective of regression testing?
A: The objective of regression testing is to test that the fixes have not created any other problems elsewhere. In other words, the objective is to ensure the software has remained intact.
A baseline set of data and scripts are maintained and executed, to verify that changes introduced during the release have not "undone" any previous code.
Expected results from the baseline are compared to results of the software under test. All discrepancies are highlighted and accounted for, before testing proceeds to the next level.
Q: 9 What stage of bug fixing is the most cost effective?
A: Bug prevention, i.e. inspections, PDRs, and walk-throughs, is more cost effective than bug detection.
Q: 10 What types of white box testing can you tell me about?
A: White box testing is a testing approach that examines the application's program structure, and derives test cases from the application's program logic.
Clear box testing is a white box type of testing. Glass box testing is also a white box type of testing. Open box testing is also a white box type of testing.
Q: 11 What black box testing types can you tell me about?
A: Black box testing is functional testing, not based on any knowledge of internal software design or code.
Black box testing is based on requirements and functionality. Functional testing is also a black-box type of testing geared to functional requirements of an application.
System testing is also a black box type of testing. Acceptance testing is also a black box type of testing. Functional testing is also a black box type of testing. Closed box testing is also a black box type of testing. Integration testing is also a black box type of testing.
Q: 12 Is regression testing performed manually?
A: It depends on the initial testing approach. If the initial testing approach was manual testing, then the regression testing is normally performed manually.
Conversely, if the initial testing approach was automated testing, then the regression testing is normally performed by automated testing.
Q: 13 Give me others' FAQs on testing.
A: Here is what you can do. You can visit my web site, and on robdavispe.com/free and robdavispe.com/free2 you will find answers to the vast majority of others' questions on testing, from a tester's point of view.
As to questions and answers that are not on my web site now, please be patient, as I am going to add more FAQs and answers, as soon as time permits.
Q: 14 Can you share with me your knowledge of software testing?
A: Surely I can. Visit my web site, and on robdavispe.com/free and robdavispe.com/free2 you will find my knowledge on software testing, from a tester's point of view.
As to knowledge that is not on my web site now, please be patient, as I am going to add more answers, as soon as time permits.
Q: 15 How can I learn software testing?
A: I suggest you visit my web site, especially robdavispe.com/free and robdavispe.com/free2, and you will find answers to most questions on software testing. As to questions and answers that are not on my web site at the moment, please be patient. I will add more questions and answers, as soon as time permits.
I also suggest you get a job in software testing. Why? Because you can get additional, free education, on the job, by an employer, while you are being paid to do software testing. On the job, you will be able to use some of the more popular software tools, including WinRunner, LoadRunner, LabView, and the Rational Toolset. The tools you use will depend on the end client, their needs and preferences.
I also suggest you sign up for courses at nearby educational institutions. Classroom education, especially non-degree courses in local community colleges, tends to be inexpensive.
Q: 16 What is your view of software QA/testing?
A: Software QA/testing is easy, if requirements are solid, clear, complete, detailed, cohesive, attainable and testable, and if schedules are realistic, and if there is good communication.
Software QA/testing is a piece of cake, if project schedules are realistic, if adequate time is allowed for planning, design, testing, bug fixing, re-testing, changes, and documentation.
Q: 17 What is your view of software QA/testing? (Cont'd...)
Software QA/testing is relatively easy, if testing is started early on, and if fixes or changes are re-tested, and if sufficient time is planned for both testing and bug fixing.
Software QA/testing is easy, if new features are avoided, and if one sticks to initial requirements as much as possible.
Q: 18 How can I be a good tester?
A: We, good testers, take the customers' point of view. We are tactful and diplomatic. We have a "test to break" attitude, a strong desire for quality, an attention to detail, and good communication skills, both oral and written.
Previous software development experience is also helpful as it provides a deeper understanding of the software development process.
Q: 19 What is the difference between software bug and software defect?
A: A 'software bug' is a nonspecific term that means an inexplicable defect, error, flaw, mistake, failure, fault, or unwanted behavior of a computer program.
Other terms, e.g. software defect and software failure, are more specific.
There are many who believe the word 'bug' is a reference to insects that caused malfunctions in early electromechanical computers (in the 1950s and 1960s), the truth is the word 'bug' has been part of engineering jargon for 100+ years. Thomas Edison, the great inventor, wrote the followings in 1878: "It has been just so in all of my inventions. The first step is an intuition, and comes with a burst, then difficulties arise—this thing gives out and [it is] then that "Bugs" — as such little faults and difficulties are called — show themselves and months of intense watching, study and labor are requisite before commercial success or failure is certainly reached."
Q: 20 How can I improve my career in software QA/testing?
A: Invest in your skills! Learn all you can! Visit my web site, and on http://robdavispe.com/free and http://robdavispe.com/free2, you will find answers to the vast majority of questions on testing, from software QA/testers' point of view.
Get additional education, on the job. Free education is often provided by employers, while you are paid to do the job of a tester. On the job, often you can use many software tools, including WinRunner, LoadRunner, LabView, and Rational Toolset. Find an employer whose needs and preferences are similar to yours.
Get an education! Sign up for courses at nearby educational institutes. Take classes! Classroom education, especially non-degree courses in local community colleges, tends to be inexpensive. Improve your attitude! Become the best software QA/tester! Always strive to exceed the expectations of your customers!
Q: 21 How do you compare two files?
A: Use PVCS, SCCS, or "diff". PVCS is a document version control tool, a competitor of SCCS. SCCS is an original UNIX program, based on "diff". Diff is a UNIX utility that compares the difference between two text files.
Q: 22 What do we use for comparison?
A: Generally speaking, when we write a software program to compare files, we compare two files, bit by bit. For example, when we use "diff", a UNIX utility, we compare two text files.
Q: 23 What is the reason we compare files?
A: We compare files because of configuration management, revision control, requirement version control, or document version control. Examples are Rational ClearCase, DOORS, PVCS, and CVS. CVS, for example, enables several, often distant, developers to work together on the same source code.
Q: 24 When is a process repeatable?
A: If we use detailed and well-written processes and procedures, we ensure the correct steps are being executed. This facilitates a successful completion of a task. This is a way we also ensure a process is repeatable.
Q: 25 What is test methodology?
A: One test methodology is a three-step process. Creating a test strategy, creating a test plan/design, and executing tests. This methodology can be used and molded to your organization's needs.
Rob Davis believes that using this methodology is important in the development and ongoing maintenance of his customers' applications.
Q: 26 What does a Test Strategy Document contain?
A: The test strategy document is a formal description of how a software product will be tested. A test strategy is developed for all levels of testing, as required.
The test team analyzes the requirements, writes the test strategy and reviews the plan with the project team.
The test plan may include test cases, conditions, the test environment, and a list of related tasks, pass/fail criteria and risk assessment.
Additional sections in the test strategy document include:
A description of the required hardware and software components, including test tools. This information comes from the test environment, including test tool data.
A description of roles and responsibilities of the resources required for the test and schedule constraints. This information comes from man-hours and schedules.
Testing methodology. This is based on known standards.
Functional and technical requirements of the application. This information comes from requirements, change request, technical, and functional design documents.
Requirements that the system cannot provide, e.g. system limitations.
A: Yes, I can. You can visit my web site, and on pages robdavispe.com/free and robdavispe.com/free2 you can find answers to many questions on software QA, documentation, and software testing, from a tester's point of view. As to questions and answers that are not on my web site now, please be patient, as I am going to add more answers, as soon as time permits.
Q: 2 What are the parameters of performance testing?
A: Performance testing verifies loads, volumes, and response times, as defined by requirements. Performance testing is a part of system testing, but it is also a distinct level of testing.
The term 'performance testing' is often used synonymously with stress testing, load testing, reliability testing, and volume testing.
Q: 3 What types of testing can you tell me about?
A: Each of the followings represents a different type of testing approach: black box testing, white box testing, unit testing, incremental testing, integration testing, functional testing, system testing, end-to-end testing, sanity testing, regression testing, acceptance testing, load testing, performance testing, usability testing, install/uninstall testing, recovery testing, security testing, compatibility testing, exploratory testing, ad-hoc testing, user acceptance testing, comparison testing, alpha testing, beta testing, and mutation testing.
Q: What is disaster recovery testing?
A: Disaster recovery testing is testing how well the system recovers from disasters, crashes, hardware failures, or other catastrophic problems.
Q: 4 How do you conduct peer reviews?
A: Peer reviews, sometimes called PDR, are formal meeting, more formalized than a walk-through, and typically consists of 3-10 people including the test lead, task lead (the author of whatever is being reviewed) and a facilitator (to make notes).
The subject of the PDR is typically a code block, release, or feature, or document. The purpose of the PDR is to find problems and see what is missing, not to fix anything.
The result of the meeting is documented in a written report. Attendees should prepare for PDRs by reading through documents, before the meeting starts; most problems are found during this preparation.
Why are PDRs so useful? Because PDRs are cost-effective methods of ensuring quality, because bug prevention is more cost effective than bug detection.
Q: 5 How do you test the password field?
A: To test the password field, we do boundary value testing.
Q: 6 How do you check the security of your application?
A: To check the security of an application, we can use security/penetration testing. Security/penetration testing is testing how well the system is protected against unauthorized internal or external access, or willful damage.
This type of testing usually requires sophisticated testing techniques.
Q: 7 When testing the password field, what is your focus?
A: When testing the password field, one needs to verify that passwords are encrypted.
Q: 8 What is the objective of regression testing?
A: The objective of regression testing is to test that the fixes have not created any other problems elsewhere. In other words, the objective is to ensure the software has remained intact.
A baseline set of data and scripts are maintained and executed, to verify that changes introduced during the release have not "undone" any previous code.
Expected results from the baseline are compared to results of the software under test. All discrepancies are highlighted and accounted for, before testing proceeds to the next level.
Q: 9 What stage of bug fixing is the most cost effective?
A: Bug prevention, i.e. inspections, PDRs, and walk-throughs, is more cost effective than bug detection.
Q: 10 What types of white box testing can you tell me about?
A: White box testing is a testing approach that examines the application's program structure, and derives test cases from the application's program logic.
Clear box testing is a white box type of testing. Glass box testing is also a white box type of testing. Open box testing is also a white box type of testing.
Q: 11 What black box testing types can you tell me about?
A: Black box testing is functional testing, not based on any knowledge of internal software design or code.
Black box testing is based on requirements and functionality. Functional testing is also a black-box type of testing geared to functional requirements of an application.
System testing is also a black box type of testing. Acceptance testing is also a black box type of testing. Functional testing is also a black box type of testing. Closed box testing is also a black box type of testing. Integration testing is also a black box type of testing.
Q: 12 Is regression testing performed manually?
A: It depends on the initial testing approach. If the initial testing approach was manual testing, then the regression testing is normally performed manually.
Conversely, if the initial testing approach was automated testing, then the regression testing is normally performed by automated testing.
Q: 13 Give me others' FAQs on testing.
A: Here is what you can do. You can visit my web site, and on robdavispe.com/free and robdavispe.com/free2 you will find answers to the vast majority of others' questions on testing, from a tester's point of view.
As to questions and answers that are not on my web site now, please be patient, as I am going to add more FAQs and answers, as soon as time permits.
Q: 14 Can you share with me your knowledge of software testing?
A: Surely I can. Visit my web site, and on robdavispe.com/free and robdavispe.com/free2 you will find my knowledge on software testing, from a tester's point of view.
As to knowledge that is not on my web site now, please be patient, as I am going to add more answers, as soon as time permits.
Q: 15 How can I learn software testing?
A: I suggest you visit my web site, especially robdavispe.com/free and robdavispe.com/free2, and you will find answers to most questions on software testing. As to questions and answers that are not on my web site at the moment, please be patient. I will add more questions and answers, as soon as time permits.
I also suggest you get a job in software testing. Why? Because you can get additional, free education, on the job, by an employer, while you are being paid to do software testing. On the job, you will be able to use some of the more popular software tools, including WinRunner, LoadRunner, LabView, and the Rational Toolset. The tools you use will depend on the end client, their needs and preferences.
I also suggest you sign up for courses at nearby educational institutions. Classroom education, especially non-degree courses in local community colleges, tends to be inexpensive.
Q: 16 What is your view of software QA/testing?
A: Software QA/testing is easy, if requirements are solid, clear, complete, detailed, cohesive, attainable and testable, and if schedules are realistic, and if there is good communication.
Software QA/testing is a piece of cake, if project schedules are realistic, if adequate time is allowed for planning, design, testing, bug fixing, re-testing, changes, and documentation.
Q: 17 What is your view of software QA/testing? (Cont'd...)
Software QA/testing is relatively easy, if testing is started early on, and if fixes or changes are re-tested, and if sufficient time is planned for both testing and bug fixing.
Software QA/testing is easy, if new features are avoided, and if one sticks to initial requirements as much as possible.
Q: 18 How can I be a good tester?
A: We, good testers, take the customers' point of view. We are tactful and diplomatic. We have a "test to break" attitude, a strong desire for quality, an attention to detail, and good communication skills, both oral and written.
Previous software development experience is also helpful as it provides a deeper understanding of the software development process.
Q: 19 What is the difference between software bug and software defect?
A: A 'software bug' is a nonspecific term that means an inexplicable defect, error, flaw, mistake, failure, fault, or unwanted behavior of a computer program.
Other terms, e.g. software defect and software failure, are more specific.
There are many who believe the word 'bug' is a reference to insects that caused malfunctions in early electromechanical computers (in the 1950s and 1960s), the truth is the word 'bug' has been part of engineering jargon for 100+ years. Thomas Edison, the great inventor, wrote the followings in 1878: "It has been just so in all of my inventions. The first step is an intuition, and comes with a burst, then difficulties arise—this thing gives out and [it is] then that "Bugs" — as such little faults and difficulties are called — show themselves and months of intense watching, study and labor are requisite before commercial success or failure is certainly reached."
Q: 20 How can I improve my career in software QA/testing?
A: Invest in your skills! Learn all you can! Visit my web site, and on http://robdavispe.com/free and http://robdavispe.com/free2, you will find answers to the vast majority of questions on testing, from software QA/testers' point of view.
Get additional education, on the job. Free education is often provided by employers, while you are paid to do the job of a tester. On the job, often you can use many software tools, including WinRunner, LoadRunner, LabView, and Rational Toolset. Find an employer whose needs and preferences are similar to yours.
Get an education! Sign up for courses at nearby educational institutes. Take classes! Classroom education, especially non-degree courses in local community colleges, tends to be inexpensive. Improve your attitude! Become the best software QA/tester! Always strive to exceed the expectations of your customers!
Q: 21 How do you compare two files?
A: Use PVCS, SCCS, or "diff". PVCS is a document version control tool, a competitor of SCCS. SCCS is an original UNIX program, based on "diff". Diff is a UNIX utility that compares the difference between two text files.
Q: 22 What do we use for comparison?
A: Generally speaking, when we write a software program to compare files, we compare two files, bit by bit. For example, when we use "diff", a UNIX utility, we compare two text files.
Q: 23 What is the reason we compare files?
A: We compare files because of configuration management, revision control, requirement version control, or document version control. Examples are Rational ClearCase, DOORS, PVCS, and CVS. CVS, for example, enables several, often distant, developers to work together on the same source code.
Q: 24 When is a process repeatable?
A: If we use detailed and well-written processes and procedures, we ensure the correct steps are being executed. This facilitates a successful completion of a task. This is a way we also ensure a process is repeatable.
Q: 25 What is test methodology?
A: One test methodology is a three-step process. Creating a test strategy, creating a test plan/design, and executing tests. This methodology can be used and molded to your organization's needs.
Rob Davis believes that using this methodology is important in the development and ongoing maintenance of his customers' applications.
Q: 26 What does a Test Strategy Document contain?
A: The test strategy document is a formal description of how a software product will be tested. A test strategy is developed for all levels of testing, as required.
The test team analyzes the requirements, writes the test strategy and reviews the plan with the project team.
The test plan may include test cases, conditions, the test environment, and a list of related tasks, pass/fail criteria and risk assessment.
Additional sections in the test strategy document include:
A description of the required hardware and software components, including test tools. This information comes from the test environment, including test tool data.
A description of roles and responsibilities of the resources required for the test and schedule constraints. This information comes from man-hours and schedules.
Testing methodology. This is based on known standards.
Functional and technical requirements of the application. This information comes from requirements, change request, technical, and functional design documents.
Requirements that the system cannot provide, e.g. system limitations.
1 comments:
Thanks for the detailed information....
Post a Comment