Set 8 of Interview FAQs

Q: 1 What are the parameters of peer reviews?

A: By definition, parameters are values on which something else depends. Peer reviews depend on the attendance and active participation of several key people; usually the facilitator, task lead, test lead, and at least one additional reviewer.

The attendance of these four people are usually required for the approval of the PDR. According to company policy, depending on your company, other participants are often invited, but generally not required for approval.

Peer reviews depend on the facilitator, sometimes known as the moderator, who controls the meeting, keeps the meeting on schedule, and records all suggestions from all attendees.

Peer reviews greatly depend on the developer, also known as the designer, author, or task lead -- usually a software engineer -- who is most familiar with the project, and most likely able to answer any questions or address any concerns that may come up during the peer review.

Peer reviews greatly depend on the tester, also known as test lead, or bench test person -- usually another software engineer -- who is also familiar with the project, and most likely able to answer any questions or address any concers that may come up during the peer review.

Peer reviews greatly depend on the participation of additional reviewers and additional attendees who often make specific suggestions and recommendations, and ask the largest number of questions.

Q: 2 Have you attended any review meetings?

A: Yes, in the last 10+ years I have attended many review meetings; mostly peer reviews. In today's corporate world, the vast majority of review meetings are peer review meetings.

In my experience, the most useful peer reviews are the ones where you're the author of something. Why? Because when you're the author, then it's you who decides what to do and how, and it's you who receives all the free help.

In my experience, on the long run, the inputs of your additional reviewers and additional attendees can be the most valuable to you and your company. But, in your own best interest, in order to expedite things, before every peer review it is a good idea to get together with the additional reviewer and additional attendee, and talk with them about issues, because if you don't, they will be the ones with the largest number of questions and usually negative feedback.

When a PDR is done right, it is useful, beneficial, pleasant, and friendly. Generally speaking, the fewer people show up at the PDR, the easier it tends to be, and the earlier it can be adjourned.

When you're an author, developer, or task lead, many times you can relax, because during your peer review your facilitator and test lead are unlikely to ask any tough questions from you. Why? Because, the facilitator is too busy taking notes, and the test lead is kind of bored (because he had already asked his toughest questions before the PDR).

When you're a facilitator, every PDR tends to be a pleasant experience. In my experience, one of the easiest review meetings are PDRs where you're the facilitator (whose only job is to call the shots and make notes).

Q: 3 What types of review meetings can you tell me about?

A: Of review meetings, peer design reviews are the most common. Peer design reviews are so common that they tend to replace both inspections and walk-throughs.

Peer design reviews can be classified according to the 'subject' of the review. I.e., "Is this a document review, design review, or code review?"

Peer design reviews can be classified according to the 'role' you play at the meeting. I.e., "Are you the task lead, test lead, facilitator, moderator, or additional reviewer?"

Peer design reviews can be classified according to the 'job title of attendees. I.e., "Is this a meeting of peers, managers, systems engineers, or system integration testers?"

Peer design reviews can be classified according to what is being reviewed at the meeting. I.e., "Are we reviewing the work of a developer, tester, engineer, or technical document writer?"

Peer design reviews can be classified according to the 'objective' of the review. I.e., "Is this document for the file cabinets of our company, or that of the government (e.g. the FAA or FDA)?"

PDRs of government documents tend to attract the attention of managers, and the meeting quickly becomes a meeting of managers.

Q: 4 How can I shift my focus and area of work from QC to QA?

A: Number one, focus on your strengths, skills, and abilities! Realize that there are MANY similarities between Quality Control and Quality Assurance! Realize that you have MANY transferable skills!

Number two, make a plan! Develop a belief that getting a job in QA is easy! HR professionals cannot tell the difference between quality control and quality assurance! HR professionals tend to respond to keywords (i.e. QC and QA), without knowing the exact meaning of those keywords!

Number three, make it a reality! Invest your time! Get some hands-on experience! Do some QA work! Do any QA work, even if, for a few months, you get paid a little less than usual! Your goals, beliefs, enthusiasm, and action will make a huge difference in your life!

Number four, I suggest you read all you can, and that includes reading product pamphlets, manuals, books, information on the Internet, and whatever information you can lay your hands on! If there is a will, there is a way! You CAN do it, if you put your mind to it! You CAN learn to do QA work, with little or no outside help! Click on a link!


Q: 5 What techniques and tools can enable me to migrate from QC to QA?

A: Technique number one is mental preparation. Understand and believe what you want is not unusual at all! Develop a belief in yourself! Start believing what you want is attainable! You can change your career! Every year, millions of men and women change their careers successfully!

Number two, make a plan! Develop a belief that getting a job in QA is easy! HR professionals cannot tell the difference between quality control and quality assurance! HR professionals tend to respond to keywords (i.e. QC and QA), without knowing the exact meaning of those keywords!

Number three, make it a reality! Invest your time! Get some hands-on experience! Do some QA work! Do any QA work, even if, for a few months, you get paid a little less than usual! Your goals, beliefs, enthusiasm, and action will make a huge difference in your life!

Number four, I suggest you read all you can, and that includes reading product pamphlets, manuals, books, information on the Internet, and whatever information you can lay your hands on!

If there is a will, there is a way! You CAN do it, if you put your mind to it! You CAN learn to do QA work, with little or no outside help! Click on a link!


Q: 6 What is the difference between build and release?

A: Builds and releases are similar, because both builds and releases are end products of software development processes. Builds and releases are similar, because both builds and releases help developers and QA teams to deliver reliable software.

Build means a version of a software, typically one that is still in testing. Usually a version number is given to a released product, but, sometimes, a build number is used instead.

Difference number one: Builds refer to software that is still in testing, release refers to software that is usually no longer in testing.

Difference number two: Builds occur more frequently; releases occur less frequently.

Difference number three: Versions are based on builds, and not vice versa. Builds, or usually a series of builds, are generated first, as often as one build per every morning, depending on the company, and then every release is based on a build, or several builds, i.e. the accumulated code of several builds.


Q: 7 What is CMM?

A: CMM is an acronym that stands for Capability Maturity Model. The idea of CMM is, as to future efforts in developing and testing software, concepts and experiences do not always point us in the right direction, therefore we should develop processes, and then refine those processes.

There are five CMM levels, of which Level 5 is the highest...

CMM Level 1 is called "Initial".
CMM Level 2 is called "Repeatable".
CMM Level 3 is called "Defined".
CMM Level 4 is called "Managed".
CMM Level 5 is called "Optimized".

There are not many Level 5 companies; most hardly need to be. Within the United States, fewer than 8% of software companies are rated CMM Level 4, or higher. The U.S. government requires that all companies with federal government contracts to maintain a minimum of a CMM Level 3 assessment.

CMM assessments take two weeks. They're conducted by a nine-member team led by a SEI-certified lead assessor.

Q: 8 What are CMM levels and their definitions?

A: There are five CMM levels of which level 5 is the highest.

CMM level 1 is called "initial". The software process is at CMM level 1, if it is an ad hoc process. At CMM level 1, few processes are defined, and success, in general, depends on individual effort and heroism.

CMM level 2 is called "repeatable". The software process is at CMM level 2, if the subject company has some basic project management processes, in order to track cost, schedule, and functionality. Software processes are at CMM level 2, if necessary processes are in place, in order to repeat earlier successes on projects with similar applications. Software processes are at CMM level 2, if there are requirements management, project planning, project tracking, subcontract management, QA, and configuration management.

CMM level 3 is called "defined". The software process is at CMM level 3, if the software process is documented, standardized, and integrated into a standard software process for the subject company. The software process is at CMM level 3, if all projects use approved, tailored versions of the company's standard software process for developing and maintaining software. Software processes are at CMM level 3, if there are process definition, training programs, process focus, integrated software management, software product engineering, intergroup coordination, and peer reviews.

CMM level 4 is called "managed". The software process is at CMM level 4, if the subject company collects detailed data on the software process and product quality, and if both the software process and the software products are quantitatively understood and controlled. Software processes are at CMM level 4, if there are software quality management (SQM) and quantitative process management.

CMM level 5 is called "optimized". The software process is at CMM level 5, if there is continuous process improvement, if there is quantitative feedback from the process and from piloting innovative ideas and technologies. Software processes are at CMM level 5, if there are process change management, and defect prevention technology change management.


Q: 9 What is the difference between bug and defect in software testing?

A: In software testing, the difference between bug and defect is small, and depends on your company. For some companies, bug and defect are synonymous, while others believe bug is a subset of defect.

Generally speaking, we, software test engineers, discover BOTH bugs and defects, before bugs and defects damage the reputation of our company. We, QA engineers, use the software much like real users would, to find BOTH bugs and defects, to find ways to replicate BOTH bugs and defects, to 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. Therefore, we, software QA engineers, do not differentiate between bugs and defects. In our bug reports, we include BOTH bugs and defects, and any differences between them are minor.

Difference number one: In bug reports, the defects are usually easier to describe.

Difference number two: In bug reports, it is usually easier to write the descriptions on how to replicate the defects. Defects tend to require brief explanations only.

Read more...

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?

Read more...

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.

Read more...

Set 5 of Interview FAQs

Q: 1 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: 2 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: 3 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.

Q: 4 What software tools are in demand these days?

A: There is no good answer to this question. The answer to this question can and will change from day to day. What is in demand today, is not necessarily in demand tomorrow.

To give you some recent examples, some of the software tools on end clients' lists of requirements include LabView, LoadRunner, Rational Tools and Winrunner.

But, as a general rule of thumb, there are many-many other items on their lists, depending on the end client, their needs and preferences.

It is worth repeating... the answer to this question can and will change from one day to the next. What is in demand today will not likely be in demand tomorrow.


Q: 5 Which of these tools should I learn?

A: I suggest you learn some of the most popular software tools (e.g. WinRunner, LoadRunner, LabView, and Rational Rose, etc.) with special attention paid to the Rational Toolset and LoadRunner.

Q: 6 What is software configuration management?

A: Software Configuration management (SCM) relates to Configuration Management (CM).

SCM is the control, and the recording of, changes that are made to the software and documentation throughout the software development life cycle (SDLC).

SCM covers the tools and processes used to control, coordinate and track code, requirements, documentation, problems, change requests, designs, tools, compilers, libraries, patches, and changes made to them, and to keep track of who makes the changes.

We, test engineers have experience with a full range of CM tools and concepts, and can easily adapt to an organization's software tool and process needs.


Q: 7 What are some of the software configuration management tools?

A: Software configuration management tools include Rational ClearCase, DOORS, PVCS, CVS; and there are many others. Rational ClearCase is a popular software tool, made by Rational Software, for revision control of source code.

DOORS, or "Dynamic Object Oriented Requirements System", is a requirements version control software tool.

CVS, or "Concurrent Version System", is a popular, open source version control system to keep track of changes in documents associated with software projects. CVS enables several, often distant, developers to work together on the same source code.

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: 8 Which of these roles are the best and most popular?

A: In testing, Tester roles tend to be the most popular. The less popular roles include the roles of System Administrator, Test/QA Team Lead, and Test/QA Managers.


Q: 9 What other roles are in testing?

A: Depending on the organization, the following roles are more or less standard on most testing projects: Testers, Test Engineers, Test/QA Team Leads, Test/QA Managers, System Administrators, Database Administrators, Technical Analysts, Test Build Managers, and Test Configuration Managers.

Depending on the project, one person can and often wear more than one hat. For instance, we Test Engineers often wear the hat of Technical Analyst, Test Build Manager and Test Configuration Manager as well.


Q: 10 What's the difference between priority and severity?

A: The simple answer is, "Priority is about scheduling, and severity is about standards."

The complex answer is, "Priority means something is afforded or deserves prior attention; a precedence established by order of importance (or urgency). Severity is the state or quality of being severe; severe implies adherence to rigorous standards or high principles and often suggests harshness; severe is marked by or requires strict adherence to rigorous standards or high principles, e.g. a severe code of behavior."

Q: 11 What's the difference between efficient and effective?

A: "Efficient" means having a high ratio of output to input; working or producing with a minimum of waste. For example, "An efficient test engineer wastes no time", or "An efficient engine saves gas".

"Effective", on the other hand, means producing, or capable of producing, an intended result, or having a striking effect. For example, "For automated testing, WinRunner is more effective than an oscilloscope", or "For rapid long-distance transportation, the jet engine is more effective than a witch's broomstick".


Q: 12 What is the difference between verification and validation?

A: Verification takes place before validation, and not vice versa. Verification evaluates documents, plans, code, requirements, and specifications. Validation, on the other hand, evaluates the product itself.

The inputs of verification are checklists, issues lists, walk-throughs and inspection meetings, reviews and meetings. The input of validation, on the other hand, is the actual testing of an actual product.

The output of verification is a nearly perfect set of documents, plans, specifications, and requirements document. The output of validation, on the other hand, is a nearly perfect, actual product.

Q: 13 What is documentation change management?

A: Documentation change management is part of configuration management (CM). CM covers the tools and processes used to control, coordinate and track code, requirements, documentation, problems, change requests, designs, tools, compilers, libraries, patches, changes made to them and who makes the changes.

Rob Davis has had experience with a full range of CM tools and concepts. Rob Davis can easily adapt to your software tool and process needs.


Q: 14 What is up time?

A: "Up time" is the time period when a system is operational and in service. Up time is the sum of busy time and idle time.

For example, if, out of 168 hours, a system has been busy for 50 hours, idle for 110 hours, and down for 8 hours, then the busy time is 50 hours, idle time is 110 hours, and up time is (110 + 50 =) 160 hours.


Q: 15 What is upwardly compatible software?

A: Upwardly compatible software is compatible with a later or more complex version of itself. For example, an upwardly compatible software is able to handle files created by a later version of itself.

Q: 16 What is upward compression?

A: In software design, upward compression means a form of demodularization, in which a subordinate module is copied into the body of a superior module.


Q: 17 What is usability?

A: Usability means ease of use; the ease with which a user can learn to operate, prepare inputs for, and interpret outputs of a software product.


Q: 18 What is user documentation?

A: User documentation is a document that describes the way a software product or system should be used to obtain the desired results.


Q: 19 What is a user manual?

A: User manual is a document that presents information necessary to employ software or a system to obtain the desired results.

Typically, what is described are system and component capabilities, limitations, options, permitted inputs, expected outputs, error messages, and special instructions.

Q: 20 What is a vertical microinstruction?

A: A vertical microinstruction is a microinstruction that specifies one of a sequence of operations needed to carry out a machine language instruction. Vertical microinstructions are short, 12 to 24 bit instructions. They're called vertical because they are normally listed vertically on a page. These 12 to 24 bit microinstructions instructions are required to carry out a single machine language instruction.

Besides vertical microinstructions, there are horizontal as well as diagonal microinstructions as well.


Q: 21 What is a virtual address?

A: In virtual storage systems, virtual addresses are assigned to auxiliary storage locations. They allow those location to be accessed as though they were part of the main storage.


Q: 22 What is virtual memory?

A: Virtual memory relates to virtual storage. In virtual storage, portions of a user's program and data are placed in auxiliary storage, and the operating system automatically swaps them in and out of main storage as needed.


Q: 23 What is virtual storage?

A: Virtual storage is a storage allocation technique, in which auxiliary storage can be addressed as though it was part of main storage. Portions of a user's program and data are placed in auxiliary storage, and the operating system automatically swaps them in and out of main storage as needed.


Q: 24 What is a waiver?

A: Waivers are authorizations to accept software that has been submitted for inspection, found to depart from specified requirements, but is nevertheless considered suitable for use "as is", or after rework by an approved method.


Q: 25 What is the waterfall model?

A: Waterfall is a model of the software development process in which the concept phase, requirements phase, design phase, implementation phase, test phase, installation phase, and checkout phase are performed in that order, probably with overlap, but with little or no iteration.


Q: 26 What are the phases of the software development process?

A: Software development process consists of the concept phase, requirements phase, design phase, implementation phase, test phase, installation phase, and checkout phase.


Q: 27 What models are used in software development?

A: In software development process the following models are used: waterfall model, incremental development model, rapid prototyping model, and spiral model.

Q: 28 What is SDLC?

A: SDLC is an acronym. It stands for "software development life cycle".


Q: 29 What is the difference between system testing and integration testing?

A: System testing is high level testing, and integration testing is a lower level testing. Integration testing is completed first, not the system testing. In other words, upon completion of integration testing, system testing is started, and not vice versa.

For integration testing, test cases are developed with the express purpose of exercising the interfaces between the components.

For system testing, on the other hand, the complete system is configured in a controlled environment, and test cases are developed to simulate real life scenarios that occur in a simulated real life test environment.

The purpose of integration testing is to ensure distinct components of the application still work in accordance to customer requirements.

The purpose of system testing, on the other hand, is to validate an application's accuracy and completeness in performing the functions as designed, and to test all functions of the system that are required in real life.

Read more...

Set 4 of Interview FAQs

Q: 1 What software tools are in demand these days?

A: There is no good answer to this question. The answer to this question can and will change from day to day. What is in demand today, is not necessarily in demand tomorrow.

To give you some recent examples, some of the software tools on end clients' lists of requirements include LabView, LoadRunner, Rational Tools and Winrunner.

But, as a general rule of thumb, there are many-many other items on their lists, depending on the end client, their needs and preferences.

It is worth repeating... the answer to this question can and will change from one day to the next. What is in demand today will not likely be in demand tomorrow.


Q: 2 Which of these tools should I learn?

A: I suggest you learn some of the most popular software tools (e.g. WinRunner, LoadRunner, LabView, and Rational Rose, etc.) with special attention paid to the Rational Toolset and LoadRunner.

Q: 3 What is software configuration management?

A: Software Configuration management (SCM) relates to Configuration Management (CM).

SCM is the control, and the recording of, changes that are made to the software and documentation throughout the software development life cycle (SDLC).

SCM covers the tools and processes used to control, coordinate and track code, requirements, documentation, problems, change requests, designs, tools, compilers, libraries, patches, and changes made to them, and to keep track of who makes the changes.

We, test engineers have experience with a full range of CM tools and concepts, and can easily adapt to an organization's software tool and process needs.


Q: 4 What are some of the software configuration management tools?

A: Software configuration management tools include Rational ClearCase, DOORS, PVCS, CVS; and there are many others. Rational ClearCase is a popular software tool, made by Rational Software, for revision control of source code.

DOORS, or "Dynamic Object Oriented Requirements System", is a requirements version control software tool.

CVS, or "Concurrent Version System", is a popular, open source version control system to keep track of changes in documents associated with software projects. CVS enables several, often distant, developers to work together on the same source code.

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: 5 Which of these roles are the best and most popular?

A: In testing, Tester roles tend to be the most popular. The less popular roles include the roles of System Administrator, Test/QA Team Lead, and Test/QA Managers.


Q: 6 What other roles are in testing?

A: Depending on the organization, the following roles are more or less standard on most testing projects: Testers, Test Engineers, Test/QA Team Leads, Test/QA Managers, System Administrators, Database Administrators, Technical Analysts, Test Build Managers, and Test Configuration Managers.

Depending on the project, one person can and often wear more than one hat. For instance, we Test Engineers often wear the hat of Technical Analyst, Test Build Manager and Test Configuration Manager as well.


Q: 7 What's the difference between priority and severity?

A: The simple answer is, "Priority is about scheduling, and severity is about standards."

The complex answer is, "Priority means something is afforded or deserves prior attention; a precedence established by order of importance (or urgency). Severity is the state or quality of being severe; severe implies adherence to rigorous standards or high principles and often suggests harshness; severe is marked by or requires strict adherence to rigorous standards or high principles, e.g. a severe code of behavior."

Q: 8 What's the difference between efficient and effective?

A: "Efficient" means having a high ratio of output to input; working or producing with a minimum of waste. For example, "An efficient test engineer wastes no time", or "An efficient engine saves gas".

"Effective", on the other hand, means producing, or capable of producing, an intended result, or having a striking effect. For example, "For automated testing, WinRunner is more effective than an oscilloscope", or "For rapid long-distance transportation, the jet engine is more effective than a witch's broomstick".


Q: 9 What is the difference between verification and validation?

A: Verification takes place before validation, and not vice versa. Verification evaluates documents, plans, code, requirements, and specifications. Validation, on the other hand, evaluates the product itself.

The inputs of verification are checklists, issues lists, walk-throughs and inspection meetings, reviews and meetings. The input of validation, on the other hand, is the actual testing of an actual product.

The output of verification is a nearly perfect set of documents, plans, specifications, and requirements document. The output of validation, on the other hand, is a nearly perfect, actual product.

Q: 10 What is documentation change management?

A: Documentation change management is part of configuration management (CM). CM covers the tools and processes used to control, coordinate and track code, requirements, documentation, problems, change requests, designs, tools, compilers, libraries, patches, changes made to them and who makes the changes.

Rob Davis has had experience with a full range of CM tools and concepts. Rob Davis can easily adapt to your software tool and process needs.


Q: 11 What is up time?

A: "Up time" is the time period when a system is operational and in service. Up time is the sum of busy time and idle time.

For example, if, out of 168 hours, a system has been busy for 50 hours, idle for 110 hours, and down for 8 hours, then the busy time is 50 hours, idle time is 110 hours, and up time is (110 + 50 =) 160 hours.


Q: 12 What is upwardly compatible software?

A: Upwardly compatible software is compatible with a later or more complex version of itself. For example, an upwardly compatible software is able to handle files created by a later version of itself.

Q: 13 What is upward compression?

A: In software design, upward compression means a form of demodularization, in which a subordinate module is copied into the body of a superior module.


Q: 14 What is usability?

A: Usability means ease of use; the ease with which a user can learn to operate, prepare inputs for, and interpret outputs of a software product.


Q: 15 What is user documentation?

A: User documentation is a document that describes the way a software product or system should be used to obtain the desired results.


Q: 16 What is a user manual?

A: User manual is a document that presents information necessary to employ software or a system to obtain the desired results.

Typically, what is described are system and component capabilities, limitations, options, permitted inputs, expected outputs, error messages, and special instructions.

Q: 17 What is the difference between user documentation and user manual?

A: When a distinction is made between those who operate and use a computer system for its intended purpose, a separate user documentation and user manual is created. Operators get user documentation, and users get user manuals.


Q: 18 What is user friendly software?

A: A computer program is user friendly, when it is designed with ease of use, as one of the primary objectives of its design.


Q: 19 What is a user friendly document?

A: A document is user friendly, when it is designed with ease of use, as one of the primary objectives of its design.


Q: 20 What is a user guide?

A: User guide is the same as the user manual. It is a document that presents information necessary to employ a system or component to obtain the desired results.

Typically, what is described are system and component capabilities, limitations, options, permitted inputs, expected outputs, error messages, and special instructions.

Q: 21 What is user interface?

A: User interface is the interface between a human user and a computer system. It enables the passage of information between a human user and hardware or software components of a computer system.


Q: 22 What is a utility?

A: Utility is a software tool designed to perform some frequently used support function. For example, a program to print files.


Q: 23 What is utilization?

A: Utilization is the ratio of time a system is busy, divided by the time it is available. Uilization is a useful measure in evaluating computer performance.


Q: 24 What is V&V?

A: V&V is an acronym for verification and validation.


Q: 25 What is variable trace?

A: Variable trace is a record of the names and values of variables accessed and changed during the execution of a computer program.

Q: 26 What is value trace?

A: Value trace is same as variable trace. It is a record of the names and values of variables accessed and changed during the execution of a computer program.


Q: 27 What is a variable?

A: Variables are data items whose values can change. One example is a variable we've named "capacitor_voltage_10000", where "capacitor_value_10000" can be any whole number between -10000 and +10000.

Keep in mind, there are local and global variables.


Q: 28 What is a variant?

A: Variants are versions of a program. Variants result from the application of software diversity.


Q: 29 What is verification and validation (V&V)?

A: Verification and validation (V&V) is a process that helps to determine if the software requirements are complete, correct; and if the software of each development phase fulfills the requirements and conditions imposed by the previos phase; and if the final software complies with the applicable software requirements.

Q: 30 What is a software version?

A: A software version is an initial release (or re-release) of a software associated with a complete compilation (or recompilation) of the software.


Q: 31 What is a document version?

A: A document version is an initial release (or a complete re-release) of a document, as opposed to a revision resulting from issuing change pages to a previous release.


Q: 32 What is VDD?

A: VDD is an acronym. It stands for "version description document".


Q: 33 What is a version description document (VDD)?

A: Version description document (VDD) is a document that accompanies and identifies a given version of a software product.

Typically the VDD includes a description, and identification of the software, identification of changes incorporated into this version, and installation and operating information unique to this version of the software.

Read more...

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.

Read more...