Set 7 of Interview FAQs
Q: 1 How can I start my career in automated testing?
A: Number one: 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.
Two, get hands-on experience on how to use automated testing tools.
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, and many other automated testing tools, with little or no outside help. Click on a link!
Q: 2 What is monkey testing?
A: "Monkey testing" is random testing performed by automated testing tools. These automated testing tools are considered "monkeys", if they work at random.
We call them "monkeys" because it is widely believed, if we allow six monkeys to pound on six typewriters at random, for a million years, they will recreate all the works of Isaac Asimov.
There are "smart monkeys" and "dumb monkeys".
"Smart monkeys" are valuable for load and stress testing, and will find a significant number of bugs, but they're also very expensive to develop.
"Dumb monkeys", on the other hand, are inexpensive to develop, are able to do some basic testing, but they will find few bugs. However, the bugs "dumb monkeys" do find will be hangs and crashes, i.e. the bugs you least want to have in your software product.
"Monkey testing" can be valuable, but they should not be your only testing.
Q: 3 What is stochastic testing?
A: Stochastic testing is the same as "monkey testing", but stochastic testing is a more technical sounding name for the same testing process.
Stochastic testing is black box testing, random testing, performed by automated testing tools. Stochastic testing is a series of random tests over time.
The software under test typically passes the individual tests, but our goal is to see if it can pass a large series of the individual tests.
Q: 4 What is mutation testing?
A: In mutation testing, we create mutant software, we make mutant software to fail, and thus demonstrate the adequacy of our test case.
When we create a set of mutant software, each mutant software differs from the original software by one mutation, i.e. one single syntax change made to one of its program statements, i.e. each mutant software contains only one single fault.
When we apply test cases to the original software and to the mutant software, we evaluate if our test case is adequate.
Our test case is inadequate, if both the original software and all mutant software generate the same output.
Our test case is adequate, if our test case detects faults, or, if, at least one mutant software generates a different output than does the original software for our test case.
Q: 5 What is PDR?
A: PDR is an acronym. In the world of software QA/testing, it stands for "peer design review", or "peer review".
Q: 6 What is is good about PDRs?
A: PDRs are informal meetings, and I do like all informal meetings. PDRs make perfect sense, because they're for the mutual benefit of you and your end client.
Your end client requires a PDR, because they work on a product, and want to come up with the very best possible design and documentation.
Your end client requires you to have a PDR, because when you organize a PDR, you invite and assemble the end client's best experts and encourage them to voice their concerns as to what should or should not go into the design and documentation, and why.
When you're a developer, designer, author, or writer, it's also to your advantage to come up with the best possible design and documentation.
Therefore you want to embrace the idea of the PDR, because holding a PDR gives you a significant opportunity to invite and assemble the end client's best experts and make them work for you for one hour, for your own benefit.
To come up with the best possible design and documentation, you want to encourage your end client's experts to speak up and voice their concerns as to what should or should not go into your design and documentation, and why.
Q: 7 Why is that my company requires a PDR?
A: Your company requires a PDR, because your company wants to be the owner of the very best possible design and documentation. Your company requires a PDR, because when you organize a PDR, you invite, assemble and encourage the company's best experts to voice their concerns as to what should or should not go into your design and documentation, and why.
Remember, PDRs are not about you, but about design and documentation. Please don't be negative; please do not assume your company is finding fault with your work, or distrusting you in any way. There is a 90+ per cent probability your company wants you, likes you and trust you, because you're a specialist, and because your company hired you after a long and careful selection process.
Your company requires a PDR, because PDRs are useful and constructive. Just about everyone - even corporate chief executive officers (CEOs) - attend PDRs from time to time. When a corporate CEO attends a PDR, he has to listen for "feedback" from shareholders. When a CEO attends a PDR, the meeting is called the "annual shareholders' meeting".
Q: 8 Give me a list of ten good things about PDRs!
A: Number 1: PDRs are easy, because all your meeting attendees are your co-workers and friends.
Number 2: PDRs do produce results. With the help of your meeting attendees, PDRs help you produce better designs and better documents than the ones you could come up with, without the help of your meeting attendees.
Number 3: Preparation for PDRs helps a lot, but, in the worst case, if you had no time to read every page of every document, it's still OK for you to show up at the PDR.
Number 4: It's technical expertise that counts the most, but many times you can influence your group just as much, or even more so, if you're dominant or have good acting skills.
Number 5: PDRs are easy, because, even at the best and biggest companies, you can dominate the meeting by being either very negative, or very bright and wise.
Number 6: It is easy to deliver gentle suggestions and constructive criticism. The brightest and wisest meeting attendees are usually gentle on you; they deliver gentle suggestions that are constructive, not destructive.
Number 7: You get many-many chances to express your ideas, every time a meeting attendee asks you to justify why you wrote what you wrote.
Number 8: PDRs are effective, because there is no need to wait for anything or anyone; because the attendees make decisions quickly (as to what errors are in your document). There is no confusion either, because all the group's recommendations are clearly written down for you by the PDR's facilitator.
Number 9: Your work goes faster, because the group itself is an independent decision making authority. Your work gets done faster, because the group's decisions are subject to neither oversight nor supervision.
Number 10: At PDRs, your meeting attendees are the very best experts anyone can find, and they work for you, for FREE!
Q: 9 What is the Exit criteria?
A: "Exit criteria" is a checklist, sometimes known as the "PDR sign-off sheet", i.e. a list of peer design review related tasks that have to be done by the facilitator or other attendees of the PDR, during or near the conclusion of the PDR.
By having a checklist, and by going through a checklist, the facilitator can...
1. Verify that the attendees have inspected all the relevant documents and reports, and
2. Verify that all suggestions and recommendations for each issue have been recorded, and
3. Verify that all relevant facts of the meeting have been recorded.
The facilitator's checklist includes the following questions:
1. "Have we inspected all the relevant documents, code blocks, or products?"
2. "Have we completed all the required checklists?"
3. "Have I recorded all the facts relevant to this peer review?"
4. "Does anyone have any additional suggestions, recommendations, or comments?"
5. "What is the outcome of this peer review?" At the end of the peer review, the facilitator asks the attendees of the peer review to make a decision as to the outcome of the peer review. I.e., "What is our consensus?" "Are we accepting the design (or document or code)?"
Or, "Are we accepting it with minor modifications?"Or, "Are we accepting it, after it is modified, and approved through e-mails to the participants?" Or, "Do we want another peer review?" This is a phase, during which the attendees of the PDR work as a committee, and the committee's decision is final.
Q: 10 What is the Entry criteria?
A: The entry criteria is a checklist, or a combination of checklists that includes the "developer's checklist", "testing checklist", and the "PDR checklist". Checklists are list of tasks that have to be done by developers, testers, or the facilitator, at or before the start of the peer review.
Using these checklists, before the start of the peer review, the developer, tester and facilitator can determine if all the documents, reports, code blocks or software products are ready to be reviewed, and if the peer review's attendees are prepared to inspect them. The facilitator can ask the peer review's attendees if they have been able to prepare for the peer review, and if they're not well prepared, the facilitator can send them back to their desks, and even ask the task lead to reschedule the peer review.
The facilitator's script for the entry criteria includes the following questions:
1. Are all the required attendees present at the peer review?
2. Have all the attendees received all the relevant documents and reports?
3. Are all the attendees well prepared for this peer review?
4. Have all the preceding life cycle activities been concluded?
5. Are there any changes to the baseline?
A: Number one: 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.
Two, get hands-on experience on how to use automated testing tools.
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, and many other automated testing tools, with little or no outside help. Click on a link!
Q: 2 What is monkey testing?
A: "Monkey testing" is random testing performed by automated testing tools. These automated testing tools are considered "monkeys", if they work at random.
We call them "monkeys" because it is widely believed, if we allow six monkeys to pound on six typewriters at random, for a million years, they will recreate all the works of Isaac Asimov.
There are "smart monkeys" and "dumb monkeys".
"Smart monkeys" are valuable for load and stress testing, and will find a significant number of bugs, but they're also very expensive to develop.
"Dumb monkeys", on the other hand, are inexpensive to develop, are able to do some basic testing, but they will find few bugs. However, the bugs "dumb monkeys" do find will be hangs and crashes, i.e. the bugs you least want to have in your software product.
"Monkey testing" can be valuable, but they should not be your only testing.
Q: 3 What is stochastic testing?
A: Stochastic testing is the same as "monkey testing", but stochastic testing is a more technical sounding name for the same testing process.
Stochastic testing is black box testing, random testing, performed by automated testing tools. Stochastic testing is a series of random tests over time.
The software under test typically passes the individual tests, but our goal is to see if it can pass a large series of the individual tests.
Q: 4 What is mutation testing?
A: In mutation testing, we create mutant software, we make mutant software to fail, and thus demonstrate the adequacy of our test case.
When we create a set of mutant software, each mutant software differs from the original software by one mutation, i.e. one single syntax change made to one of its program statements, i.e. each mutant software contains only one single fault.
When we apply test cases to the original software and to the mutant software, we evaluate if our test case is adequate.
Our test case is inadequate, if both the original software and all mutant software generate the same output.
Our test case is adequate, if our test case detects faults, or, if, at least one mutant software generates a different output than does the original software for our test case.
Q: 5 What is PDR?
A: PDR is an acronym. In the world of software QA/testing, it stands for "peer design review", or "peer review".
Q: 6 What is is good about PDRs?
A: PDRs are informal meetings, and I do like all informal meetings. PDRs make perfect sense, because they're for the mutual benefit of you and your end client.
Your end client requires a PDR, because they work on a product, and want to come up with the very best possible design and documentation.
Your end client requires you to have a PDR, because when you organize a PDR, you invite and assemble the end client's best experts and encourage them to voice their concerns as to what should or should not go into the design and documentation, and why.
When you're a developer, designer, author, or writer, it's also to your advantage to come up with the best possible design and documentation.
Therefore you want to embrace the idea of the PDR, because holding a PDR gives you a significant opportunity to invite and assemble the end client's best experts and make them work for you for one hour, for your own benefit.
To come up with the best possible design and documentation, you want to encourage your end client's experts to speak up and voice their concerns as to what should or should not go into your design and documentation, and why.
Q: 7 Why is that my company requires a PDR?
A: Your company requires a PDR, because your company wants to be the owner of the very best possible design and documentation. Your company requires a PDR, because when you organize a PDR, you invite, assemble and encourage the company's best experts to voice their concerns as to what should or should not go into your design and documentation, and why.
Remember, PDRs are not about you, but about design and documentation. Please don't be negative; please do not assume your company is finding fault with your work, or distrusting you in any way. There is a 90+ per cent probability your company wants you, likes you and trust you, because you're a specialist, and because your company hired you after a long and careful selection process.
Your company requires a PDR, because PDRs are useful and constructive. Just about everyone - even corporate chief executive officers (CEOs) - attend PDRs from time to time. When a corporate CEO attends a PDR, he has to listen for "feedback" from shareholders. When a CEO attends a PDR, the meeting is called the "annual shareholders' meeting".
Q: 8 Give me a list of ten good things about PDRs!
A: Number 1: PDRs are easy, because all your meeting attendees are your co-workers and friends.
Number 2: PDRs do produce results. With the help of your meeting attendees, PDRs help you produce better designs and better documents than the ones you could come up with, without the help of your meeting attendees.
Number 3: Preparation for PDRs helps a lot, but, in the worst case, if you had no time to read every page of every document, it's still OK for you to show up at the PDR.
Number 4: It's technical expertise that counts the most, but many times you can influence your group just as much, or even more so, if you're dominant or have good acting skills.
Number 5: PDRs are easy, because, even at the best and biggest companies, you can dominate the meeting by being either very negative, or very bright and wise.
Number 6: It is easy to deliver gentle suggestions and constructive criticism. The brightest and wisest meeting attendees are usually gentle on you; they deliver gentle suggestions that are constructive, not destructive.
Number 7: You get many-many chances to express your ideas, every time a meeting attendee asks you to justify why you wrote what you wrote.
Number 8: PDRs are effective, because there is no need to wait for anything or anyone; because the attendees make decisions quickly (as to what errors are in your document). There is no confusion either, because all the group's recommendations are clearly written down for you by the PDR's facilitator.
Number 9: Your work goes faster, because the group itself is an independent decision making authority. Your work gets done faster, because the group's decisions are subject to neither oversight nor supervision.
Number 10: At PDRs, your meeting attendees are the very best experts anyone can find, and they work for you, for FREE!
Q: 9 What is the Exit criteria?
A: "Exit criteria" is a checklist, sometimes known as the "PDR sign-off sheet", i.e. a list of peer design review related tasks that have to be done by the facilitator or other attendees of the PDR, during or near the conclusion of the PDR.
By having a checklist, and by going through a checklist, the facilitator can...
1. Verify that the attendees have inspected all the relevant documents and reports, and
2. Verify that all suggestions and recommendations for each issue have been recorded, and
3. Verify that all relevant facts of the meeting have been recorded.
The facilitator's checklist includes the following questions:
1. "Have we inspected all the relevant documents, code blocks, or products?"
2. "Have we completed all the required checklists?"
3. "Have I recorded all the facts relevant to this peer review?"
4. "Does anyone have any additional suggestions, recommendations, or comments?"
5. "What is the outcome of this peer review?" At the end of the peer review, the facilitator asks the attendees of the peer review to make a decision as to the outcome of the peer review. I.e., "What is our consensus?" "Are we accepting the design (or document or code)?"
Or, "Are we accepting it with minor modifications?"Or, "Are we accepting it, after it is modified, and approved through e-mails to the participants?" Or, "Do we want another peer review?" This is a phase, during which the attendees of the PDR work as a committee, and the committee's decision is final.
Q: 10 What is the Entry criteria?
A: The entry criteria is a checklist, or a combination of checklists that includes the "developer's checklist", "testing checklist", and the "PDR checklist". Checklists are list of tasks that have to be done by developers, testers, or the facilitator, at or before the start of the peer review.
Using these checklists, before the start of the peer review, the developer, tester and facilitator can determine if all the documents, reports, code blocks or software products are ready to be reviewed, and if the peer review's attendees are prepared to inspect them. The facilitator can ask the peer review's attendees if they have been able to prepare for the peer review, and if they're not well prepared, the facilitator can send them back to their desks, and even ask the task lead to reschedule the peer review.
The facilitator's script for the entry criteria includes the following questions:
1. Are all the required attendees present at the peer review?
2. Have all the attendees received all the relevant documents and reports?
3. Are all the attendees well prepared for this peer review?
4. Have all the preceding life cycle activities been concluded?
5. Are there any changes to the baseline?
0 comments:
Post a Comment