testings interview question and answers part-7

Q: What is the role of documentation in QA?
A: Documentation plays a critical role in QA. QA practices should be
documented, so that they are repeatable. Specifications, designs, business rules,
inspection reports, configurations, code changes, test plans, test cases, bug
reports, user manuals should all be documented. Ideally, there should be a
system for easily finding and obtaining of documents and determining what
document will have a particular piece of information. Use documentation change
management, if possible. Q: What about requirements? A: Requirement specifications are important and one of the most reliable
methods of insuring problems in a complex software project is to have poorly
documented requirement specifications. Requirements are the details describing
an application's externally perceived functionality and properties. Requirements
should be clear, complete, reasonably detailed, cohesive, attainable and
testable. A non-testable requirement would be, for example, "user-friendly",
which is too subjective. A testable requirement would be something such as, "the
product shall allow the user to enter their previously-assigned password to
access the application". Care should be taken to involve all of a project's
significant customers in the requirements process. Customers could be in-house
or external and could include end-users, customer acceptance test engineers,
testers, customer contract officers, customer management, future software
maintenance engineers, salespeople and anyone who could later derail the
project. If his/her expectations aren't met, they should be included as a customer,
if possible. In some organizations, requirements may end up in high-level project
plans, functional specification documents, design documents, or other
documents at various levels of detail. No matter what they are called, some type
of documentation with detailed requirements will be needed by test engineers in
order to properly plan and execute tests. Without such documentation there will
be no clear-cut way to determine if a software application is performing correctly. Q: What is a 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 none outside
the test group will be able to read it.


Q: What is a test case?
A: A test case is a document that describes an input, action, or event and its
expected result, in order to determine if a feature of an application is working
correctly. A test case should contain particulars such as a... · Test case identifier; · Test case name; · Objective; · Test conditions/setup; · Input data requirements/steps, and · Expected results. Please note, the process of developing test cases can help find problems in the
requirements or design of an application, since it requires you to completely think
through the operation of the application. For this reason, it is useful to prepare
test cases early in the development cycle, if possible.
Q: What should be done after a bug is found?
A: 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: What is configuration management?
A: Configuration management (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.