Software Testing All Questions and Answers PDF

Software Testing FAQ
What is quality assurance?

The set of support activities (including facilitation, training, measurement and
analysis) needed to provide adequate confidence that processes are established
and continuously improved in order to produce products that meet specifications
and fit for use.
What is the purpose of the testing?
Testing provides information whether or not a certain product meets the
requirements.
What is the difference between QA and testing?
Quality Assurance is that set of activities that are carried out to set standards and
to monitor and improve performance so that the care provided is as effective and
as safe as possible. Testing provides information whether or not a certain product
meets the requirements. It also provides information where the product fails to
meet the requirements.
What is software quality'? OR
Define software quality for me, as you understand it?
Quality software is reasonably bug-free, delivered on time and within budget,
meets requirements and/or expectations, and is maintainable. However, quality is
obviously a
subjective term. It will depend on who the 'customer' is and their overall influence
in the
scheme of things. Each type of 'customer' will have their own slant on 'quality' - the
accounting department might define quality in terms of profits while an end-user
might define quality as user-friendly and bug-free.
What's the role of documentation in QA?
Critical. (Note that documentation can be electronic, not necessarily paper.) QA
practices should be documented such that they are repeatable. Specifications,
designs, business rules, inspection reports, configurations, code changes, test
plans, test cases, bug reports, user manuals, etc. should all be documented. There
should ideally be a system for easily finding and obtaining documents and
determining what documentation will have a particular piece of information.
Change management for documentation should be used if possible.
Explain the software development lifecycle.
There are seven stages of the software development lifecycle
1.
Initiate the project The users identify their Business requirements.
2.
Define the project The software development team translates the business
requirements into system specifications and put together into System Specification
Document.
3.
Design the system The System Architecture Team designs the system and
write Functional Design Document. During design phase general solutions re
hypothesized
and data and process structures are organized.
4.
Build the system The System Specifications and design documents are
given to the development team code the modules by following the
Requirements and Design
document.
5.
Test the system - The test team develops the test plan following the
requirements. The software is build and installed on the test platform after
developers have completed development and Unit Testing. The testers test the
software by following the test plan.
6.
Deploy the system After the user-acceptance testing and certification of
the software, it is installed on the production platform. Demos and training are
given to the users.
7.
Support the system - After the software is in production, the maintenance
phase of the life begins. During this phase the development team works with
the development
document staff to modify and enhance the application and the test team works
with the test documentation staff to verify and validate the changes and
enhancement to the application software.
At what stage of the SDLC does testing begin in your opinion?
QA process starts from the second phase of the Software Development Life Cycle
i.e. Define the System. Actual Product testing will be done on Test the system
phase (Phase-5). During this phase test team will verify the actual results against
expected results.
Explain the pre testing phase, acceptance testing and testing phase.
Pre testing Phase:
1.
Review the requirements document for the testability: Tester will use the
requirement document to write the test cases.
2.
Establishing the hard freeze date: Hard freeze date is a date after which
system test team will not accept any more software and documentation changes
from development
team, unless they are fixes of severity 1 MRs. The date is scheduled so that
product test team will have time for final regression.
3.
Writing master test plan: It is written by the lead tester or test coordinator.
Master test
plan includes entire testing plan, testing resources and testing strategy.
4.
Setting up MR Tool: The MR tool must be set as soon as you know of the
different modules in the product, the developers and testers on the product,
the hardware
platform, and operating system testing will be done.
This information will be available upon the completion of the first draft of
the architecture document. Both testers and developers are trained how to use the
system.
5.
Setting up the test environment: The test environment is set on separate
machines,
database and network. This task is performed by the technical support team. First
time it takes some time, Afterwards the same environment can be used by the later
releases.
6.
Writing the test plan and test cases: Template and the tool is decided to
write the test plan, test cases and test procedures. Expected results are organized
in the test plan according to the feature categories specified in the requirement
document. For each
feature positive and negative test cases are written. Writing test plan requires
the complete understanding of the product and its interfaces with other systems.
After test
plan is completed, a walkthrough is conducted with the developers and design
team members to baseline the test plan document.
7.
Setting up the test automation tool: Planning of test strategy on how to
automate the testing. Which test cases will be executed for regression testing. Not
all the test cases will be executed during regression testing.
8.
Identify acceptance test cases: Select subsets that are expected on the first
day of system test. These tests must pass to accept the product in the system test.
Acceptance testing phase:
1.
When the product enters system test, check it has completed integration
test and must meet the integration test exit criteria.
2.
Check integration exit criteria and product test entrance criteria in the
master test plan or test strategy documents.
3.
Check the integration testing sign off criteria sheet.
4.
Coordinate release with product development.
5.
How the code will be migrated from development environment to the test
environment.
6.
Installation and acceptance testing.
Product testing phase:
1.
Running the test: Execution of test cases and verify if actual functionality of
application matches the expected results.
2.
Initial manual testing is recommended to isolate unexpected system
behavior. Once application is stable automated regression test could be generated.
3.
Issue MRs upon detection of the bugs.
What is the value of a testing group? How do you justify your work and budget?
All software products contain defects/bugs, despite the best efforts of their
development teams. It is important for an outside party (one who is not developer)
to test the product from a viewpoint that is more objective and representative of
the product user.
Testing group test the software from the requirements point of view or what is
required by the user. Testers job is to examine a program and see if it does not do
what it is supposed to do and also see what it does what it is not supposed to do.
What is master test plan? What it contains? Who is responsible for writing it? OR
What is a test plan? Who is responsible for writing it? What it contains. OR
What's a 'test plan'? What did you include in a test plan?
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 read it. The following are some of
the items that might be included in a test plan, depending on the particular
project:
Title
Identification of software including version/release numbers
Revision history of document including authors, dates, approvals
Table of Contents
Purpose of document, intended audience
Objective of testing effort
Software product overview
Relevant related document list, such as requirements, design documents,

other test plans, etc.
Relevant standards or legal requirements
Trace ability requirements
Relevant naming conventions and identifier conventions
Overall
software
project
organization
and
personnel/contactinfo/responsibilties
Test organization and personnel/contact-info/responsibilities
Assumptions and dependencies
Project risk analysis
Testing priorities and focus

Scope and limitations of testing
Test outline - a decomposition of the test approach by test type, feature,

functionality, process, system, module, etc. as applicable
Outline of data input equivalence classes, boundary value analysis, error

classes
Test environment - hardware, operating systems, other required

software, data configurations, interfaces to other systems
Test environment validity analysis - differences between the test and

production systems and their impact on test validity.
Test environment setup and configuration issues
Software migration processes
Software CM processes
Test data setup requirements
Database setup requirements
Outline of system-logging/error-logging/other capabilities, and tools

such as screen capture software, that will be used to help describe and report
bugs
Discussion of any specialized software or hardware tools that will be used by

testers to help track the cause or source of bugs
Test automation - justification and overview
Test tools to be used, including versions, patches, etc.
Test script/test code maintenance processes and version control
Problem tracking and resolution - tools and processes
Project test metrics to be used
Reporting requirements and testing deliverables
Software entrance and exit criteria
Initial sanity testing period and criteria
Test suspension and restart criteria
Personnel allocation
Personnel pre-training needs
Test site/location
Outside test organizations to be utilized and their purpose, responsibilties,

deliverables, contact persons, and coordination issues
Relevant proprietary, classified, security, and licensing issues.
Open issues
Appendix - glossary, acronyms, etc.

The team-lead or a Sr. QA Analyst is responsible to write this document.
Why is test plan a controlled document?

Because it controls the entire testing process. Testers have to follow this test plan
during the entire testing process.
What information you need to formulate test plan?

Need the Business requirement document to prepare the test plan.
What are the entrance and exit criteria in the system test?
Entrance and exit criteria of each testing phase is written in the master test plan.
Enterence Criteria:
Integration exit criteria have been successfully met.
All installation documents are completed.
All shippable software has been successfully built
Syate, test plan is baselined by completing the walkthrough of the test plan.
Test environment should be setup.
All severity 1 MRs of integration test phase should be closed. Exit Criteria:
All the test cases in the test plan should be executed.
All MRs/defects are either closed or deferred.
Regression testing cycle should be executed after closing the MRs.
All documents are reviewed, finilized and signed-off.
If there are no requirements, how will you write your test plan?
If there are no requirements we try to gather as much details as possible from:
Business Analysts
Developers (If accessible)
Previous Version documentation (if any)
Stake holders (If accessible)
Prototypes.
What is White box testing/unit testing?
Unit testing - The most 'micro' scale of testing; to test particular functions or code
modules. Typically done by the programmer and not by testers, as it requires
detailed knowledge of the internal program design and code. Not always easily
done unless the application has a well-designed architecture with tight code; may
require developing test driver modules or test harnesses.
Difference between Black and White box testing?
Black box testing: Functional testing based on requirements with no knowledge of
the internal program structure or data. Also known as closed-box testing.
White Box testing: Testing approaches that examine the program structure and
device test data from the program logic.
What are the roles of glass-box and black-box testing tools?
Glass-box testing also called as white-box testing refers to testing, with detailed
knowledge of the modules internals. Thus these tools concentrate more on
the algorithms, data
structures used in development of modules. These tools perform testing on
individual
modules more likely than the whole application. Black-Box testing tools refer to
testing the interface, functionality and performance testing of the system module
and the whole system.
What is Black box testing?
Black Box testing is also called system testing which is performed by the testers.
Here the features and requirements of the product as described in the requirement
document are tested.
What is Integration testing?
Integration testing - Testing of combined parts of an application to determine if
they function together correctly. The 'parts' can be code modules, individual
applications, client and server applications on a network, etc. This type of testing is
especially relevant to client/server and distributed systems.
What knowledge you require to do white box, integration and black box testing?
For white box testing you need to understand the internals of the module like data
structures and algorithms and have access to the source code and for black box
testing only understanding/functionality of the application.
What is Regression testing?
Regression testing: Re-testing after fixes or modifications of the software or its
environment. It can be difficult to determine how much re-testing is needed,
especially near the end of the development cycle. Automated testing tools can be
especially useful for this type of testing..
Why do we do regression testing?
In any application new functionalities can be added so the application has to be
tested to see whether the added functionalities have affected the existing
functionalities or not. Here instead of retesting all the existing functionalities
baseline scripts created for these can be rerun and tested.
How do we regression testing?
Various automation-testing tools can be used to perform regression testing like
WinRunner, Rational Robot and Silk Test.
What are positive scenarios?
Testing to see whether the application is doing what it is supposed to do.
What are negative scenarios?
Testing to see whether the application is not doing what it is not suppose to do.
What is the difference between regression automation tool and performance

automation tool?
Regression testing tools capture test and play them back at a later time. The
capture and playback feature is fundamental to regression testing.
Performance testing tool determine the load a server can handle. And must have
feature to stimulate many users from one machine, scheduling and synchronize
different users, able to measure the network load under different number of
simulated users.
What is the difference between exception and validation testing?
Validation testing aims to demonstrate that the software functions in a manner
that can be reasonably expected by the customer. Testing the software in
conformance to the Software Requirements Specifications.
Exception testing deals with handling the exceptions (unexpected events) while the
AUT is run. Basically this testing involves how to change the control flow of the
AUT when an
exception arises.
What is user acceptance testing?

What is manual testing and what is automated testing?
What is smoke testing?

What is soak testing?
What is stress testing, performance testing, Security testing, Recovery testing and
volume testing.
What is MR?
MR is a Modification Request also known as Defect Report, a request to
modify the program so that program does what it is supposed to do.
Why you write MR?
MR is written for reporting problems/errors or suggestions in the software.
What information does MR contain? OR
Describe me to the basic elements you put in a defect report?
OR
What is the procedure for bug reporting?
The bug needs to be communicated and assigned to developers that can fix it.
After the problem is resolved, fixes should be re-tested, and determinations made
regarding requirements for regression testing to check that fixes didn't create
problems elsewhere. If a problem-tracking system is in place, it should encapsulate
these processes. A variety of commercial problem-tracking/management software
tools are available.
The following are items to consider in the tracking process:
Complete information such that developers can understand the bug, get an
idea of its severity, and reproduce it if necessary.
Current bug status (e.g., 'Released for Retest', 'New', etc.)
The application name or identifier and version
The function, module, feature, object, screen, etc. where the bug occurred
Environment specifics, system, platform, relevant hardware specifics
Test case name/number/identifier
One-line bug description
Full bug description
Description of steps needed to reproduce the bug if not covered by a test

case or if the developer doesn't have easy access to the test case/test script/test
tool
Names and/or descriptions of file/data/messages/etc. used in test
File excerpts/error messages/log file excerpts/screen shots/test tool logs

that would be helpful in finding the cause of the problem
Severity estimate (a 5-level range such as 1-5 or 'critical'-to-'low' is

common)
Was the bug reproducible?
Tester name
Test date
Bug reporting date
Name of developer/group/organization the problem is assigned to
Description of problem cause
Description of fix
Code section/file/module/class/method that was fixed
Date of fix
Application version that contains the fix
Tester responsible for retest
Retest date
Retest results
Regression testing requirements
Tester responsible for regression tests
Regression testing results

Which MR tool you used to write MR?
What criteria you will follow to assign severity and due date to the MR?
If the functionality of an application had an inbuilt bug because of which the test
script fails, would you automate the test?
You find a bug and the developer says Its not possible what do u do? How do
you help developer to track the fault s in the software?
What are the different types of MRs?
What is the role of a bug tracking system?
What is a successful product?
What Process/Methodologies are you familiar with? What are CMM and CMMI?
What is the difference?
What you will do during the first day of job?
What was the test team hierarchy?
What are the different automation tools you know?
Automation tools provided by Mercury Interactive Quick Test Professionl,
WinRunner, LoadRunner; Rational Rational Robot; Segue- SilkTest.
What is ODBC?
Did you ever have problems working with developers? Describe your experience
with code analyzers?
How do you survive chaos?
Tell me about the worst boss youve ever had.

What do you like about Windows?
How will you describe testing activities?
What is good code?
How you will begin improve the QA process?
What is UML and how it is used for testing?
The Unified Modeling Language (UML) is the industry-standard language for
specifying, visualizing, constructing, and documenting the artifacts of software
systems. It simplifies the complex process of software design, making a "blueprint"
for construction. UML state charts provide a solid basis for test generation in a
form that can be easily manipulated. This technique includes coverage criteria that
enable highly effective tests to be developed. A tool has been developed that uses
UML state charts produced by Rational Software Corporation's Rational Rose tool
to generate test data.
When should testing be stopped?
When do you start developing your automation tests?
What are benefits of the test automation?

Describe some problems that you had with automation testing tools Can test
automation improver test effectiveness?
What are the main use of test automation? Does automation replace manual
testing?
How will you choose a tool for test automation? OR
How we decide which automation tool we are going to use for the regression
testing?
What could wrong with automation testing?
What type of scripting techniques for test automation do you know?
What are good principles for test scripts?
What type of document do you need for QA, QC and testing?
What are the properties of a good requirement?
Have you ever written test cases or did you just execute those written by others?
How do you determine what to test?
How do you decide when you have tested enough?

Real isi ng you w ont be abl e to t est eve ryt hi ng -how do you decide what to
test first? OR What if there isn't enough time for thorough testing?
Where do you get your expected results?
If automating-what is your process for determining what to automate and in what
order? OR
Can you automate all the test scripts? Explain ? OR How do you plan test
automation? OR
What criteria do you use when determining when to automate a test or leave it
manual?
1.
Test that need to be run for every build of the application
2.
Tests that use multiple data values for the same actions( data driven tests)
3.
Tests that require detailed information from application internals
4.
Stress/ load testing
If youre given a program that will average student grades, what kinds of inputs
would you use?
Name of student, Subject, Score
How do you go about testing a project?
1.
Analyze user requirement documents and other documents like software
specifications, design document etc.
2.
Write master test plan which describe the scope, objective, strategy,
risk/contingencies,
resources
3.
Write system test plan and detailed test cases
4.
Execute test cases manually and compare actual results against expected
results.
5.
Identify mismatches, report defect to the development team using defect
reporting tool.
6.
Track defect, perform regression test to verify that defect is fixed and did
not disturb other parts of the application.
7.
Once all the defects are closed and application is stabilized, automate the
test scripts for
regression and performance testing.
How do you go about testing a web application?
.
What is configuration management? Tools used?
What are Individual test case and Workflow test case? Why we do workflow
scenarios How did you use automating testing tools in your job?
What is data-driven automation?
Describe me the difference between validation and verification? Is coding required
in Regression testing tools?
What do you mean by set up the test environment and provide full platform
support?
What are the two ways to copy a file in windows? Were you able to meet
deadlines?
What is test Metrics? What is the use of Metrics?

If you have shortage of time, how would you prioritize you testing?
Use risk analysis to determine where testing should be focused. Since it's rarely
possible to test every possible aspect of an application, every possible combination
of events, every dependency, or everything that could go wrong, risk analysis is
appropriate to most software development projects. Considerations can include:
Which functionality is most important to the project's intended purpose?
Which functionality is most visible to the user?
Which functionality has the largest safety impact?
Which functionality has the largest financial impact on users?
Which aspects of the application are most important to the customer?
Which aspects of the application can be tested early in the development

cycle?
Which parts of the code are most complex, and thus most subject to errors?
Which parts of the application were developed in rush or panic mode?
Which aspects of similar/related previous projects caused problems?
Which aspects of similar/related previous projects had large maintenance

expenses?
Which parts of the requirements and design are unclear or poorly thought
out?
What do the developers think are the highest-risk aspects of the

application?
What kinds of problems would cause the worst publicity?
What kinds of problems would cause the most customer service

complaints?
What kinds of tests could easily cover multiple functionalities?
Which tests will have the best high-risk-coverage to time-required ratio?
What is the impact of environment on the actual results of performance testing?

What is a pre-condition data?
What are the different documents in QA? How do you rate yourself in software
testing
Is defect resolution a technical skill or interpersonal skill from QA view point? What
is End to End business logic testing?
What is the task bar and where does it reside?

How do you analyze your test results? what metrics do you try to provide?
OR
How do you view test results?
If you come onboard, give me a general idea of what your first overall tasks will be
as far as as starting a quality effort?
Try to learn about the application, Environment and Prototypes to have the
better understanding of application and existing testing efforts
How do you differentiate the roles of Quality Assurance Manager and Project
Manager?
What do you like about QA?
Who in the company is responsible for Quality?
Should we test every possible combination/scenario for a program? What is clientserver architecture?
Client-server architecture, a client is defined as a requester of services and a server
is
defined as the provider of services. Communication takes place in the form a
request message from the client to the server asking for some work to be done.
Then the server does
the work and sends back the reply.
How Intranet is different from client-server? What is three-tier and multi-tier

architecture?
What is Internet? What is Intranet? What is Extranet? What is ISO-9000?
What is QMO?
What is Object Oriented model?
\
What is Procedural model?
What is an Object? What is class?

What is encapsulation? Give one example. What is inheritance? Give example.
What is the difference about web-testing and client server testing?
Is a Fast database retrieval rate a testable requirement?
What development model should programmers and the test group use? What are
the key challenges of load testing?
Have you done explanatory or specification-driven testing?
What is the role of QA in development project?
How do you promote the concept of phase containment and defect prevention?
What is Walkthrough? What is inspection?

\
What is Software Review?
What if the application has functionality that wasn't in the requirements?
Build Verification Test (BVT)

1.
What is verification?
2.
What is validation?
3.
What is a walkthrough?
4.
What is quality?
5.
What is good code?
6.
What is good design?
7.
.
What is software life cycle?
8.
What is the role of documentation in QA?
9.
What about requirements?
10.
What is a test plan?
11.
What is a test case?
12.
What is software quality assurance?
A: Software Quality Assurance, is oriented to *prevention*. It involves the entire
software
development process. Prevention is monitoring and improving the process, making
sure any agreed-upon standards and procedures are followed and ensuring
problems are found and dealt with.
13.
.
14.
Standards and templates - what is supposed to be in a document?
15.
How do test case templates look like?
16.
Process and procedures - why follow them?
18.
How do you create a test strategy?
19.
What is the general testing process?
20.
What is a test schedule?
21.
What are the different levels of testing?
22.
What is black box testing?
23.
What is white box testing?
24.
What is unit testing?
25.
What is functional testing?
26.
What is integration testing?
27.
What is incremental integration testing?
28.
What is system testing?
29.
What is Gray Box testing?
30.
What is end-to-end testing?
31.
What is regression testing?
32.
What is sanity testing?
33.
What is performance testing?
34.
What is load testing?
35.
What is stress testing?
36.
What is recovery/error testing?
37.
What is compatibility testing?
38.
What is acceptance testing?
39.
What is alpha testing?
40.
What is beta testing?
41.
What is Traceability matrix?
42.
What is configuration management?
43.
What can be done if requirements are changing continuously?
44.
What if the application has functionality that wasn't in the requirements?
45.
Why do you recommend that we test during the design phase?
46.
What makes a good test engineer?
A: Has a "test to break" attitude,
Takes the point of view of the customer,
Has a strong desire for quality,
Has an attention to detail, He's also
Tactful and diplomatic and
Has good a communication skill, both oral and written. And he
Has previous software development experience, too.
47.
Why are there so many software bugs?
48.
Give me five common problems that occur during software development.
49.
What should be done after a bug is found?
50.
What if the software is so buggy it can't be tested at all?
51.
How do you know when to stop testing?
52.
What if the project isn't big enough to justify extensive testing?
Whats the role of a QA in a company that produces software?

QA is
responsible
for
managing, implementing,
maintaining
and
continuously improving the Processes the Company and enables internal projects
towards process maturity and facilitates process improvements and innovations in
the organization. Tester is responsible for
carrying the testing effort in the company.
Who writes business requirements? What you do when you have BRD?
Business Analyst writes the Business Requirements. Business requirements (BR)
are sent to the software architect (SA) for validation. SA after understanding the BR
makes use cases and
UML diagrams and forwards them to QA manager. QA manager based on scope,
BR, use case & UML diagram writes the overall testing strategy & high-level test
cases and forward them to
testers.
What is the difference between SRS and BRS?

BRS is a document, which contains the requirements of a customer during initial
phase. It is prepared by Business Analyst. It plays a vital role in all the phases of
SDLC. SRS is also a
document which is prepared on the basis of BRS. It is prepared by System
Analyst/Project manager. It mainly contains tentative plan, technological selection
etc.
What are the exit and entry criteria in a test plan?

Exit criteria define when u stops the testing. It defines interims the following: All
bug status cycle are closed, all functionalities are tested, and all high and medium
bugs are resolved. Entry criteria define entry of test execution. It defines interims
the following: Test environment established, Builder received from developer, Test
case prepared and reviewed.
Sample Testing Plan

A testing plan should include:
Software development lifecycle

There are seven stages of the software development lifecycle
8.
Initiate the project The users identify their Business requirements.
9.
Define the project The software development team translates the business
requirements into system specifications and put together into System Specification
Document.
10.
Design the system The System Architecture Team designs the system and
write Functional Design Document. During design phase general solutions re
hypothesized and data and process structures are organized.
11.
Build the system The System Specifications and design documents are
given to the development team code the modules by following the Requirements
and Design document.
12.
Test the system - The test team develops the test plan following the
requirements. The software is build and installed on the test platform after
developers have completed development and Unit Testing. The testers test the
software by following the test plan.
13.
Deploy the system After the user-acceptance testing and certification of
the software, it is installed on the production platform. Demos and training are
given to the users.
14.
Support the system - After the software is in production, the maintenance
phase of the life begins. During this phase the development team works with the
development document staff to modify and enhance the application and the test
team works with the test documentation staff to verify and validate the changes
and enhancement to the application software.
QA process starts from the second phase of the Software Development Life Cycle
i.e. Define the System. Actual Product testing will be done on Test the system
phase (Phase- 5). During this phase test team will verify the actual results against
expected results.
Test plan
A software project test plan is a document that describes the objectives, scope,
approach,
and focus of a software testing effort.
Outside test organizations to be utilized and their purpose,

responsibilities, deliverables, contact persons, and coordination issues
Need the Business requirement document to prepare the test plan. Test plan
controls the entire testing process. Testers have to follow this test plan during the
entire testing process. Entrance and exit criteria of each testing phase is written in
the master test plan.
Enterence Criteria:
Integration exit criteria have been successfully met.
plan.
-
All installation documents are completed.

All shippable software has been successfully built
System, test plan is base lined by completing the walkthrough of the test
Test environment should be setup.
All severity 1 MRs of integration test phase should be closed.

Exit Criteria:
All the test cases in the test plan should be executed.
All MRs/defects are either closed or deferred.
Regression testing cycle should be executed after closing the MRs.
All documents are reviewed, finilized and signed-off.
White box testing/unit testing Black box testing
Knowledge require to do white box and black box testing What is backend and
front end testing?
Testing Types:
2.
What is the difference between verifying and validating data?
3.
How can an object recognition problem be resolved?
4.
How do we calculate bug rate?
5.
How do you ensure comprehensive test coverage?
6.
When do you know testing is over?
7.
What is QA methodology and what environment would you use to do your
QA testing?
9.
What is Release acceptance testing?
10.
What is system integration testing?
11.
What is the compatibility testing difference between testing IE explorer and
testing in firefox? What is bug leakage?
What is requirement traceability?
Describe the basic elements you put in a defect report.
17. In a situation where actual result doesnt match with expected result, what
would you do?
19.
What is walkthrough and inspection?
20.
What is the difference between test scenario and test case?
21.
What is the difference between smoke testing and sanity testing?
22.
What are all the scenarios to be considered while testing reports?
23.
How do you know all the testing scenarios are covered?
24.
If test cases are executed with existing requirements and the requirements
are frequently changing, what steps should be taken for the test completion?
25.
What is a test strategy?
26.
What is a checklist?
28.
What type of testing does non- functional testing include?
29.
What is the difference between boundary value analysis and equivalence
portioning?
30. What are severity levels?
31. What is the diff between quality control and quality assurance?
What is Software Quality Assurance? What is Software Testing?

Common interview questions QA:
1.
FRD
What types of documents would you need for QA, QC, and Testing? BRD,
2.
What did you include in a test plan?
The detailed doc which gives scope and approach to the application
3.
Describe any bug you remember.
4.
What is the purpose of the testing? To have the applications bugs free
5.
What do you like (not like) in this job?
6.
What is QA (quality assurance)?
Testing of the applications for bugs or any defects and assuring the product is bug
free
7.
Read the answer for
this interview question for software testers
QA is assuring the application is bug free
Testing is executing the applications, documenting all the results & defects.
8.
How do you scope, organize, and execute a test project? Through Test Plan
9.
What is the role of QA in a development project?
Write the test cases, execute the test cases, report the defects. Perform regression
testing if there are any defects or new addition to the application
10.
What is the role of QA in a company that produces software? To check if the
application is bug free from end to end.
11.
Define quality for me as you understand it
Quality by itself says it all. For me quality means the application should not have
any errors on the user end.
12.
Describe to me the difference between validation and verification.
Validation is boundary testing (tel No., zip code)
Verification is verifying the insertion of data
13.
Describe to me what you see as a process. Not a particular process, just the
basics of having a process.
14.
Describe to me when you would consider employing a failure mode and
effect analysis.
15.
Describe to me the Software Development Life Cycle as you would define it.
Initiate, Define, Design, Build, Test, Deploy & Support
16.
The req should be specified clearly with all the details of the application
17.
How do you differentiate the roles of Quality Assurance Manager and
Project Manager? QA Manager is the one who will manage all the QA Testers.
Project Manager will be managing all the developers and the whole project.
18.
Tell me about any quality efforts you have overseen or implemented.
Describe some of the challenges you faced and how you overcame them.
19.
How do you deal with environments that are hostile to quality change
efforts?
20.
In general, how do you see automation fitting into the overall process of
testing?
If the application is too big it should be tested by automation. Also if the
application is going to be in regression testing it should be automated
21.
How do you promote the concept of phase containment and defect
prevention?
22.
If you come onboard, give me a general idea of what your first overall tasks
will be as far as starting a quality effort.
Understanding the project thoroughly by reading the BRD, Creating test plans &
documents for that project & attending the meetings to improve my knowledge of
this new project
23.
What kinds of testing have you done?
The different kinds of testing which I was involved was manual testing, QTP
automation testing, winrunner & loadrunner
24.
Have you ever created a test plan?
Yes the test plans for all the projects I have worked were created by me.
25.
Have you ever written test cases or did you just execute those written by
others?
Most of the times I have written the test cases and executed them, but there were
times when I had to execute the existing test case due to addition of new modules
26.
What did your base your test cases?
27.
To ensure the application is clean we have to check all the existing defects & rerun
the test. Also check if the whole application is running without any errors
28.
How do you decide when you have 'tested enough?'
When the application is running smoothly from end to end without any errors.
29.
How do you test if you have minimal or no documentation about the
product?
To run the test we have to have the proper documents but if there are no
documents about the product we should have meetings with the developers and
the users, discuss the product.
30.
Describe me to the basic elements you put in a defect report? Priority,
assigned to,
Character Traits
1.
A.
B.
C.
Do you consider yourself to be a smart person?

Yes.
Depending on the way I handled with different situations
Interacting with other people.
D.
E.
Solving Business problems

Making decisions
2.
How important is job security to you?
A. Security is the basic need. The only true job security comes from making a
meaningful
contribution to my employer. I am confident that I will be able to continue getting
the work done always exceeding expectations.
3.
Do you get bored doing the same work over and over again?
A. Not really, if the work involves my job. I dont get bored because it is my
responsibility to complete it.
4.
Do you prefer working as a member of a team or alone?
A. Working as a part of a team is one of the most important elements in a
successful
career. It really depends on the best way to complete it. I would work equally hard
with the initiative required for success.
5.
A.
B.
C.
D.
E.
What are the reasons for your success?

When I do a job well, it gives me personal satisfaction.
Paying attention to details
I usually Recheck the things for missed ones
Hard work
Respect for others
6.
Are you absent from work often?
A. No. My attendance record is very good (unless I have a serious health problem)
7.
Hoe do you show your interest in your co-workers?
A.
By keeping my eyes and ears open. I try to remember the things that are
important to
the people around me. If I am a supervisor, I usually call a quick closed-door
conference to see if there is something that can be done before a problem occurs.
8.
If you could be anyone, who would you like to be?
A.
Generally I am pretty happy with who I am.
B.
If it could be anyone I wanted, it would be a person who used his/her
business skills to make the world a better place.
C.
The best way to succeed is by helping others to succeed.
9.
How did you react to criticism superiors?
A. I always learned to receive criticism as a feedback to my actions.
10.
What would you do if it were your last day on earth?
A.
I would gather the people who are important to me and let them know how
much they
have contributed to my happiness.
11.
Do you have a competitive nature?
A.
Yes. It is necessary to be successful in a corporate environment. If I do my
work well
the rewards will come and that is the way to succeed.
12.
What is your idea of success?
13.
14.
How would you feel about working with a female executive?

What types of people try your patience?
15.
How well do you cope with your tension?
16.
Do you speak up if your point of view differs from that of your superiors?
17.Are you an innovative person?
A.
.
18.
How often do you lose your temper?
19.
How have you benefited from your disappointments? 20.Do you get along
with your co-workers?
21.What can you tell me about yourself? 22.What do you think you do best?
23.What have you learned from mistakes?
31.
How do you perform regression testing?
32.
At what stage of the life cycle does testing begin in your opinion?
33.
How do you analyze your test results? What metrics do you try to provide?
34.
Realising you won't be able to test everything - how do you decide what to
test first?
35.
here do you get your expected results?
36.
If automating - what is your process for determining what to automate and
in what order?
37.
In the past, I have been asked to verbally start mapping out a test plan for a
common situation, such as an ATM. The interviewer might say, "Just thinking out
loud, if you were tasked to test an ATM, what items might you test plan include?"
These type questions are not meant to be answered conclusively, but it is a good
way for the interviewer to see how you approach the task.
38.
If you're given a program that will average student grades, what kinds of
inputs would you use?
39.
Tell me about the best bug you ever found.
40.
What made you pick testing over another career?
41.
What is the exact difference between Integration & System testing, give me
examples with your project.
42.
How did you go about testing a project?
43.
When should testing start in a project? Why?
44.
45.
Difference between Black & White box testing
46.
What is Configuration management? Tools used?
47.
What do you plan to become after say 2-5yrs (Ex: QA Manager, Why?)
48.
Would you like to work in a team or alone, why?
49.
Give me 5 strong & weak points of yours
50.
Why do you want to join our company?
51.
52.
What sort of things would you put down in a bug report?
53.
54.
Who defines quality?
55.
What is an equivalence class?
56.
Is a "A fast database retrieval rate" a testable requirement?
57.
Should we test every possible combination/scenario for a program?
58.
What criteria do you use when determining when to automate a test or
leave it manual?
59.
60.
Discuss what test metrics you feel are important to publish an organization?
61.
In case anybody cares, here are the questions that I will be asking:
62.
Describe the role that QA plays in the software lifecycle.
63.
What should Development require of QA?
64.
What should QA require of Development?
65.
How would you define a "bug?"
66.
Give me an example of the best and worst experiences you've had with QA.
67.
How does unit testing play a role in the development / software lifecycle?
68.
Explain some techniques for developing software components with respect
to testability.
69.
Describe a past experience with implementing a test harness in the
development of software.
70.
Have you ever worked with QA in developing test tools? Explain the
participation Development should have with QA in leveraging such test tools for
QA use.
71.
Give me some examples of how you have participated in Integration
Testing.
72. How would you describe the involvement you have had with the bug-fix cycle
between Development and QA?
72.
73.
Describe your personal software development process.
74.
How do you know when your code has met specifications?
75.
How do you know your code has met specifications when there are no
specifications? 76. Describe your experiences with code analyzers.
77.
How do you feel about cyclomatic complexity?
78.
Who should test your code? 79. How do you survive chaos?
80.
What processes/methodologies are you familiar with?
81.
What type of documents would you need for QA/QC/Testing? 82. How can
you use technology to solve problem?
83.
What type of metrics would you use?
84.
How to find that tools work well with your existing system? 85. What
automated tools are you familiar with?
86.
How well you work with a team?
87.
How would you ensure 100% coverage of testing? 88. How would you build
a test team?
89.
What problem you have right now or in the past? How you solved it?
90.
What you will do during the first day of job? 91. What would you like to do
five years from now? 92. Tell me about the worst boss you've ever had.
93. What are your greatest weaknesses? 94. What are your strengths?
95.
96.
What do you like about Windows? 97. What is good code?
99.
What are basic, core, practises for a QA specialist?
100. What do you like about QA?
101. What has not worked well in your previous QA experience and what would
you change?
102. How you will begin to improve the QA process? 103. What is the difference
between QA and QC? 104. What is UML and how to use it for testing?
105. What is CMM and CMMI? What is the difference?
106. What do you like about computers?
107. Do you have a favourite QA book? More than one? Which ones? And why.
108. What is the responsibility of programmers vs QA? 109.What are the
properties of a good requirement?
110. Ho to do test if we have minimal or no documentation about the product?
111. What are all the basic elements in a defect report?
112. Is an "A fast database retrieval rate" a testable requirement? 113.Why
should you care about objects and object-oriented testing?
114. What does 100% statement coverage mean?
115. How do you perform configuration management with typical revision
control systems?
116. What is code coverage?
117. What types of code coverage do you know?
118. What tools can be used for code coverage analysis?
119. Is any graph is used for code coverage analysis?
120. At what stage of the development cycle software errors are least costly to
correct?
121. What can you tell about the project if during testing you found 80 bugs in
it?
122. How to monitor test progress?
123. Describe a few reasons that a bug might not be fixed.
124. What are the possible states of software bugs life cycle?
125. What books about QA (software testing) did you read?
126. What type of testing based specifically on a program code?
127. What type of testing based on any document that describes the "structure
of the software"?
128. Please describe test design techniques like: state-transition diagrams,
decision tables, activity diagrams.
129. Describe business process testing and what test design technique would
you use for it?
Test Automation job interview questions:

1.
What automating testing tools are you familiar with?
2.
How did you use automating testing tools in your job?
3.
Describe some problem that you had with automating testing tool.
4.
How do you plan test automation?
5.
Can test automation improve test effectiveness?
6.
What is data - driven automation?
7.
What are the main attributes of test automation?
8.
Does automation replace manual testing?
9.
How will you choose a tool for test automation?
10.
How you will evaluate the tool for test automation?
11.
What are main benefits of test automation?
12.
What could go wrong with test automation?
13.
How you will describe testing activities?
14.
What testing activities you may want to automate?
15.
Describe common problems of test automation.
16.
What types of scripting techniques for test automation do you know?
17.
What are principles of good testing scripts for automation?
18.
What tools are available for support of testing during software development
life cycle?
19.
Can the activities of test case design be automated?
20.
What are the limitations of automating software testing?
21.
What skills needed to be a good test automator?
22.
How to find that tools work well with your existing system?
23.
24.
25.
What testing activities you may want to automate in a project?
26.
27.
What are some of the common misconceptions during implementation of
an automated testing tools for the first time?
Testing Interview Questions
Why did you ever become involved in QA/testing?

What is the testing lifecycle and explain each of its phases? What is the difference
between testing and Quality Assurance? What is Negative testing?
What was a problem you had in your previous assignment (testing if possible)?
How did you resolve it?
What are two of your strengths that you will bring to our QA/testing team? How
would you define Quality Assurance?
What do you like most about Quality Assurance/Testing? What do you like least
about Quality Assurance/Testing?
What is the Waterfall Development Method and do you agree with all the steps?
What is the V-Model Development Method and do you agree with this model?
What is the Capability Maturity Model (CMM)? At what CMM level were the last
few companies you worked?
What is a "Good Tester"?
Could you tell me two things you did in your previous assignment (QA/Testing
related hopefully) that you are proud of?
List 5 words that best describe your strengths. What are two of your weaknesses?
What methodologies have you used to develop test cases?
In an application currently in production, one module of code is being modified. Is
it necessary to retest the whole application or is it enough to just test
functionality associated with that module?
Define each of the following and explain how each relates to the other: Unit,
System, and Integration testing.
Define Verification and Validation. Explain the differences between the two. Explain
the differences between White-box, Gray-box, and Black-box testing. How do you
go about going into a new organization? How do you assimilate?
Define the following and explain their usefulness: Change Management,

Configuration Management, Version Control, and Defect Tracking.
What is ISO 9000? Have you ever been in an ISO shop? When are you done
testing?
What is the difference between a test strategy and a test plan? What is ISO 9003?
Why is it important
What are ISO standards? Why are they important?
What is IEEE 829? (This standard is important for Software Test DocumentationWhy?)
What is IEEE? Why is it important?
Do you support automated testing? Why?
We have a testing assignment that is time-driven. Do you think automated tests
are the best solution?
What is your experience with change control? Our development team has only 10
members. Do you think managing change is such a big deal for us?
Are reusable test cases a big plus of automated testing and explain why.
Can you build a good audit trail using CPWR's QACenter products. Explain why.
How important is Change Management in today's computing environments?
Do you think tools are required for managing change. Explain and please list some
tools/practices which can help you managing change.
We believe in ad-hoc software processes for projects. Do you agree with this?
Please explain your answer.
When is a good time for system testing?
Are regression tests required or do you feel there is a better use for resources?
Our software designers use UML for modeling applications. Based on their use
cases, we would like to plan a test strategy. Do you agree with this approach or
would
this mean more effort for the testers.
Tell me about a difficult time you had at work and how you worked through it.
Give me an example of something you tried at work but did not work out so you
had to go at things another way.
How can one file compare future dated output files from a program which has
change, against the baseline run which used current date for input. The client does
not want to mask dates on the output files to allow compares. - Answer-Rerun
baseline and future date input files same # of days as future dated run of program
with change. Now run a file compare against the baseline future dated output and
the changed programs' future dated output.
Interviewing Suggestions
If you do not recognize a term ask for further definition. You may know the
methodology/term but you have used a different name for it.
Always keep in mind that the employer wants to know what you are going to do
for them, with that you should always stay/be positive.
Preinterview Questions
What is the structure of the company?
Who is going to do the interview-possible background information of interviewer?
What is the employer's environment (platforms, tools, etc.)?
What are the employer's methods and processes used in software arena? What is
the employer's philosophy?
What is the project all about you are interviewing for-as much information as
possible.
Any terminologies that the company may use.
Test Automation:
1.
What automating testing tools are you familiar with?
2.
How did you use automating testing tools in your job?
3.
4.
How do you plan test automation?
5.
Can test automation improve test effectiveness?
6.
What is data - driven automation?
7.
8.
Does automation replace manual testing?
9.
How will you choose a tool for test automation?
10.
How you will evaluate the tool for test automation?
11.
What are main benefits of test automation?
12.
What could go wrong with test automation?
13.
How you will describe testing activities?
14.
What testing activities you may want to automate?
15.
Describe common problems of test automation.
16.
What types of scripting techniques for test automation do you know?
17.
What are principles of good testing scripts for automation?
18.
What tools are available for support of testing during software development
life cycle?
19.
Can the activities of test case design be automated?
20.
What are the limitations of automating software testing?
21.
What skills needed to be a good test automator?
22.
How to find that tools work well with your existing system? 23.Describe
some problem that you had with automating testing tool. 24.What are the main
attributes of test automation?
25.What testing activities you may want to automate in a project? 26.How to find
that tools work well with your existing system?
Load Testing:
1.
What criteria would you use to select Web transactions for load testing?
2.
For what purpose are virtual users created?
3.
Why it is recommended to add verification checks to your all your
scenarios?
4.
In what situation would you want to parameterize a
text verification check?
5.
Why do you need to parameterize fields in your virtual user script?
6.
What are the reasons why parameterization is necessary when load testing
the Web server and the database server?
7.
How can data caching have a negative effect on load testing results?
8.
What usually indicates that your virtual user script has dynamic data that is
dependent on you parameterized fields?
9.
What are the benefits of creating multiple actions within any virtual user
script?
General questions:
1.
2.
What types of documents would you need for QA, QC, and Testing?
What did you include in a test plan?
3.
Describe any bug you remember.
4.
What is the purpose of the testing?
5.
What do you like (not like) in this job?
6.
7.
8.
How do you scope, organize, and execute a test project?
9.
What is the role of QA in a development project?
10.
What is the role of QA in a company that produces software?
11.
Define quality for me as you understand it
12.
Describe to me the difference between validation and verification.
13.
Describe to me what you see as a process. Not a particular process, just the
basics of having a process.
14.
Describe to me when you would consider employing a failure mode and
effect analysis.
15.
Describe to me the Software Development Life Cycle as you would define it.
16.
17.
How do you differentiate the roles of Quality Assurance Manager and
Project Manager?
18.
Tell me about any quality efforts you have overseen or implemented.
Describe some of the challenges you faced and how you overcame them.
19.
How do you deal with environments that are hostile to quality change
efforts?
20.
In general, how do you see automation fitting into the overall process of
testing?
21.
How do you promote the concept of phase containment and defect
prevention?
22.
If you come onboard, give me a general idea of what your first overall tasks
will be as far as starting a quality effort.
23.
What kinds of testing have you done?
24.
Have you ever created a test plan?
25.
Have you ever written test cases or did you just execute those written by
others?
26.
What did your base your test cases?
27.
28.
How do you decide when you have 'tested enough?'
29.
How do you test if you have minimal or no documentation about the
product?
30.
Describe me to the basic elements you put in a defect report?
31.
How do you perform regression testing?
32.
At what stage of the life cycle does testing begin in your opinion?
33.
How do you analyze your test results? What metrics do you try to provide?
34.
Realising you won't be able to test everything - how do you decide what to
test first?
35.
Where do you get your expected results?
36.
If automating - what is your process for determining what to automate and
in what order?
37.
In the past, I have been asked to verbally start mapping out a test plan for a
common situation, such as an ATM. The interviewer might say, "Just thinking out
loud, if you were tasked to test an ATM, what items might you test plan include?"
These type questions are not meant to be answered conclusively, but it is a good
way for the interviewer to see how you approach the task.
38.
If you're given a program that will average student grades, what kinds of
inputs would you use?
39.
Tell me about the best bug you ever found.
40.
What made you pick testing over another career?
41.
What is the exact difference between Integration & System testing, give me
examples with your project.
42.
How did you go about testing a project?
43.
When should testing start in a project? Why?
44.
45.
Difference between Black & White box testing
46.
What is Configuration management? Tools used?
47.
What do you plan to become after say 2-5yrs (Ex: QA Manager, Why?)
48.
Would you like to work in a team or alone, why?
49.
Give me 5 strong & weak points of yours
50.
Why do you want to join our company?
51.
52.
What sort of things would you put down in a bug report?
53.
54.
Who defines quality?
55.
What is an equivalence class?
56.
Is a "A fast database retrieval rate" a testable requirement?
57.
Should we test every possible combination/scenario for a program?
58.
What criteria do you use when determining when to automate a test or
leave it manual?
59.
60.
Discuss what test metrics you feel are important to publish an organization?
61.
In case anybody cares, here are the questions that I will be asking:
62.
Describe the role that QA plays in the software lifecycle.
63.
What should Development require of QA?
64.
What should QA require of Development?
65.
How would you define a "bug?"
66.
Give me an example of the best and worst experiences you've had with QA.
67.
How does unit testing play a role in the development / software lifecycle?
68.
Explain some techniques for developing software components with respect
to testability.
69.
Describe a past experience with implementing a test harness in the
development of software.
70.
Have you ever worked with QA in developing test tools? Explain the
participation Development should have with QA in leveraging such test tools for
QA use.
71.
Give me some examples of how you have participated in Integration
Testing.
72.
How would you describe the involvement you have had with the bug-fix
cycle between Development and QA?
72.
73.
Describe your personal software development process.
74.
How do you know when your code has met specifications?
75.
How do you know your code has met specifications when there are no
specifications?
76.
Describe your experiences with code analyzers.
77.
How do you feel about cyclomatic complexity?
78.
Who should test your code? 79.How do you survive chaos?
80.
What processes/methodologies are you familiar with?
81.
What type of documents would you need for QA/QC/Testing?
82.
How can you use technology to solve problem?
83.
What type of metrics would you use?
84.
85.
What automated tools are you familiar with?
86.
How well you work with a team?
87.
How would you ensure 100% coverage of testing?
88.
How would you build a test team?
89.
What problem you have right now or in the past? How you solved it?
90.
What you will do during the first day of job?
91.
What would you like to do five years from now?
92.
Tell me about the worst boss you've ever had.
93.
What are your greatest weaknesses?
94.
What are your strengths?
95.
96.
What do you like about Windows?
97.
What is good code?
99.
What are basic, core, practises for a QA specialist?
100. What do you like about QA?

101. What has not worked well in your previous QA experience and what would
you change?
102. How you will begin to improve the QA process?
103. What is the difference between QA and QC?
104. What is UML and how to use it for testing?
105. What is CMM and CMMI? What is the difference?
106. What do you like about computers?
107. Do you have a favourite QA book? More than one? Which ones? And
why.
108. What is the responsibility of programmers vs QA? 109.What are the
properties of a good requirement?
110. Ho to do test if we have minimal or no documentation about the product?
111. What are all the basic elements in a defect report?
112. Is an "A fast database retrieval rate" a testable requirement?
1.
What is software quality assurance?
2.
What is the value of a testing group? How do you justify your work and
budget?
3.
What is the role of the test group vis-is documentation, tech support, and
so forth?
4.
How much interaction with users should testers have, and why?
5.
How should you learn about problems discovered in the field, and what
should you learn from those problems?
6.
What are the roles of glass-box and black-box testing tools?
7.
What issues come up in test automation, and how do you manage them?
8.
What development model should programmers and the test group use?
9.
How do you get programmers to build testability support into their code?
10.
What is the role of a bug tracking system?
11.
What are the key challenges of testing?
12.
Have you ever completely tested any part of a product? How?
13.
Have you done exploratory or specification-driven testing?
14.
Should every business test its software the same way?
15.
Discuss the economics of automation and the role of metrics in testing.
16.
Describe components of a typical test plan, such as tools for interactive
products and for database products, as well as cause-and-effect graphs and dataflow diagrams.
17.
When have you had to focus on data integrity?
18.
What are some of the typical bugs you encountered in your last
assignment?
19.
How do you prioritize testing tasks within a project?
20.
How do you develop a test plan and schedule? Describe bottom-up and
top-down approaches.
21.
When should you begin test planning?
22.
When should you begin testing?
23.
Do you know of metrics that help you estimate the size of the testing effort?
24.
How do you scope out the size of the testing effort?
25.
How many hours a week should a tester work?
26.
How should your staff be managed? How about your overtime?
27.
How do you estimate staff requirements?
28.
What do you do (with the project tasks) when the schedule fails?
29.
How do you handle conflict with programmers?
30.
How do you know when the product is tested well enough?
31.
What characteristics would you seek in a candidate for test-group manager?
32.
What do you think the role of test-group manager should be? Relative to
senior management?
Relative to other technical groups in the company? Relative to your staff?
33.
How do your characteristics compare to the profile of the ideal manager
that you just described?
34.
How does your preferred work style work with the ideal test-manager role
that you just described? What is different between the way you work and the role
you described?
35.
Who should you hire in a testing group and why?
36.
What is the role of metrics in comparing staff performance in human
resources management?
37.
How do you estimate staff requirements?
38.
What do you do (with the project staff) when the schedule fails?
39.
Describe some staff conflicts youve handled.
Here are some questions you might be asked on a job interview for a testing
opening: (from MU COSC 198 Software Testing by Dr. Corliss)
Why did you ever become involved in QA/testing?
What is the testing lifecycle and explain each of its phases? What is the difference
between testing and Quality Assurance? What is Negative testing?
What was a problem you had in your previous assignment (testing if possible)?
How did you resolve it?
What are two of your strengths that you will bring to our QA/testing team?
How would you define Quality Assurance?
What do you like most about Quality Assurance/Testing? What do you like least
about Quality Assurance/Testing?
What is the Waterfall Development Method and do you agree with all the steps?
What is the V-Model Development Method and do you agree with this model?
What is the Capability Maturity Model (CMM)? At what CMM level were the last
few companies you worked?
What is a "Good Tester"?
Could you tell me two things you did in your previous assignment (QA/Testing
related hopefully) that you are proud of?
List 5 words that best describe your strengths. What are two of your weaknesses?
What methodologies have you used to develop test cases?
In an application currently in production, one module of code is being modified. Is
it necessary to retest the whole application or is it enough to just test
functionality associated with that module?
Define each of the following and explain how each relates to the other: Unit,
System, and Integration testing.
Define Verification and Validation. Explain the differences between the two.
Explain the differences between White-box, Gray-box, and Black-box testing.
How do you go about going into a new organization? How do you assimilate?
Define the following and explain their usefulness: Change Management,
Configuration Management, Version Control, and Defect Tracking.
What is ISO 9000? Have you ever been in an ISO shop? When are you done
testing?
What is the difference between a test strategy and a test plan? What is ISO 9003?
Why is it important
What are ISO standards? Why are they important?
What is IEEE 829? (This standard is important for Software Test DocumentationWhy?)
What is IEEE? Why is it important?
Do you support automated testing? Why?
We have a testing assignment that is time-driven. Do you think automated tests
are the best solution?

What is your experience with change control? Our development team has only 10
members. Do you think managing change is such a big deal for us?
Are reusable test cases a big plus of automated testing and explain why.
Can you build a good audit trail using Compuware's QACenter products.
Explain why.
How important is Change Management in today's computing environments?
Do you think tools are required for managing change. Explain and please list some
tools/practices which can help you managing
change.
We believe in ad-hoc software processes for projects. Do you agree with this?
Please explain your answer.
When is a good time for system testing?
Are regression tests required or do you feel there is a better use for resources?
Our software designers use UML for modeling applications. Based on their use
cases, we would like to plan a test strategy. Do you agree with this approach or
would this mean more effort for the testers.
Tell me about a difficult time you had at work and how you worked through it.
Give me an example of something you tried at work but did not work out so you
had to go at things another way.
How can one file compare future dated output files from a program which has
change, against the baseline run which used current date for input. The client does
not want to mask dates on the output files to allow compares. - Answer-Rerun
baseline and future date input files same # of days as future dated run of program
with change. Now run a file compare against the baseline future dated output and
the changed programs' future dated output.
Interviewing Suggestions
If you do not recognize a term ask for further definition. You may know the
methodology/term but you have used a different name for it.
Always keep in mind that the employer wants to know what you are going to do
for them, with that you should always stay/be positive.
Preinterview Questions
What is the structure of the company?

Who is going to do the interview-possible background information of interviewer?
What is the employer's environment (platforms, tools, etc.)?
What are the employer's methods and processes used in software arena?
What is the employer's philosophy?
What is the project all about you are interviewing for-as much information as
possible.
Any terminologies that the company may use.
Software Quality Assurance

(1) A planned and systematic pattern of all actions necessary to provide adequate confidence
that an item or product conforms to established technical requirements.
(2) A set of activities designed to evaluate the process by which products are developed or
manufactured.
What's difference between client/server and Web Application ?

Client/server based is any application architecture where one server application and one or
many client applications are involved like your mail server and MS outlook Express, it can be a
web application as well, where the Web Application is a kind of client server application that is
hosted on the web server and accessed over the internet or interanet. There are lots of things
that differs between testing of the two type above and cann't be posted in one post but you can
look into the data flow, communication and servside variable like session and security etc
Software Quality Assurance Activities
Application of Technical Methods (Employing proper methods and tools for developing
software)
Conduct of Formal Technical Review (FTR)
Testing of Software
Enforcement of Standards (Customer imposed standards or management imposed

standards)
Control of Change (Assess the need for change, document the change)
Measurement (Software Metrics to measure the quality, quantifiable)
Records Keeping and Recording (Documentation, reviewed, change control etc. i.e.
benefits of docs).
What's the difference between STATIC TESTING and DYNAMIC TESTING?
Answer1:
Dynamic testing: Required program to be executed
static testing: Does not involve program execution
The program is run on some test cases & results of the programs performance are
examined to check whether the program operated as expected
E.g. Compiler task such as Syntax & type checking, symbolic execution, program
proving, data flow analysis, control flow analysis
Answer2:
Static Testing: Verification performed with out executing the system code
Dynamic Testing: Verification and validation performed by executing the system code
What is software testing

What black box testing types can you tell me about?
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 blackbox 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.
What is software testing methodology?
One software testing methodology is the use a three step process of...
1. Creating a test strategy;
2. Creating a test plan/design; and
3. 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 clients' applications.
Whats the difference between QA and testing?
TESTING means Quality Control; and
QUALITY CONTROL measures the quality of a product; while
QUALITY ASSURANCE measures the quality of processes used to create a quality product.
Why Testing CANNOT Ensure Quality
Testing in itself cannot ensure the quality of software. All testing can do is give you a certain
level of assurance (confidence) in the software. On its own, the only thing that testing proves is
that under specific controlled conditions, the software functioned as expected by the test cases
executed.
s regression testing performed manually?
The answer to this question depends on the initial testing approach. If the initial testing
approach was manual testing, then the regression testing is usually performed manually.
Conversely, if the initial testing approach was automated testing, then the regression testing is
usually performed by automated testing.
How to choose which defect to remove in 1000000 defects? (because It will take too
much resources in order to remove them all.)
Answe2:
As a tester we don't fix the defects but we surely can prioritize them once detected. In our
org we assign severity level to the defects depending upon their influence on other parts of
products. If a defect doesnt allow you to go ahead and test test the product, it is critical one
so it has to be fixed ASAP. We have 5 levels as
1-critical
2-High
3-Medium
4-Low
5-Cosmetic
Dev can group all the critical ones and take them to fix before any other defect.
Answer3:
Priority/Severity P1 P2 P3
S1
S2
S3
Generally the defects are classified in aboveshown grid. Every organization / software has
some target of fixing the bugs.
Example P1S1 -> 90% of the bugs reported should be fixed.
P3S3 -> 5% of the bugs reported may be fixed. Rest are taken in letter service packs or
versions.
Thus the organization should decide its target and act accordingly.
Basically bugfree software is not possible.
Answer4:
Ideally, the customer should assign priorities to their requirements. They tend to resist this.
On a large, multi-year project I just completed, I would often (in the lack of customer
guidelines) rely on my knowledge of the application and the potential downstream impacts
in the modeled business process to prioritize defects.
If the customer doesn't then I fell the test organization should based on risk or other, similar
considerations.
What is Software Quality?
Quality software is reasonably bug-free, delivered on time and within budget, meets
requirements and/or expectations, and is maintainable.
However, quality is a subjective term. It will depend on who the customer is and their overall
influence in the scheme of things. A wide-angle view of the customers of a software

development project might include end-users, customer acceptance testers, customer contract
officers, customer management, the development organisations
management/accountants/testers/salespeople, future software maintenance engineers,
stockholders, magazine reviewers, etc. Each type of customer will have their own view on
quality - the accounting department might define quality in terms of profits while an end-user
might define quality as user-friendly and bug-free.
What are the five dimensions of the Risks?
Schedule: Unrealistic schedules, exclusion of certain activities when chalking out a schedule
etc. could be deterrents to project delivery on time. Unstable communication link can be
considered as a probable risk if testing is carried out from a remote location.
Client: Ambiguous requirements definition, clarifications on issues not being readily available,
frequent changes to the requirements etc. could cause chaos during project execution.
Human Resources: Non-availability of sufficient resources with the skill level expected in the
project are not available; Attrition of resources - Appropriate training schedules must be planned
for resources to balance the knowledge level to be at par with resources quitting.
Underestimating the training effort may have an impact in the project delivery.
System Resources: Non-availability of /delay in procuring all critical computer resources either
hardware and software tools or licenses for software will have an adverse impact.
Quality: Compound factors like lack of resources along with a tight delivery schedule and
frequent changes to requirements will have an impact on the quality of the product tested.
What is good code?
A good code is code that works, is free of bugs and is readable and maintainable. Organizations
usually have coding standards all developers should adhere to, but every programmer and
software engineer has different ideas about what is best and what are too many or too few
rules. We need to keep in mind that excessive use of rules can stifle both productivity and
creativity. Peer reviews and code analysis tools can be used to check for problems and enforce
standards.
How do you perform integration testing?
To perform integration testing, first, all 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, or acceptable, based on client input.
Why back-end testing is required, if we are going to check the front-end ....?
Why we need to do unit testing, if all the features are being tested in System testing.
What extra things are tested in unit testing, which can not be tested in System testing.
Answer1:
Assume that you're thinking client-server or web. If you test the application on the front end only
you can see if the data was stored and retrievd correctly. You can't see if the servers are in an
error state or not. many server processes are monitored by another process. If they crash, they
are restarted. You can't see that without looking at it.
The data may not be stored correctly either but the front end may have cached data lying
around and it will use that instead. The least you should be doing is verifying the data as stored
in the database.
It is easier to test data being transferred on the boundaries and see the results of those
transactions when you can set the data in a driver.
Answer2:
Back-End testing : Basically the requirement of this testing depends on ur project. like Say if ur
project is .Ticket booking system,Front end u will provided with an Interface , where u can book
the ticket by giving the appropriate details ( Like Place to go, and Time when u wanna go etc..).
It will have a Data storage system (Database or XL sheet etc) which is a Back end for storing
details entered by the user.
After submitting the details ,U might have provided with a correct acknowledgement.But in back
end , the details might not updated correctly in Database becoz of wrong logic development.
Then that will cause a major problem.
and regarding Unit level testing and System testing Unit level testing is for testing the basic
checks whether the application is working fyn with the basic requirements.This will be done by
developers before delivering to the QA.In System testing , In addition to the unit checks ,u will
be performing all the checks ( all possible integrated checks which required) .Basically this will
be carried out by tester
Answer3:
Ever heard about divide and conquer tactic ? It is a same method applied in backend and
frontend testing.
A good back end test will help minimize the burden of frontend test.
Another point is you can test the backend while develope the frontend. A true pararelism could
be achived.
Backend testing has another problem which must addressed before front end could use it. The
problem is concurency. Building a scenario to test concurency is formidable task.
A complex thing is hard to test. To create such scenarios will make you unsure which test you
already done and which you haven't. What we need is an effective methods to test our
application. The simplest method i know is using divide and conquer.
Answer4:
A wide range of errors are hard to see if you don't see the code. For example, there are many
optimizations in programs that treat special cases. If you don't see the special case, you don't
test the optimization. Also, a substantial portion of most programs is error handling. Most
programmers anticipate more errors than most testers.
Programmers find and fix the vast majority of their own bugs. This is cheaper, because there is
no communication overhead, faster because there is no delay from tester-reporter to
programmer, and more effective because the programmer is likely to fix what she finds, and she
is likely to know the cause of the problems she sees. Also, the rapid feedback gives the
programmer information about the weaknesses in her programming that can help her write
better code.
Many tests -- most boundary tests -- are done at the system level primarily because we don't
trust that they were done at the unit level. They are wasteful and tedious at the system level. I'd
rather see them properly done and properly automated in a suite of programmer tests.
What is retesting?
Answer1:
Retesting is usually equated with regression testing (see above) but it is different in that is
follows a specific fix--such as a bug fix--and is very narrow in focus (as opposed to testing entire
application again in a regression test). A product should never be released after any change has
been applied to the code, with only retesting of the bug fix, and without a regression test.
Answer2:
1. Re-testing is the testing for a specific bug after it has been fixed.(one given by your
definition).
2. Re-testing can be one which is done for a bug which was raised by QA but could not be
found or confirmed by Development and has been rejected. So QA does a re-test to make sure
the bug still exists and again assigns it back to them.
when entire project is tested & client have some doubts about the quality of testing, Re-Testing
can be called. It can also be testing the same application again for better Quality.
Answer3:
Regression Testing is, the selective retesting of a system that has been modified to ensure that
any bugs have been fixed and that no other previously working functions have failed as a result
of the reparations and that newly added features have not created problems with previous
versions of the software. Also referred to as verification testing
It is important to determine whether in a given set of circumstances a particular series of tests
has been failed. The supplier may want to submit the software for re-testing. The contract
should deal with the parameters for retests, including (1) will test program which are doomed to
failure be allowed to finish early, or must they be completed in their entirety? (2) when can, or
must, the supplier submit his software for retesting?, and (3) how many times can the supplier
fail tests and submit software for retesting is this based on time spent, or the number of
attempts? A well drawn contract will grant the customer options in the event of failure of
acceptance tests, and these options may vary depending on how many attempts the supplier
has made to achieve acceptance.
So the conclusion is retesting is more or less regression testing. More appropriately retesting is
a part of regression testing.
Answer4:
Re-testing is simply executing the test plan another time. The client may request a re-test for
any reason - most likely is that the testers did not properly execute the scripts, poor
documentation of test results, or the client may not be comfortable with the results.
I've performed re-tests when the developer inserted unauthorized code changes, or did not
document changes.
Regression testing is the execution of test cases "not impacted" by the specific project. I am
currently working on testing of a system with poor system documentation (and no user
documentation) so our regression testing must be extensive.
Answer5:
* QA gets a bug fix, and has to verify that the bug is fixed. You might want to check a few things
that are a gut feel if you want to and get away by calling it retesting, but not the entire function
/ module / product. * Development Refuses a bug on the basis of it being Non Reproducible,
then retesting, preferably in the presence of the Developer, is needed.
How to establish QA Process in an organization?
1.CURRENT SITUATION
The first thing you should do is to put what you currently do in a piece of paper in some sort of a
flowchart diagram. This will allow you to analyze what is being currently done.
2.DEVELOPMENT PROCESS STAGE
Once you have the "big picture", you have to be aware of the current status of your
development project or projects. The processes you select will vary depending if you are in early
stages of developing a new application (i.e.: developing a version 1.0), or maintaining an
existing application (i.e.: working on release 6.7.1).
3. PRIORITIES
The next thing you need to do is identify the priorities of your project, for example: - Compliance
with industry standards - Validation of new functionality (new GUIs, etc) - Security - Capacity
Planning ( You should see "Effective Methods for Software Testing" for more info). Make a list of
the priorities, and then assign them values of (H)igh, (M)edium and (L)ow.
4. TESTING TYPES
Once you are aware of the priorities, focus on the High first, then Medium, and finally evaluate
whether the Low ones need immediate attention.
Based on this, you need to select those Testing Types that will provide coverage for your
priorities. Example of testing types:
- Functional Testing
- Integration Testing
- System Testing
- System-to-System Testing (for testing interfaces)
- Regression Testing
- Load Testing
- Performance Testing
- Stress Testing
Etc.
5. WRITE A TEST PLAN
Once you have determined your needs, the simplest way to document and implement your
process is to elaborate a "Test Plan" for every effort that you are engaged into (i.e.: for every
release).
For this you can use generic Test Plan templates available in the web that will help you
brainstorm and define the scope of your testing:
- Scope of Testing (defects, functionality, and what will be and will not be tested).
- Testing Types (Functional, Regression, etc).
- Responsible people
- Requirements traceability matrix (match test cases with requirements to ensure coverage)
- Defect tracking
- Test Cases
DURING AND POST-TESTING ACTIVITIES
Make sure you keep track of the completion of your testing activities, the defects found, and that
you comply with an exit criteria prior to moving to the next stage in testing (i.e. User Acceptance
Testing, then Production Release).
Make sure you have a mechanism for:
- Reporting
- Test tracking
What is the testing lifecycle?
There is no standard, but it consists of:
Test Planning (Test Strategy, Test Plan(s), Test Bed Creation)
Test Development (Test Procedures, Test Scenarios, Test Cases)
Test Execution
Result Analysis (compare Expected to Actual results)
Defect Tracking
Reporting
What is quality?
Quality software is software that is reasonably bug-free, delivered on time and within budget,
meets requirements and expectations and is maintainable. However, quality is a subjective
term. Quality depends on who the customer is and their overall influence in the scheme of
things. Customers of a software development project include end-users, customer acceptance
test engineers, testers, customer contract officers, customer management, the development
organization's management, test engineers, testers, salespeople, software engineers,
stockholders and accountants. Each type of customer will have his or her own slant on quality.
The accounting department might define quality in terms of profits, while an end-user might
define quality as user friendly and bug free
What is Benchmark?
How it is linked with SDLC (Software Development Life Cycle)?
or SDLC and Benchmark are two unrelated things.?
What are the compoments of Benchmark?
In Software Testing where Benchmark fits in?
A Benchmark is a standard to measure against. If you benchmark an application, all future
application changes will be tested and compared against the benchmarked application.
What is the general testing process?
The general testing process is the creation of a test strategy (which sometimes includes the
creation of test cases), creation of a test plan/design (which usually includes test cases and test
procedures) and the execution of tests. Test data are inputs that have been devised to test the
system
Test Cases are inputs and outputs specification plus a statement of the function under the test.
Test data can be generated automatically (simulated) or real (live).
The stages in the testing process are as follows:
1. Unit testing: (Code Oriented)
Individual components are tested to ensure that they operate correctly. Each component is
tested independently, without other system components.
2. Module testing:
A module is a collection of dependent components such as an object class, an abstract data
type or some looser collection of procedures and functions. A module encapsulates related
components so it can be tested without other system modules.
3. Sub-system testing: (Integration Testing) (Design Oriented)
This phase involves testing collections of modules, which have been integrated into subsystems. Sub-systems may be independently designed and implemented. The most common
problems, which arise in large software systems, are sub-systems interface mismatches. The
sub-system test process should therefore concentrate on the detection of interface errors by
rigorously exercising these interfaces.

4. System testing:
The sub-systems are integrated to make up the entire system. The testing process is concerned
with finding errors that result from unanticipated interactions between sub-systems and system
components. It is also concerned with validating that the system meets its functional and nonfunctional requirements.
5. Acceptance testing:
This is the final stage in the testing process before the system is accepted for operational use.
The system is tested with data supplied by the system client rather than simulated test data.
Acceptance testing may reveal errors and omissions in the systems requirements definition(
user - oriented) because real data exercises the system in different ways from the test data.
Acceptance testing may also reveal requirement problems where the system facilities do not
really meet the users needs (functional) or the system performance (non-functional) is
unacceptable.
Acceptance testing is sometimes called alpha testing. Bespoke systems are developed for a
single client. The alpha testing process continues until the system developer and the client
agrees that the delivered system is an acceptable implementation of the system requirements.
When a system is to be marketed as a software product, a testing process called beta testing is
often used.
Beta testing involves delivering a system to a number of potential customers who agree to use
that system. They report problems to the system developers. This exposes the product to real
use and detects errors that may not have been anticipated by the system builders. After this
feedback, the system is modified and either released fur further beta testing or for general sale.
What is boundary value analysis?
Boundary value analysis is a technique for test data selection. A test engineer chooses values
that lie along data extremes. Boundary values include maximum, minimum, just inside
boundaries, just outside boundaries, typical values, and error values. The expectation is that, if
a systems works correctly for these extreme or special values, then it will work correctly for all
values in between. An effective way to test code is to exercise it at its natural boundaries.
Boundary Value Analysis is a method of testing that complements equivalence partitioning. In
this case, data input as well as data output are tested. The rationale behind BVA is that the
errors typically occur at the boundaries of the data. The boundaries refer to the upper limit and
the lower limit of a range of values or more commonly known as the "edges" of the boundary.
What is the purpose of black box testing?
Answer1:
The main purpose of BB Testing is to validate that the application works as the user will be
operating it and in the environments of their systems. How do you do system testing and
integration testing?
You may lose time and money but you may also lose Quality and eventually Customers!
Answer2:
"What is the purpose of black box testing?"
Black-box testing checks that the user interface and user inputs and outputs all work correctly.
Part of this is that error handling must work correctly. It's used in functional and system testing.
"We do everything in white box testing: - we check each module's function in the unit testing"
Who is "we"? Are you programmers or quality assurance testers? Usually, unit testing is done
by programmers, and white-box testing would be how they'd do it.
"- once unit test result is ok, means that modules work correctly (according to the requirement
documemts)"
Not quite. It means that on a stand-alone basis, each module is okay. White box testing only
tests the internal structure of the program, the code paths. Functional testing is needed to test
how the individual components work together, and this is best done from an external
perspective, meaning by using the software the way an end user would, without reference to the
code (which is what black-box testing is).
if we doing testing again in black box will we lose time and money?"
No, the opposite: You'll lose money from having to repair errors you didn't catch with the whitebox testing if you don't do some black-box testing. It's far more expensive to fix errors after
release than to test for them and fix them early on.
But again, who is "we"? The black box testers should not be the people who did the
programming; they should be the QA team -- also some end users for the usability testing.
Now that I've said that, good programmers will run some basic black-box tests before handing
the application to QA for testing. This isn't a substitute for having QA do the tests, but it's a lot
quicker for the programmer to find and fix an error right away than to have to go through the
whole process of reporting a bug, then fixing and releasing a new build, then retesting.
How do you create a test strategy?
The test strategy 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, a list of related tasks, pass/fail criteria and risk
assessment.
Inputs for this process:
* 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 can not provide, e.g. system limitations.
Outputs for this process:
* An approved and signed off test strategy document, test plan, including test cases.
* Testing issues requiring resolution. Usually this requires additional negotiation at the project
management level.
What is the purpose of test strategy?
Reason number 1: The number one reason of writing a test strategy document is to "have" a
signed, sealed, and delivered, FDA (or FAA) approved document, where the document includes
a written testing methodology, test plan, and test cases.
Reason number 2: Having a test strategy does satisfy one important step in the software testing
process.
Reason number 3: The test strategy document tells us how the software product will be tested.
Reason number 4: The creation of a test strategy document presents an opportunity to review
the test plan with the project team.
Reason number 5: The test strategy document describes the roles, responsibilities, and the
resources required for the test and schedule constraints.
Reason number 6: When we create a test strategy document, we have to put into writing any
testing issues requiring resolution (and usually this means additional negotiation at the project
management level).
Reason number 7: The test strategy is decided first, before lower level decisions are made on
the test plan, test design, and other testing issues
Why Q/A should not report to development?
Based on research from the Quality Assurance Institute, the percent of quality groups in each
location is noted,
50% - reports to Senior IT Manager - This is the best positioning because it gives the Quality
Manager immediate access to the IT Manager to discuss and promote Quality issues, when the
quality manager reports elsewhere, quality issues may not be raised to the appropriate level or
receive the necessary action.
25% - reports to Manager of systems/programming
15 % reports to Manger oprerations.
10 % outside IT function.
What is a requirements test matrix?

The requirements test matrix is a project management tool for tracking and managing testing
efforts, based on requirements, throughout the project's life cycle.
The requirements test matrix is a table, where requirement descriptions are put in the rows of
the table, and the descriptions of testing efforts are put in the column headers of the same
table.
The requirements test matrix is similar to the requirements traceability matrix, which is a
representation of user requirements aligned against system functionality. The requirements
traceability matrix ensures that all user requirements are addressed by the system integration
team and implemented in the system integration effort.
The requirements test matrix is a representation of user requirements aligned against system
testing. Similarly to the requirements traceability matrix, the requirements test matrix ensures
that all user requirements are addressed by the system test team and implemented in the
system testing effort.
Can you give me a requirements test matrix template?
For a requirements test matrix template, you want to visualize a simple, basic table that you
create for cross-referencing purposes.
Step 1: Find out how many requirements you have.
Step 2: Find out how many test cases you have.
Step 3: Based on these numbers, create a basic table. If you have a list of 90 requirements and
360 test cases, you want to create a table of 91 rows and 361 columns.
Step 4: Focus on the the first column of your table. One by one, copy all your 90 requirement
numbers, and paste them into rows 2 through 91 of the table.
Step 5: Now switch your attention to the the first row of the table. One by one, copy all your 360
test case numbers, and paste them into columns 2 through 361 of the table.
Step 6: Examine each of your 360 test cases, and, one by one, determine which of the 90
requirements they satisfy. If, for the sake of this example, test case number 64 satisfies
requirement number 12, then put a large "X" into cell 13-65 of your table... and then you have it;
you have just created a requirements test matrix template that you can use for cross-referencing
purposes
What metrics are used for bug tracking?
Metrics that can be used for bug tracking include the followings: the total number of bugs, total
number of bugs that have been fixed, number of new bugs per week, and the number of fixes
per week. Metrics for bug tracking can be used to determine when to stop testing, for example,
when bug rate falls below a certain level. You CAN learn to use defect tracking software.
What is the difference between verification and validation?
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, walkthroughs 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.
What stage of bug fixing is the most cost effective?
Bug prevention techniques (i.e. inspections, peer design reviews, and walk-throughs) are more
cost effective than bug detection
What is Defect Life Cycle.?
Answer1:
Defect life cycle is....different stages after a defect is identified.
New (When defect is identified)
Accepted (when Development team and QA team accepts it's a Bug)
In Progress (when a person is working to resolve the issue-defect)
Resolved (once the defect resolved)
Completed (Some one who can take up the responsibly Team lead)
Closed/reopened (Retested by TE and he will update the Status of the bug)
Answer2:
Defect Life Cycle is nothing but the various phases a Bug undergoes after it is raised or
reported.
A general Interview answer can be given as:
1. New or Opened
2. Assinged
3. Fixed
4. Tested
What's the difference between priority and severity?
The word "priority" is associated with scheduling, and the word "severity" is associated with
standards. "Priority" means something is afforded or deserves prior attention; a precedence
established by urgency or order of or importance.
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. For example, a severe code of behavior.
How do you write test cases?
When I write test cases, I concentrate on one requirement at a time. Then, based on that one
requirement, I come up with several real life scenarios that are likely to occur in the use of the
application by an end user.
When I write test cases, I describe the inputs, action, or event, and their expected results, in
order to determine if a feature of an application is working correctly. To make the test case
complete, I also add particulars e.g. test case identifiers, test case names, objectives, test
conditions (or setups), input data requirements (or steps), and expected results.
Additionally, if I have a choice, I like writing test cases as early as possible in the development
life cycle. Why? Because, as a side benefit of writing test cases, many times I am able to find
problems in the requirements or design of an application. And, because the process of
developing test cases makes me completely think through the operation of the application.
Freshers Jobs In India | Interview Preparation | Puzzles

www.fresherventure.net
Frequently Asked Manual Software Testing Interview Questions with Answers
1) What is difference between bug, error and defect?

Bug and defect essentially mean the same. It is the flaw in a component or system, which can
cause the component or system to fail to perform its required function. If a bug or defect is
encountered during the execution phase of the software development, it can cause the
component or the system to fail. On the other hand, an error is a human error, which gives
rise to incorrect result. You may want to know about, how to log a bug (defect), contents of a
bug, bug life cycle, and bug and statuses used during a bug life cycle, which help you in
understanding the terms bug and defect better.
2) Explain white box testing.
One of the testing types used in software testing is white box testing. Read in detail on white
box testing.
3) Tell me about V model in manual testing.
V model is a framework, which describes the software development life cycle activities right
from requirements specification up to software maintenance phase. Testing is integrated in
each of the phases of the model. The phases of the model start with user requirements and are
followed by system requirements, global design, detailed design, implementation and ends
with system testing of the entire system. Each phase of model has the respective testing
activity integrated in it and is carried out parallel to the development activities. The four test
levels used by this model include, component testing, integration testing, system testing and
acceptance testing.
4) What are stubs and drivers in manual testing?
Both stubs and drivers are a part of incremental testing. There are two approaches, which are
used in incremental testing, namely bottom up and top down approach. Drivers are used in
bottom up testing. They are modules, which test the components to be tested. The look of the
drivers is similar to the future real modules. A skeletal or special purpose implementation of a

component, which is used to develop or test a component, that calls or is otherwise dependent
on it. It is the replacement for the called component.
5) Explain black box testing.
Find the answer to the question in the article on black box testing.
6) Explain compatibility testing.
The answer to this question is in the article on compatibility testing.
7) What are the check lists, which a software tester should follow?
Read the link on check lists for software tester to find the answer to the question.
8) What are the different types of software testing?
There are a number of types of software testing which you will learn in the preceding link.
9) What are the phases of STLC?
Like there are different phases of the software development life cycle, there are different
phases of software testing life cycle as well. Read through software testing life cycle for more
explanation.
10) What is a Review?
A review is an evaluation of a said product or project status to ascertain any discrepancies
from the actual planned results and to recommend improvements to the said product. The
common examples of reviews are informal review or peer review, technical review,
inspection, walkthrough, management review. This is one of the manual testing interview
questions.
11) Explain beta testing.
For answer to this question, refer to the article on beta testing.
12) Explain equivalence class partition.
It is either specification based or a black box technique. Gather information on equivalence
partitioning from the article on equivalence partitioning.
13) What is a test case?
Find the answer to this question in the article titled test cases.
14) What is a test suite?

A test suite is a set of several test cases designed for a component of a software or system
under test, where the post condition of one test case is normally used as the precondition for
the next test.
15) What is acceptance testing?
Refer to the article on acceptance testing for the answer.
16) What is boundary value analysis?
A boundary value is an input or an output value, which resides on the edge of an equivalence
partition. It can also be the smallest incremental distance on either side of an edge, like the
minimum or a maximum value of an edge. Boundary value analysis is a black box testing
technique, where the tests are based on the boundary values.
17) What is compatibility testing?
Compatibility testing is a part of non-functional tests carried out on the software component
or the entire software to evaluate the compatibility of the application with the computing
environment. It can be with the servers, other software, computer operating system, different
web browsers or the hardware as well.
18) What is exact difference between debugging & testing?
When a test is run and a defect has been identified. It is the duty of the developer to first
locate the defect in the code and then fix it. This process is known as debugging. In other
words, debugging is the process of finding, analyzing and removing the causes of failures in
the software. On the other hand, testing consists of both static and dynamic testing life cycle
activities. It helps to determine that the software does satisfy specified requirements and it is
fit for purpose.
19) Explain in short, sanity testing, ad-hoc testing and smoke testing.
Sanity testing is a basic test, which is conducted if all the components of the software can be
compiled with each other without any problem. It is to make sure that there are no conflicting
or multiple functions or global variable definitions have been made by different developers. It
can also be carried out by the developers themselves. Smoke testing on the other hand is a
testing methodology used to cover all the major functionality of the application without
getting into the finer nuances of the application. It is said to be the main functionality
oriented test. Ad hoc testing is different than smoke and sanity testing. This term is used for
software testing, which is performed without any sort of planning and/or documentation.
These tests are intended to run only once. However in case of a defect found it can be carried
out again. It is also said to be a part of exploratory testing.
20) Explain performance testing.
It is one of the non-functional types of software testing. Performance of software is the
degree to which a system or a component of system accomplishes the designated functions

given constraints regarding processing time and throughput rate. Therefore, performance
testing is the process to test to determine the performance of software.
21) What is exploratory testing?
Read the page on exploratory testing to find the answer.
22) What is integration testing?
One of the software testing types, where tests are conducted to test interfaces between
components, interactions of the different parts of the system with operating system, file
system, hardware and between different software. It may be carried out by the integrator of
the system, but should ideally be carried out by a specific integration tester or a test team.
23) What is meant by functional defects and usability defects in general? Give appropriate
example.
We will take the example of Login window to understand functionality and usability
defects. A functionality defect is when a user gives a valid user name but invalid password
and the user clicks on login button. If the application accepts the user name and password,
and displays the main window, where an error should have been displayed. On the other hand
a usability defect is when the user gives a valid user name, but invalid password and clicks on
login button. The application throws up an error message saying Please enter valid user
name when the error message should have been Please enter valid Password.
24) What is pilot testing?
It is a test of a component of a software system or the entire system under the real time
operating conditions. The real time environment helps to find the defects in the system and
prevent costly bugs been detected later on. Normally a group of users use the system before
its complete deployment and give their feedback about the system.
25) Explain statement coverage.
It is a structure based or white box technique. Test coverage measures in a specific way the
amount of testing performed by a set of tests. One of the test coverage type is statement
coverage. It is the percentage of executable statements which have been exercise by a
particular test suite. The formula which is used for statement coverage is:
Statement Coverage = Number of statements exercised Total number of statements * 100%
26) Explain stress testing.
Find the answer to this question in this article on stress testing.
27) What is regression testing?
Regression testing is the testing of a particular component of the software or the entire
software after modifications have been made to it. The aim of regression testing is to ensure

new defects have not been introduced in the component or software, especially in the areas
where no changes have been made. In short, regression testing is the testing to ensure nothing
has changed, which should not have changed due to changes made.
28) What is security testing?
Read on security testing for an appropriate answer.
29) What is system testing?
System testing is testing carried out of an integrated system to verify, that the system meets
the specified requirements. It is concerned with the behavior of the whole system, according
to the scope defined. More often than not system testing is the final test carried out by the
development team, in order to verify that the system developed does meet the specifications
and also identify defects which may be present.
30) What is the difference between retest and regression testing?
Retesting, also known as confirmation testing is testing which runs the test cases that failed
the last time, when they were run in order to verify the success of corrective actions taken on
the defect found. On the other hand, regression testing is testing of a previously tested
program after the modifications to make sure that no new defects have been introduced. In
other words, it helps to uncover defects in the unchanged areas of the software.
31) Explain priority, severity in software testing.
Priority is the level of business importance, which is assigned to a defect found. On the other
hand, severity is the degree of impact, the defect can have on the development or operation of
the component or the system.
32) Explain the bug life cycle in detail.
This is one of the most commonly asked interview questions, hence this question is always a
part of software testing interview questions and answers for experienced as well as freshers.
The bug life cycle is the stages the bug or defect goes through before it is fixed, deferred or
rejected. Read in detail on bug life cycle.
33) What is the difference between volume testing and load testing?
Volume testing checks if the system can actually come up with the large amount of data. For
example, a number of fields in a particular record or numerous records in a file, etc. On the
other hand, load testing is measuring the behavior of a component or a system with increased
load. The increase in load can be in terms of number of parallel users and/or parallel
transactions. This helps to determine the amount of load, which can be handled by the
component or the software system.
34) What is usability testing?
Refer to the article titled usability testing for an answer to this question.

35) Explain the test case life cycle.

On an average a test case goes through the following phases. The first phase of the test case
life cycle is identifying the test scenarios either from the specifications or from the use cases
designed to develop the system. Once the scenarios have been identified, the test cases apt for
the scenarios have to be developed. Then the test cases are reviewed and the approval for
those test cases has to be taken from the concerned authority. After the test cases have been
approved, they are executed. When the execution of the test cases start, the results of the tests
have to be recorded. The test cases which pass are marked accordingly. If the test cases fail,
defects have to be raised. When the defects are fixed the failed test case has to be executed
again.
36) What is verification and validation?
Read on the two techniques used in software testing namely verification and validation in the
article on verification and validation.
37) Which are the different methodologies used in software testing?
Refer to software testing methodologies for detailed information on the different
methodologies used in software testing.
38) Explain the waterfall model in testing.
Waterfall model is a part of software development life cycle, as well as software testing. It is
one of the first models to be used for software testing.
39) Explain is Validation?
The process of evaluating software at the end of the software development process to ensure
compliance with software requirements. The techniques for validation are testing, inspection
and reviewing.
40) What is Verification?
The process of determining whether or not the products of a given phase of the software
development cycle meet the implementation steps and can be traced to the incoming
objectives established during the previous phase. The techniques for verification are testing,
inspection and reviewing.
1. What is Acceptance Testing?

Testing conducted to enable a user/customer to determine whether to accept a software product.
Normally performed to validate the software meets a set of agreed acceptance criteria.
2. What is Accessibility Testing?
Verifying a product is accessible to the people having disabilities (deaf, blind, mentally disabled
etc.).
3. What is Ad Hoc Testing?
A testing phase where the tester tries to 'break' the system by randomly trying the system's
functionality. Can include negative testing as well. See also Monkey Testing.
4. What is Agile Testing?
Testing practice for projects using agile methodologies, treating development as the customer of
testing and emphasizing a test-first design paradigm. See also Test Driven Development.
5. What is Application Binary Interface (ABI)?
A specification defining requirements for portability of applications in binary forms across different
system platforms and environments.
6. What is Application Programming Interface (API)?
A formalized set of software calls and routines that can be referenced by an application program in
order to access supporting system or network services.
7. What is Automated Software Quality (ASQ)?
The use of software tools, such as automated testing tools, to improve software quality.
8. What is Automated Testing?
Testing employing software tools which execute tests without manual intervention. Can be applied in
GUI, performance, API, etc. testing. The use of software to control the execution of tests, the
comparison of actual outcomes to predicted outcomes, the setting up of test preconditions, and
other test control and test reporting functions.
9. What is Backus-Naur Form?
A metalanguage used to formally describe the syntax of a language.
10. What is Basic Block?
A sequence of one or more consecutive, executable statements containing no branches.
11. What is Basis Path Testing?
A white box test case design technique that uses the algorithmic flow of the program to design tests.
12. What is Basis Set?
The set of tests derived using basis path testing.
13. What is Baseline?
The point at which some deliverable produced during the software engineering process is put under
formal change control.
14. What you will do during the first day of job?
What would you like to do five years from now?
15. What is Beta Testing?
Testing of a release of a software product conducted by customers.
16. What is Binary Portability Testing?
Testing an executable application for portability across system platforms and environments, usually
for conformation to an ABI specification.
17. What is Black Box Testing?
Testing based on an analysis of the specification of a piece of software without reference to its
internal workings. The goal is to test how well the component conforms to the published
requirements for the component.
18. What is Bottom Up Testing?
An approach to integration testing where the lowest level components are tested first, then used to
facilitate the testing of higher level components. The process is repeated until the component at the
top of the hierarchy is tested.
19. What is Boundary Testing?
Test which focus on the boundary or limit conditions of the software being tested. (Some of these
tests are stress tests).
20. What is Bug?
A fault in a program which cause it to perform in an unintended or unanticipated manner.
20. What is Defect?
If software misses some feature or function from what is there in requirement it is called as defect.
21. What is Boundary Value Analysis?
BVA is similar to Equivalence Partitioning but focuses on "corner cases" or values that are usually out
of range as defined by the specification. his means that if a function expects all values in range of
negative 100 to positive 1000, test inputs would include negative 101 and positive 1001.
22. What is Branch Testing?
Testing in which all branches in the program source code are tested at least once.
23. What is Breadth Testing?
A test suite that exercises the full functionality of a product but does not test features in detail.
24. What is CAST?
Computer Aided Software Testing.
25. What is Capture/Replay Tool?
A test tool that records test input as it is sent to the software under test. The input cases stored can
then be used to reproduce the test at a later time. Most commonly applied to GUI test tools.
26. What is CMM?
The Capability Maturity Model for Software (CMM or SW-CMM) is a model for judging the maturity of
the software processes of an organization and for identifying the key practices that are required to
increase the maturity of these processes.
27. What is Cause Effect Graph?
A graphical representation of inputs and the associated outputs effects which can be used to design
test cases.
28. What is Code Complete?
Phase of development where functionality is implemented in entirety; bug fixes are all that are left.
All functions found in the Functional Specifications have been implemented.
29. What is Code Coverage?
An analysis method that determines which parts of the software have been executed (covered) by
the test case suite and which parts have not been executed and therefore may require additional
attention.
30. What is Code Inspection?
A formal testing technique where the programmer reviews source code with a group who ask
questions analyzing the program logic, analyzing the code with respect to a checklist of historically
common programming errors, and analyzing its compliance with coding standards.
31. What is Code Walkthrough?
A formal testing technique where source code is traced by a group with a small set of test cases,
while the state of program variables is manually monitored, to analyze the programmer's logic and
assumptions.
32. What is Coding?
The generation of source code.
33. What is Compatibility Testing?
Testing whether software is compatible with other elements of a system with which it should
operate, e.g. browsers, Operating Systems, or hardware.
34. What is Component?
A minimal software item for which a separate specification is available.
35. What is Component Testing?
Testing of individual software components (Unit Testing).
36. What is Concurrency Testing?
Multi-user testing geared towards determining the effects of accessing the same application code,
module or database records. Identifies and measures the level of locking, deadlocking and use of
single-threaded code and locking semaphores.
37. What is Conformance Testing?
The process of testing that an implementation conforms to the specification on which it is based.
Usually applied to testing conformance to a formal standard.
38. What is Context Driven Testing?
The context-driven school of software testing is flavor of Agile Testing that advocates continuous and
creative evaluation of testing opportunities in light of the potential information revealed and the
value of that information to the organization right now.
39. What is Conversion Testing?
Testing of programs or procedures used to convert data from existing systems for use in replacement
systems.
40. What is Cyclomtic Complexity?
A measure of the logical complexity of an algorithm, used in white-box testing.
41. What is Data Dictionary?
A database that contains definitions of all data items defined during analysis.
42. What is Data Flow Diagram?
A modeling notation that represents a functional decomposition of a system.
43. What is Data Driven Testing?
Testing in which the action of a test case is parameterized by externally defined data values,
maintained as a file or spreadsheet. A common technique in Automated Testing.
44. What is Debugging?
The process of finding and removing the causes of software failures.
45. What is Defect?
Nonconformance to requirements or functional / program specification
46. What is Dependency Testing?
Examines an application's requirements for pre-existing software, initial states and configuration in
order to maintain proper functionality.
47. What is Depth Testing?
A test that exercises a feature of a product in full detail.
48. What is Dynamic Testing?
Testing software through executing it. See also Static Testing.
49. What is Emulator?
A device, computer program, or system that accepts the same inputs and produces the same outputs
as a given system.
50. What is Endurance Testing?
Checks for memory leaks or other problems that may occur with prolonged execution.
51. What is End-to-End testing?
Testing a complete application environment in a situation that mimics real-world use, such as
interacting with a database, using network communications, or interacting with other hardware,
applications, or systems if appropriate.
52. What is Equivalence Class?
A portion of a component's input or output domains for which the component's behaviour is assumed
to be the same from the component's specification.
53. What is Equivalence Partitioning?
A test case design technique for a component in which test cases are designed to execute
representatives from equivalence classes.
54. What is Exhaustive Testing?
Testing which covers all combinations of input values and preconditions for an element of the
software under test.
55. What is Functional Decomposition?
A technique used during planning, analysis and design; creates a functional hierarchy for the
software.
54. What is Functional Specification?
A document that describes in detail the characteristics of the product with regard to its intended
features.
55. What is Functional Testing?
Testing the features and operational behavior of a product to ensure they correspond to its
specifications. Testing that ignores the internal mechanism of a system or component and focuses
solely on the outputs generated in response to selected inputs and execution conditions. or Black Box
Testing.
56. What is Glass Box Testing?
A synonym for White Box Testing.
57. What is Gorilla Testing?
Testing one particular module, functionality heavily.
58. What is Gray Box Testing?
A combination of Black Box and White Box testing methodologies? testing a piece of software against
its specification but using some knowledge of its internal workings.
59. What is High Order Tests?
Black-box tests conducted once the software has been integrated.
60. What is Independent Test Group (ITG)?
A group of people whose primary responsibility is software testing,
61. What is Inspection?
A group review quality improvement process for written material. It consists of two aspects; product
(document itself) improvement and process improvement (of both document production and
inspection).
62. What is Integration Testing?
Testing of combined parts of an application to determine if they function together correctly. Usually
performed after unit and functional testing. This type of testing is especially relevant to
client/server and distributed systems.
63. What is Installation Testing?
Confirms that the application under test recovers from expected or unexpected events without loss
of data or functionality. Events can include shortage of disk space, unexpected loss of
communication, or power out conditions.
64. What is Load Testing?
See Performance Testing.
65. What is Localization Testing?
This term refers to making software specifically designed for a specific locality.
66. What is Loop Testing?
A white box testing technique that exercises program loops.
67. What is Metric?
A standard of measurement. Software metrics are the statistics describing the structure or content of
a program. A metric should be a real objective measurement of something such as number of bugs
per lines of code.
68. What is Monkey Testing?
Testing a system or an Application on the fly, i.e just few tests here and there to ensure the system
or an application does not crash out.
69. What is Negative Testing?
Testing aimed at showing software does not work. Also known as "test to fail". See also Positive
Testing.
70. What is Path Testing?
Testing in which all paths in the program source code are tested at least once.
71. What is Performance Testing?
Testing conducted to evaluate the compliance of a system or component with specified performance
requirements. Often this is performed using an automated test tool to simulate large number of
users. Also know as "Load Testing".
72. What is Positive Testing?
Testing aimed at showing software works. Also known as "test to pass". See also Negative Testing.
73. What is Quality Assurance?
All those planned or systematic actions necessary to provide adequate confidence that a product or
service is of the type and quality needed and expected by the customer.
74. What is Quality Audit?
A systematic and independent examination to determine whether quality activities and related
results comply with planned arrangements and whether these arrangements are implemented
effectively and are suitable to achieve objectives.
75. What is Quality Circle?
A group of individuals with related interests that meet at regular intervals to consider problems or
other matters related to the quality of outputs of a process and to the correction of problems or to
the improvement of quality.
76. What is Quality Control?
The operational techniques and the activities used to fulfill and verify requirements of quality.
77. What is Quality Management?
That aspect of the overall management function that determines and implements the quality policy.
78. What is Quality Policy?
The overall intentions and direction of an organization as regards quality as formally expressed by
top management.
79. What is Quality System?
The organizational structure, responsibilities, procedures, processes, and resources for implementing
quality management.
80. What is Race Condition?
A cause of concurrency problems. Multiple accesses to a shared resource, at least one of which is a
write, with no mechanism used by either to moderate simultaneous access.
81. What is Ramp Testing?
Continuously raising an input signal until the system breaks down.
82. What is Recovery Testing?
Confirms that the program recovers from expected or unexpected events without loss of data or
functionality. Events can include shortage of disk space, unexpected loss of communication, or power
out conditions.
83. What is Regression Testing?
Retesting a previously tested program following modification to ensure that faults have not been
introduced or uncovered as a result of the changes made.
84. What is Release Candidate?
A pre-release version, which contains the desired functionality of the final version, but which needs
to be tested for bugs (which ideally should be removed before the final version is released).
85. What is Sanity Testing?
Brief test of major functional elements of a piece of software to determine if its basically
operational. See also Smoke Testing.
86. What is Scalability Testing?
Performance testing focused on ensuring the application under test gracefully handles increases in
work load.
87. What is Security Testing?
Testing which confirms that the program can restrict access to authorized personnel and that the
authorized personnel can access the functions available to their security level.
88. What is Smoke Testing?
A quick-and-dirty test that the major functions of a piece of software work. Originated in the
hardware testing practice of turning on a new piece of hardware for the first time and considering it
a success if it does not catch on fire.
89. What is Soak Testing?
Running a system at high load for a prolonged period of time. For example, running several times
more transactions in an entire day (or night) than would be expected in a busy day, to identify and
performance problems that appear after a large number of transactions have been executed.
90. What is Software Requirements Specification?
A deliverable that describes all data, functional and behavioral requirements, all constraints, and all
validation requirements for software/
91. What is Software Testing?
A set of activities conducted with the intent of finding errors in software.
92. What is Static Analysis?
Analysis of a program carried out without executing the program.
93. What is Static Analyzer?
A tool that carries out static analysis.
94. What is Static Testing?
Analysis of a program carried out without executing the program.
95. What is Storage Testing?
Testing that verifies the program under test stores data files in the correct directories and that it
reserves sufficient space to prevent unexpected termination resulting from lack of space. This is
external storage as opposed to internal storage.
96. What is Stress Testing?
Testing conducted to evaluate a system or component at or beyond the limits of its specified
requirements to determine the load under which it fails and how. Often this is performance testing
using a very high level of simulated load.
97. What is Structural Testing?
Testing based on an analysis of internal workings and structure of a piece of software. See also White
Box Testing.
98. What is System Testing?
Testing that attempts to discover defects that are properties of the entire system rather than of its
individual components.
99. What is Testability?
The degree to which a system or component facilitates the establishment of test criteria and the
performance of tests to determine whether those criteria have been met.
100. What is Testing?
The process of exercising software to verify that it satisfies specified requirements and to detect
errors. The process of analyzing a software item to detect the differences between existing and
required conditions (that is, bugs), and to evaluate the features of the software item (Ref. IEEE Std
829). The process of operating a system or component under specified conditions, observing or
recording the results, and making an evaluation of some aspect of the system or component. What is
Test Automation? It is the same as Automated Testing.
101. What is Test Bed?
An execution environment configured for testing. May consist of specific hardware, OS, network
topology, configuration of the product under test, other application or system software, etc. The
Test Plan for a project should enumerated the test beds(s) to be used.
102. What is Test Case?
Test Case is a commonly used term for a specific test. This is usually the smallest unit of testing. A
Test Case will consist of information such as requirements testing, test steps, verification steps,
prerequisites, outputs, test environment, etc. A set of inputs, execution preconditions, and expected
outcomes developed for a particular objective, such as to exercise a particular program path or to
verify compliance with a specific requirement. Test Driven Development? Testing methodology
associated with Agile Programming in which every chunk of code is covered by unit tests, which must
all pass all the time, in an effort to eliminate unit-level and regression bugs during development.
Practitioners of TDD write a lot of tests, i.e. an equal number of lines of test code to the size of the
production code.
103. What is Test Driver?
A program or test tool used to execute a tests. Also known as a Test Harness.
104. What is Test Environment?
The hardware and software environment in which tests will be run, and any other software with
which the software under test interacts when under test including stubs and test drivers.
105. What is Test First Design?
Test-first design is one of the mandatory practices of Extreme Programming (XP).It requires that
programmers do not write any production code until they have first written a unit test.
106. What is Test Harness?
A program or test tool used to execute a tests. Also known as a Test Driver.
107. What is Test Plan?
A document describing the scope, approach, resources, and schedule of intended testing activities.
It identifies test items, the features to be tested, the testing tasks, who will do each task, and any
risks requiring contingency planning.
108. What is Test Procedure?
A document providing detailed instructions for the execution of one or more test cases.
109. What is Test Script?
Commonly used to refer to the instructions for a particular test that will be carried out by an
automated test tool.
110. What is Test Specification?
A document specifying the test approach for a software feature or combination or features and the
inputs, predicted results and execution conditions for the associated tests.
111. What is Test Suite?
A collection of tests used to validate the behavior of a product. The scope of a Test Suite varies from
organization to organization. There may be several Test Suites for a particular product for example.
In most cases however a Test Suite is a high level concept, grouping together hundreds or thousands
of tests related by what they are intended to test.
112. What is Test Tools?
Computer programs used in the testing of a system, a component of the system, or its
documentation.
113. What is Thread Testing?
A variation of top-down testing where the progressive integration of components follows the
implementation of subsets of the requirements, as opposed to the integration of components by
successively lower levels.
114. What is Top Down Testing?
An approach to integration testing where the component at the top of the component hierarchy is
tested first, with lower level components being simulated by stubs. Tested components are then used
to test lower level components. The process is repeated until the lowest level components have been
tested.
115. What is Total Quality Management?
A company commitment to develop a process that achieves high quality product and customer
satisfaction.
116. What is Traceability Matrix?
A document showing the relationship between Test Requirements and Test Cases.
117. What is Usability Testing?
Testing the ease with which users can learn and use a product.
118. What is Use Case?
The specification of tests that are conducted from the end-user perspective. Use cases tend to focus
on operating software as an end-user would conduct their day-to-day activities.
119. What is Unit Testing?
Testing of individual software components.
120. What is Validation?

The process of evaluating software at the end of the software development process to ensure
compliance with software requirements. The techniques for validation is testing, inspection and
reviewing.
121. What is Verification?
The process of determining whether or not the products of a given phase of the software
development cycle meet the implementation steps and can be traced to the incoming objectives
established during the previous phase. The techniques for verification are testing, inspection and
reviewing.
122. What is White Box Testing?
Testing based on an analysis of internal workings and structure of a piece of software. Includes
techniques such as Branch Testing and Path Testing. Also known as Structural Testing and Glass Box
Testing. Contrast with Black Box Testing.
123. What is Workflow Testing?
Scripted end-to-end testing which duplicates specific workflows which are expected to be utilized by
the end-user.
124. What's the difference between load and stress testing ?
One of the most common, but unfortunate misuse of terminology is treating load testing and
stress testing as synonymous. The consequence of this ignorant semantic abuse is usually that the
system is neither properly load tested nor subjected to a meaningful stress test.
Stress testing is subjecting a system to an unreasonable load while denying it the resources (e.g.,
RAM, disc, mips, interrupts, etc.) needed to process that load. The idea is to stress a system to the
breaking point in order to find bugs that will make that break potentially harmful. The system is not
expected to process the overload without adequate resources, but to behave (e.g., fail) in a decent
manner (e.g., not corrupting or losing data). Bugs and failure modes discovered under stress testing
may or may not be repaired depending on the application, the failure mode, consequences, etc. The
load (incoming transaction stream) in stress testing is often deliberately distorted so as to force the
system into resource depletion.
Load testing is subjecting a system to a statistically representative (usually) load. The two main
reasons for using such loads is in support of software reliability testing and in performance testing.
The term 'load testing' by itself is too vague and imprecise to warrant use. For example, do you mean
representative load,' 'overload,' 'high load,' etc. In performance testing, load is varied from a
minimum (zero) to the maximum level the system can sustain without running out of resources or
having, transactions >suffer (application-specific) excessive delay. A third use of the term is as a test
whose objective is to determine the maximum sustainable load the system can handle. In this usage,
'load testing' is merely testing at the highest transaction arrival rate in performance testing.
125. What's the difference between QA and testing?
QA is more a preventive thing, ensuring quality in the company and therefore the product rather than
just testing the product for software bugs? TESTING means 'quality control' QUALITY CONTROL
measures the quality of a product QUALITY ASSURANCE measures the quality of processes used to
create a quality product.
126. What is the best tester to developer ratio?
Reported tester: developer ratios range from 10:1 to 1:10. There's no simple answer. It depends on so
many things, Amount of reused code, number and type of interfaces, platform, quality goals, etc. It
also can depend on the development model. The more specs, the less testers. The roles can play a
big part also. Does QA own beta? Do you include process auditors or planning activities? These figures
can all vary very widely depending on how you define 'tester' and 'developer'. In some organizations,
a 'tester' is anyone who happens to be testing software at the time -- such as their own. In other
organizations, a 'tester' is only a member of an independent test group. It is better to ask about the
test labor content than it is to ask about the tester/developer ratio. The test labor content, across
most applications is generally accepted as 50%, when people do honest accounting. For life-critical
software, this can go up to 80%.
127. How can new Software QA processes be introduced in an existing organization?
- A lot depends on the size of the organizattion and the risks involved. For large organizations with
high-risk (in terms of lives or property) projects, serious management buy-in is required and a
formalized QA process is necessary.
- Where the risk is lower, management and orrganizational buy-in and QA implementation may be a
slower, step-at-a-time process. QA processes should be balanced with productivity so as to keep
bureaucracy from getting out of hand.

- For small groups or projects, a more ad-hooc process may be appropriate, depending on the type of
customers and projects. A lot will depend on team leads or managers, feedback to developers, and
ensuring adequate communications among customers, managers, developers, and testers.
- In all cases the most value for effort willl be in requirements management processes, with a goal of
clear, complete, testable requirement specifications or expectations.
128. What are 5 common problems in the software development process?
1. poor requirements - if requirements are unclear, incomplete, too general, or not testable, there
will be problems.
2. unrealistic schedule - if too much work is crammed in too little time, problems are inevitable.
3. inadequate testing - no one will know whether or not the program is any good until the customer
complains or systems crash.
4. featuritis - requests to pile on new features after development is underway; extremely common.
5. miscommunication - if developers don't know what's needed or customer's have erroneous
expectations, problems are guaranteed.
129. What are 5 common solutions to software development problems?
1. solid requirements - clear, complete, detailed, cohesive, attainable, testable requirements that
are agreed to by all players. Use prototypes to help nail down requirements.
2. realistic schedules - allow adequate time for planning, design, testing, bug fixing, re-testing,
changes, and documentation; personnel should be able to complete the project without burning out.
3. adequate testing - start testing early on, re-test after fixes or changes, plan for adequate time for
testing and bug-fixing.
4. stick to initial requirements as much as possible - be prepared to defend against changes and
additions once development has begun, and be prepared to explain consequences. If changes are
necessary, they should be adequately reflected in related schedule changes. If possible, use rapid
prototyping during the design phase so that customers can see what to expect. This will provide them
a higher comfort level with their requirements decisions and minimize changes later on.
5. communication - require walkthroughs and inspections when appropriate; make extensive use of
group communication tools - e-mail, groupware, networked bug-tracking tools and change
management tools, intranet capabilities, etc.; insure that documentation is available and up-to-date
- preferably electronic, not paper; promote teamwork and cooperation; use prototypes early on so
that customers' expectations are clarified.
130. What is 'good code'?
'Good code' is code that works, is bug free, and is readable and maintainable. Some organizations
have coding 'standards' that all developers are supposed to adhere to, but everyone has different
ideas about what's best, or what is too many or too few rules. There are also various theories and
metrics, such as McCabe Complexity metrics. It should be kept in mind that excessive use of
standards and rules can stifle productivity and creativity. 'Peer reviews', 'buddy checks' code analysis
tools, etc. can be used to check for problems and enforce standards.
For C and C++ coding, here are some typical ideas to consider in setting rules/standards; these may
or may not apply to a particular situation:
- minimize or eliminate use of global variabbles.
- use descriptive function and method names - use both upper and lower case, avoid abbreviations,
use as many characters as necessary to be adequately descriptive (use of more than 20 characters is
not out of line); be consistent in naming conventions.
- use descriptive variable names - use both upper and lower case, avoid abbreviations, use as many
characters as necessary to be adequately descriptive (use of more than 20 characters is not out of
line); be consistent in naming conventions.
- function and method sizes should be minimiized; less than 100 lines of code is good, less than 50
lines is preferable.
- function descriptions should be clearly sppelled out in comments preceding a function's code.
- organize code for readability.
- use whitespace generously - vertically andd horizontally
- each line of code should contain 70 characcters max.
- one code statement per line.
- coding style should be consistent throughtt a program (eg, use of brackets, indentations, naming
conventions, etc.)
- in adding comments, err on the side of tooo many rather than too few comments; a common rule of
thumb is that there should be at least as many lines of comments (including header blocks) as lines of
code.
- no matter how small, an application shouldd include documentaion of the overall program function
and flow (even a few paragraphs is better than nothing); or if possible a separate flow chart and
detailed program documentation.
- make extensive use of error handling proceedures and status and error logging.
- for C++, to minimize complexity and increaase maintainability, avoid too many levels of inheritance
in class heirarchies (relative to the size and complexity of the application). Minimize use of multiple
inheritance, and minimize use of operator overloading (note that the Java programming language
eliminates multiple inheritance and operator overloading.)
- for C++, keep class methods small, less thhan 50 lines of code per method is preferable.
- for C++, make liberal use of exception hanndlers
131. What is 'good design'?
'Design' could refer to many things, but often refers to 'functional design' or 'internal design'. Good
internal design is indicated by software code whose overall structure is clear, understandable, easily
modifiable, and maintainable; is robust with sufficient error-handling and status logging capability;
and works correctly when implemented. Good functional design is indicated by an application whose
functionality can be traced back to customer and end-user requirements. For programs that have a
user interface, it's often a good idea to assume that the end user will have little computer knowledge
and may not read a user manual or even the on-line help; some common rules-of-thumb include:
- the program should act in a way that leastt surprises the user
- it should always be evident to the user whhat can be done next and how to exit
- the program shouldn't let the users do sommething stupid without warning them.
132. What makes a good test engineer?
A good test engineer has a 'test to break' attitude, an ability to take the point of view of the
customer, a strong desire for quality, and an attention to detail. Tact and diplomacy are useful in
maintaining a cooperative relationship with developers, and an ability to communicate with both
technical (developers) and non-technical (customers, management) people is useful. Previous
software development experience can be helpful as it provides a deeper understanding of the
software development process, gives the tester an appreciation for the developers' point of view, and
reduce the learning curve in automated test tool programming. Judgment skills are needed to assess
high-risk areas of an application on which to focus testing efforts when time is limited.
133. What makes a good Software QA engineer?
The same qualities a good tester has are useful for a QA engineer. Additionally, they must be able to
understand the entire software development process and how it can fit into the business approach
and goals of the organization. Communication skills and the ability to understand various sides of
issues are important. In organizations in the early stages of implementing QA processes, patience and
diplomacy are especially needed. An ability to find problems as well as to see 'what's missing' is
important for inspections and reviews.
134. What makes a good QA or Test manager?
A good QA, test, or QA/Test(combined) manager should:
- be familiar with the software development process
- be able to maintain enthusiasm of their team and promote a positive atmosphere, despite what is a
somewhat 'negative' process (e.g., looking for or preventing problems)
- be able to promote teamwork to increase productivity
- be able to promote cooperation between software, test, and QA engineers
- have the diplomatic skills needed to promote improvements in QA processes
-have the ability to withstand pressures and say 'no' to other managers when quality is insufficient or
QA processes are not being adhered to
- have people judgment skills for hiring and keeping skilled personnel
- be able to communicate with technical and non-technical people, engineers, managers, and
customers.
- be able to run meetings and keep them focused
135. What's the role of documentation in QA?
Critical. (Note that documentation can be electronic, not necessarily paper.) QA practices should be
documented such that they are repeatable. Specifications, designs, business rules, inspection
reports, configurations, code changes, test plans, test cases, bug reports, user manuals, etc. should
all be documented. There should ideally be a system for easily finding and obtaining documents and
determining what documentation will have a particular piece of information. Change management
for documentation should be used if possible.
136. What's the big deal about 'requirements'?
One of the most reliable methods of insuring problems, or failure, in a complex software project is to
have poorly documented requirements 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' (too subjective). A testable requirement would be something like 'the
user must enter their previously-assigned password to access the application'. Determining and
organizing requirements details in a useful and efficient way can be a difficult effort; different
methods are available depending on the particular project. Many books are available that describe
various approaches to this task. Care should be taken to involve ALL of a project's significant
'customers' in the requirements process. 'Customers' could be in-house personnel or out, and could
include end-users, customer acceptance testers, customer contract officers, customer management,
future software maintenance engineers, salespeople, etc. Anyone who could later derail the project
if their expectations aren't met should be included if possible. Organizations vary considerably in
their handling of requirements specifications. Ideally, the requirements are spelled out in a
document with statements such as 'The product shall.....'. 'Design' specifications should not be
confused with 'requirements'; design specifications should be traceable back to the requirements. In
some organizations requirements may end up in high level project plans, functional specification
documents, in design documents, or in other documents at various levels of detail. No matter what
they are called, some type of documentation with detailed requirements will be needed by testers 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.
137. What steps are needed to develop and run software tests?
The following are some of the steps to consider:
- Obtain requirements, functional design, annd internal design specifications and other necessary
documents
- Obtain budget and schedule requirements - Determine project-related personnel and thheir
responsibilities, reporting requirements, required standards and processes (such as release processes,
change processes, etc.)
- Identify application's higher-risk aspectss, set priorities, and determine scope and limitations of
tests
- Determine test approaches and methods - unnit, integration, functional, system, load, usability
tests, etc.
- Determine test environment requirements (hhardware, software, communications, etc.)
-Determine testware requirements (record/plaayback tools, coverage analyzers, test tracking,
problem/bug tracking, etc.)
- Determine test input data requirements - Identify tasks, those responsible for taskks, and labor
requirements
- Set schedule estimates, timelines, milestoones
- Determine input equivalence classes, bounddary value analyses, error classes
- Prepare test plan document and have neededd reviews/approvals
- Write test cases
- Have needed reviews/inspections/approvals of test cases
- Prepare test environment and testware, obttain needed user manuals/reference
documents/configuration guides/installation guides, set up test tracking processes, set up logging
and archiving processes, set up or obtain test input data
- Obtain and install software releases
- Perform tests
- Evaluate and report results
- Track problems/bugs and fixes
- Retest as needed
- Maintain and update test plans, test casess, test environment, and testware through life cycle
138. What is 'configuration management'?
Configuration management covers the 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.
139. What if the software is so buggy it can't really be tested at all?
The best bet in this situation is for the testers to go through the process of reporting whatever bugs
or blocking-type problems initially show up, with the focus being on critical bugs. Since this type of
problem can severely affect schedules, and indicates deeper problems in the software development
process (such as insufficient unit testing or insufficient integration testing, poor design, improper
build or release procedures, etc.) managers should be notified, and provided with some
documentation as evidence of the problem.
140. How can it be known when to stop testing?
This can be difficult to determine. Many modern software applications are so complex, and run in
such an interdependent environment, that complete testing can never be done. Common factors in
deciding when to stop are:
- Deadlines (release deadlines, testing deadlines, etc.)
- Test cases completed with certain percentage passed
- Test budget depleted
- Coverage of code/functionality/requirements reaches a specified point
- Bug rate falls below a certain level
> - Beta or alpha testing period ends
141. What if there isn't enough time for thorough testing?
Use risk analysis to determine where testing should be focused.
Since it's rarely possible to test every possible aspect of an application, every possible combination of
events, every dependency, or everything that could go wrong, risk analysis is appropriate to most
software development projects. This requires judgement skills, common sense, and experience. (If
warranted, formal methods are also available.) Considerations can include:
- Which functionality is most important to the project's intended purpose?
- Which functionality is most visible to the user?
- Which functionality has the largest safety impact?
- Which functionality has the largest financial impact on users?
- Which aspects of the application are most important to the customer?
- Which aspects of the application can be tested early in the development cycle?
- Which parts of the code are most complex, and thus most subject to errors?
- Which parts of the application were developed in rush or panic mode?
- Which aspects of similar/related previous projects caused problems?
- Which aspects of similar/related previous projects had large maintenance expenses?
- Which parts of the requirements and design are unclear or poorly thought out?
- What do the developers think are the highest-risk aspects of the application?
- What kinds of problems would cause the worst publicity?
- What kinds of problems would cause the most customer service complaints?
- What kinds of tests could easily cover multiple functionalities?
- Which tests will have the best high-risk-coverage to time-required ratio?
142. What can be done if requirements are changing continuously?
A common problem and a major headache.
- Work with the project's stakeholders earlyy on to understand how requirements might change so
that alternate test plans and strategies can be worked out in advance, if possible.
- It's helpful if the application's initial design allows for some adaptability so that later changes do
not require redoing the application from scratch.
- If the code is well-commented and well-doccumented this makes changes easier for the developers.
- Use rapid prototyping whenever possible too help customers feel sure of their requirements and
minimize changes.
- The project's initial schedule should alloow for some extra time commensurate with the possibility
of changes.
- Try to move new requirements to a 'Phase 22' version of an application, while using the original
requirements for the 'Phase 1' version.
- Negotiate to allow only easily-implementedd new requirements into the project, while moving more
difficult new requirements into future versions of the application.
- Be sure that customers and management undeerstand the scheduling impacts, inherent risks, and
costs of significant requirements changes. Then let management or the customers (not the
developers or testers) decide if the changes are warranted - after all, that's their job.
- Balance the effort put into setting up auttomated testing with the expected effort required to redo them to deal with changes.
- Try to design some flexibility into automaated test scripts.
- Focus initial automated testing on applicaation aspects that are most likely to remain unchanged.
- Devote appropriate effort to risk analysiss of changes to minimize regression testing needs.
- Design some flexibility into test cases (tthis is not easily done; the best bet might be to minimize
the detail in the test cases, or set up only higher-level generic-type test plans)
- Focus less on detailed test plans and testt cases and more on ad hoc testing (with an understanding
of the added risk that this entails).
143. What if the project isn't big enough to justify extensive testing?
Consider the impact of project errors, not the size of the project. However, if extensive testing is
still not justified, risk analysis is again needed and the same considerations as described previously in
'What if there isn't enough time for thorough testing?' apply. The tester might then do ad hoc testing,
or write up a limited test plan based on the risk analysis.
144. What if the application has functionality that wasn't in the requirements?
It may take serious effort to determine if an application has significant unexpected or hidden
functionality, and it would indicate deeper problems in the software development process. If the
functionality isn't necessary to the purpose of the application, it should be removed, as it may have
unknown impacts or dependencies that were not taken into account by the designer or the customer.
If not removed, design information will be needed to determine added testing needs or regression
testing needs. Management should be made aware of any significant added risks as a result of the
unexpected functionality. If the functionality only effects areas such as minor improvements in the
user interface, for example, it may not be a significant risk.
145. How can Software QA processes be implemented without stifling productivity?
By implementing QA processes slowly over time, using consensus to reach agreement on processes,
and adjusting and experimenting as an organization grows and matures, productivity will be improved
instead of stifled. Problem prevention will lessen the need for problem detection, panics and burnout will decrease, and there will be improved focus and less wasted effort. At the same time,
attempts should be made to keep processes simple and efficient, minimize paperwork, promote
computer-based processes and automated tracking and reporting, minimize time required in
meetings, and promote training as part of the QA process. However, no one - especially talented
technical types - likes rules or bureacracy, and in the short run things may slow down a bit. A typical
scenario would be that more days of planning and development will be needed, but less time will be
required for late-night bug-fixing and calming of irate customers.
146. What if an organization is growing so fast that fixed QA processes are impossible?
This is a common problem in the software industry, especially in new technology areas. There is no
easy solution in this situation, other than:
- Hire good people
- Management should 'ruthlessly prioritize' quality issues and maintain focus on the customer
- Everyone in the organization should be cleear on what 'quality' means to the customer
147. How does a client/server environment affect testing?
Client/server applications can be quite complex due to the multiple dependencies among clients,
data communications, hardware, and servers. Thus testing requirements can be extensive. When
time is limited (as it usually is) the focus should be on integration and system testing. Additionally,
load/stress/performance testing may be useful in determining client/server application limitations
and capabilities. There are commercial tools to assist with such testing.
148. How can World Wide Web sites be tested?
Web sites are essentially client/server applications - with web servers and 'browser' clients.
Consideration should be given to the interactions between html pages, TCP/IP communications,
Internet connections, firewalls, applications that run in web pages (such as applets, javascript, plugin applications), and applications that run on the server side (such as cgi scripts, database interfaces,
logging applications, dynamic page generators, asp, etc.). Additionally, there are a wide variety of
servers and browsers, various versions of each, small but sometimes significant differences between
them, variations in connection speeds, rapidly changing technologies, and multiple standards and
protocols. The end result is that testing for web sites can become a major ongoing effort. Other
considerations might include:
- What are the expected loads on the server (e.g., number of hits per unit time?), and what kind of
performance is required under such loads (such as web server response time, database query
response times). What kinds of tools will be needed for performance testing (such as web load testing
tools, other tools already in house that can be adapted, web robot downloading tools, etc.)?
- Who is the target audience? What kind of bbrowsers will they be using? What kind of connection
speeds will they by using? Are they intra- organization (thus with likely high connection speeds and
similar browsers) or Internet-wide (thus with a wide variety of connection speeds and browser types)?
- What kind of performance is expected on thhe client side (e.g., how fast should pages appear, how
fast should animations, applets, etc. load and run)?
- Will down time for server and content mainntenance/upgrades be allowed? how much?
- What kinds of security (firewalls, encrypttions, passwords, etc.) will be required and what is it
expected to do? How can it be tested?
- How reliable are the site's Internet conneections required to be? And how does that affect backup
system or redundant connection requirements and testing?
- What processes will be required to manage updates to the web site's content, and what are the
requirements for maintaining, tracking, and controlling page content, graphics, links, etc.?
- Which HTML specification will be adhered tto? How strictly? What variations will be allowed for
targeted browsers?
- Will there be any standards or requirementts for page appearance and/or graphics throughout a site
or parts of a site??
- How will internal and external links be vaalidated and updated? how often?
- Can testing be done on the production systtem, or will a separate test system be required? How are
browser caching, variations in browser option settings, dial-up connection variabilities, and realworld internet 'traffic congestion' problems to be accounted for in testing?
- How extensive or customized are the serverr logging and reporting requirements; are they
considered an integral part of the system and do they require testing?
- How are cgi programs, applets, javascriptss, ActiveX components, etc. to be maintained, tracked,
controlled, and tested?
- Pages should be 3-5 screens max unless conntent is tightly focused on a single topic. If larger,
provide internal links within the page.
- The page layouts and design elements shoulld be consistent throughout a site, so that it's clear to
the user that they're still within a site.
- Pages should be as browser-independent as possible, or pages should be provided or generated
based on the browser-type.
- All pages should have links external to thhe page; there should be no dead-end pages.
- The page owner, revision date, and a link to a contact person or organization should be included on
each page.
149. How is testing affected by object-oriented designs?
Well-engineered object-oriented design can make it easier to trace from code to internal design to
functional design to requirements. While there will be little affect on black box testing (where an
understanding of the internal design of the application is unnecessary), white-box testing can be
oriented to the application's objects. If the application was well-designed this can simplify test
design.
150. What is Extreme Programming and what's it got to do with testing?
Extreme Programming (XP) is a software development approach for small teams on risk-prone
projects with unstable requirements. It was created by Kent Beck who described the approach in his
book 'Extreme Programming Explained'. Testing ('extreme testing') is a core aspect of Extreme
Programming. Programmers are expected to write unit and functional test code first - before the
application is developed. Test code is under source control along with the rest of the code.
Customers are expected to be an integral part of the project team and to help develope scenarios for
acceptance/black box testing. Acceptance tests are preferably automated, and are modified and
rerun for each of the frequent development iterations. QA and test personnel are also required to be
an integral part of the project team. Detailed requirements documentation is not used, and frequent
re-scheduling, re-estimating, and re-prioritizing is expected.
151. Will automated testing tools make testing easier?
- Possibly. For small projects, the time needed to learn and implement them may not be worth it.
For larger projects, or on-going long-term projects they can be valuable.
- A common type of automated tool is the 'record/playback' type. For example, a tester could click
through all combinations of menu choices, dialog box choices, buttons, etc. in an application GUI and
have them 'recorded' and the results logged by a tool. The 'recording' is typically in the form of text
based on a scripting language that is interpretable by the testing tool. If new buttons are added, or
some underlying code in the application is changed, etc. the application can then be retested by just
'playing back' the 'recorded' actions, and comparing the logging results to check effects of the
changes. The problem with such tools is that if there are continual changes to the system being
tested, the 'recordings' may have to be changed so much that it becomes very time-consuming to
continuously update the scripts. Additionally, interpretation of results (screens, data, logs, etc.) can
be a difficult task. Note that there are record/playback tools for text-based interfaces also, and for
all types of platforms.
- Other automated tools can include:
code analyzers - monitor code complexity, adherence to standards, etc.
coverage analyzers - these tools check which parts of the code have been exercised by a test, and
may be oriented to code statement coverage, condition coverage, path coverage, etc.
memory analyzers - such as bounds-checkers and leak detectors.
load/performance test tools - for testing client/server and web applications under various load
levels.
web test tools - to check that links are valid, HTML code usage is correct, client-side and server-side
programs work, a web site's interactions are secure.
other tools - for test case management, documentation management, bug reporting, and
configuration management.
151. What's the difference between black box and white box testing?
Black-box and white-box are test design methods. Black-box test design treats the system as a
black-box, so it doesn't explicitly use knowledge of the internal structure. Black-box test design is
usually described as focusing on testing functional requirements. Synonyms for black-box include:
behavioral, functional, opaque-box, and closed-box. White-box test design allows one to peek inside
the box, and it focuses specifically on using internal knowledge of the software to guide the
selection of test data. Synonyms for white-box include: structural, glass-box and clear-box.
While black-box and white-box are terms that are still in popular use, many people prefer the terms
'behavioral' and 'structural'. Behavioral test design is slightly different from black-box test design
because the use of internal knowledge isn't strictly forbidden, but it's still discouraged. In practice, it
hasn't proven useful to use a single test design method. One has to use a mixture of different
methods so that they aren't hindered by the limitations of a particular one. Some call this 'gray-box'
or 'translucent-box' test design, but others wish we'd stop talking about boxes altogether.
It is important to understand that these methods are used during the test design phase, and their
influence is hard to see in the tests once they're implemented. Note that any level of testing (unit
testing, system testing, etc.) can use any test design methods. Unit testing is usually associated with
structural test design, but this is because testers usually don't have well-defined requirements at the
unit level to validate.
152. What kinds of testing should be considered?
Black box testing - not based on any knowledge of internal design or code. Tests are based on
requirements and functionality.
White box testing - based on knowledge of the internal logic of an application's code. Tests are based
on coverage of code statements, branches, paths, conditions.
unit testing - the most 'micro' scale of testing; to test particular functions or code modules. Typically
done by the programmer and not by testers, as it requires detailed knowledge of the internal
program design and code. Not always easily done unless the application has a well-designed
architecture with tight code; may require developing test driver modules or test harnesses.
incremental integration testing - continuous testing of an application as new functionality is added;
requires that various aspects of an application's functionality be independent enough to work
separately before all parts of the program are completed, or that test drivers be developed as
needed; done by programmers or by testers.
integration testing - testing of combined parts of an application to determine if they function
together correctly. The 'parts' can be code modules, individual applications, client and server
applications on a network, etc. This type of testing is especially relevant to client/server and
distributed systems. functional testing - black-box type testing geared to functional requirements of
an application; this type of testing should be done by testers. This doesn't mean that the
programmers shouldn't check that their code works before releasing it (which of course applies to any
stage of testing.) system testing - black-box type testing that is based on overall requirements
specifications; covers all combined parts of a system.
end-to-end testing - similar to system testing; the 'macro' end of the test scale; involves testing of a
complete application environment in a situation that mimics real-world use, such as interacting with
a database, using network communications, or interacting with other hardware, applications, or
systems if appropriate.
sanity testing or smoke testing - typically an initial testing effort to determine if a new software
version is performing well enough to accept it for a major testing effort. For example, if the new
software is crashing systems every 5 minutes, bogging down systems to a crawl, or corrupting
databases, the software may not be in a 'sane' enough condition to warrant further testing in its
current state.
regression testing - re-testing after fixes or modifications of the software or its environment. It can
be difficult to determine how much re-testing is needed, especially near the end of the development
cycle. Automated testing tools can be especially useful for this type of testing.
acceptance testing - final testing based on specifications of the end-user or customer, or based on
use by end-users/customers over some limited period of time.
load testing - testing an application under heavy loads, such as testing of a web site under a range of
loads to determine at what point the system's response time degrades or fails.
stress testing - term often used interchangeably with 'load' and 'performance' testing. Also used to
describe such tests as system functional testing while under unusually heavy loads, heavy repetition
of certain actions or inputs, input of large numerical values, large complex queries to a database
system, etc. performance testing - term often used interchangeably with 'stress' and 'load' testing.
Ideally 'performance' testing (and any other 'type' of testing) is defined in requirements
documentation or QA or Test Plans.
usability testing - testing for 'user-friendliness'. Clearly this is subjective, and will depend on the
targeted end-user or customer. User interviews, surveys, video recording of user sessions, and other
techniques can be used. Programmers and testers are usually not appropriate as usability testers.
install/uninstall testing - testing of full, partial, or upgrade install/uninstall processes. recovery
testing - testing how well a system recovers from crashes, hardware failures, or other catastrophic
problems.
failover testing - typically used interchangeably with 'recovery testing'
security testing - testing how well the system protects against unauthorized internal or external
access, willful damage, etc; may require sophisticated testing techniques.
compatability testing - testing how well software performs in a particular
hardware/software/operating system/network/etc. environment.
exploratory testing - often taken to mean a creative, informal software test that is not based on
formal test plans or test cases; testers may be learning the software as they test it. ad-hoc testing similar to exploratory testing, but often taken to mean that the testers have significant
understanding of the software before testing it.
context-driven testing - testing driven by an understanding of the environment, culture, and
intended use of software. For example, the testing approach for life-critical medical equipment
software would be completely different than that for a low-cost computer game.
user acceptance testing - determining if software is satisfactory to an end-user or customer.
comparison testing - comparing software weaknesses and strengths to competing products. alpha
testing - testing of an application when development is nearing completion; minor design changes
may still be made as a result of such testing. Typically done by end-users or others, not by
programmers or testers.
beta testing - testing when development and testing are essentially completed and final bugs and
problems need to be found before final release. Typically done by end-users or others, not by
programmers or testers. mutation testing - a method for determining if a set of test data or test
cases is useful, by deliberately introducing various code changes ('bugs') and retesting with the
original test data/cases to determine if the 'bugs' are detected. Proper implementation requires large
computational resources.
151. Why is it often hard for management to get serious about quality assurance?
Solving problems is a high-visibility process; preventing problems is low-visibility.
This is illustrated by an old parable:
In ancient China there was a family of healers, one of whom was known throughout the land and
employed as a physician to a great lord. The physician was asked which of his family was the most
skillful healer. He replied, "I tend to the sick and dying with drastic and dramatic treatments, and on
occasion someone is cured and my name gets out among the lords." "My elder brother cures sickness
when it just begins to take root, and his skills are known among the local peasants and neighbors."
"My eldest brother is able to sense the spirit of sickness and eradicate it before it takes form. His
name is unknown outside our home."
152. Why does software have bugs?
1. Miscommunication or no communication - as to specifics of what an application should or shouldn't
do (the application's requirements).
2. Software complexity - the complexity of current software applications can be difficult to
comprehend for anyone without experience in modern-day software development. Multi-tiered
applications, client-server and distributed applications, data communications, enormous relational
databases, and sheer size of applications have all contributed to the exponential growth in
software/system complexity. programming errors - programmers, like anyone else, can make
mistakes.
3. Changing requirements (whether documented or undocumented) - the end-user may not
understand the effects of changes, or may understand and request them anyway - redesign,
rescheduling of engineers, effects on other projects, work already completed that may have to be
redone or thrown out, hardware requirements that may be affected, etc. If there are many minor
changes or any major changes, known and unknown dependencies among parts of the project are
likely to interact and cause problems, and the complexity of coordinating changes may result in
errors. Enthusiasm of engineering staff may be affected. In some fast-changing business
environments, continuously modified requirements may be a fact of life. In this case, management
must understand the resulting risks, and QA and test engineers must adapt and plan for continuous
extensive testing to keep the inevitable bugs from running out of control.
3. Poorly documented code - it's tough to maintain and modify code that is badly written or poorly
documented; the result is bugs. In many organizations management provides no incentive for
programmers to document their code or write clear, understandable, maintainable code. In fact, it's
usually the opposite: they get points mostly for quickly turning out code, and there's job security if
nobody else can understand it ('if it was hard to write, it should be hard to read').
4. software development tools - visual tools, class libraries, compilers, scripting tools, etc. often
introduce their own bugs or are poorly documented, resulting in added bugs.
153. How can new Software QA processes be introduced in an existing organization?
A lot depends on the size of the organization and the risks involved. For large organizations with
high-risk (in terms of lives or property) projects, serious management buy-in is required and a
formalized QA process is necessary.
Where the risk is lower, management and organizational buy-in and QA implementation may be a
slower, step-at-a-time process. QA processes should be balanced with productivity so as to keep
bureaucracy from getting out of hand.
For small groups or projects, a more ad-hoc process may be appropriate, depending on the type of
customers and projects. A lot will depend on team leads or managers, feedback to developers, and
ensuring adequate communications among customers, managers, developers, and testers.
The most value for effort will often be in
(a) requirements management processes, with a goal of clear, complete, testable requirement
specifications embodied in requirements or design documentation, or in 'agile'-type environments
extensive continuous coordination with end-users,
(b) design inspections and code inspections, and
(c) post-mortems/retrospectives.
GROUP 1
QUESTIONS
1.
2.
3.
4.
In your own words briefly define what is meant by software verification

Briefly explain the approaches to verification
Explain the experimental test of software verification
Explain integration and functional testing aspect of software verification
SOLUTION
(1)
Software verification is a software engineering practise that is carried out through
the developmental cycle of the software product which is targeted at ensuring that
software produced meet specified requirement and specification defined in the
development document. Some of the needs for software verification are listed below
1.
To ensure that the customers desires as stated in the requirement and

specification document are fully implemented in the software.
2.
To provide a predictable functionality of the software system when
delivered to the customer
For software to fully meet its specification, several defects like faults, errors, bugs, and
failures and other anomalies has to be identified and eliminated. So indirectly software
verification collaborates with (or comprises) other techniques like testing and
debugging to achieve its goals.
Simply put Software verification means developing software in the right way.
The verification of software encompasses correctness, consistency and other attributes
that can show that software has been developed in the right way. During verification
faults, bugs and other defects and anomalies are identified and removed for the
software to conform to its specifications.
(2)
The approaches to software verification are

i.
Dynamic verification
ii.
Static verification
DYNAMIC VERIFICATION: This encompasses testing / experimentation and it is a

verification approach that periodically checks the software being produce, at each
stage of development, with the requirement defined. In Dynamic Verification, there is
every possibility that the behaviour of the system or the deliverables at each stage
doesnt conform to that expected as a result of defects, this need to be identified and
removed.
The following activities are performed in dynamic verification
i.
ii.
iii.
Execution of software system up to the point reached in development

process.
Selection of valid test cases/ input which consist of test data
Examining the output to ensure that it results from the input data
Dynamic verification is target and ensuring that the software system meets it
specifications and requirement by fixing all the bugs and anomalies which may prohibit
this and requesting that the actions needed to fix them are taken.
It encompasses the following testing: unit, module, integration, functional testing e.t.c.
This verification approach has a great advantage in that it can easily identify defects
because it involving the running of part of the whole system.
STATIC VERIFICATION: This is an approach of software verification that ensures that
software product conforms to the specified requirement, as stated in the specification
and requirement document, by performing a physical inspection, work-through and
review of the software system. This could be applied as various stage of the software
development like requirement, design, test data etc,
An advantage of this is that it can be used even before the executable version of the
software is developed. Static verification encompasses what is known as program
proving.
The approaches to static verification are
i.
ii.
iii.
Formal verification
Model checking
Automated static analyser
Formal Verification: This involves the use of strong and rigorous mathematical argument
and constructs to show that software conforms to its specification. We can simply say
that it depends on the use of formal methods to show that software is correct.
Model Checking: This involves the building the model of the system the checking the
models correctness specialised tools. The behaviour of the system could be modelled
through the help of the finite state machine, where all the states and state transition are
identified in the system.
Automatic static Analyser: This approach assumes that there are some common errors
found in different programming language, this could be collected in a list and then an
automated process could then check the program codes against this list of errors. This is
a good approach to easy finding bugs like syntactic errors in programs. But can only
identify those bugs listed.
(3)
Experimental Test of Dynamic verification is simply choosing some valid test cases
(containing test data) as inputs and passing it to the program or software. We then
examine the output to know whether it results out of the input and that it confirms to the
specification in the development document. In other words, it implies showing that the
software product produces valid output which results from the input supplied to it.
VALID INPUT
PROGRAM
VALID OUTPUT
(4)
Integration Testing is a testing process which involves checking that all software
components and modules work in interoperable manner, that is, it checks that modules
really provide the correct interfaces needed for other modules to interoperate with it
and that the right set of data are passed between modules. This is a kind of White Box
Testing because the tester is expected to be knowledgeable in the program code
But functional testing involves identifying and testing all the functionality which the
system is expected to provide, as specified in the specification document, by supplying
valid input cases to the software and examining the output, whether is the expected
not. This kind of testing is BLACK BOX TESTING because the tester is not expected to be
knowledgeable of program code. The tester just passes in
GROUP 2
1. Why is it that software debugging takes 60% - 70% of the overall development time
2. In your own words explain brief five major debugging techniques
Debugging by printing (tracing)
The most common debugging technique is monitoring, in which in applications
programming is done by calling printf at suitable points.
Debugging by querying
The debugging by printing has a disadvantage that massive use of print statements
can slow down the system noticeably. The best way to get relevant information is to
query the system when you need information, instead of continually producing
data.
Debugging by Watching
Sometimes minor problems can be tracked down by watching the behavior of an
application in user space. Watching programs can also help in building confidence
that a driver is working correctly. There are various ways to watch a user-space
program working. You can run a debugger on it to step through its functions, add
print statements, or run the program under trace.
Using the compilers features
A good compiler can do a great deal of static analysis of your code: the analysis of
those aspects of a piece of code that can be studied without executing that code.
Static analysis can help in detecting a number of basic semantic problems such as
type mismatches and dead code.
Remote Debugging
This is the process of debugging a program running on a system different than the
debugger. To start remote debugging, debugger connects to a remote system over
a network. Once connected, debugger can control the execution of the program
on the remote system and retrieve information about its state.
Post-mortem debugging
This is debugging of the program after it has already crashed. Related techniques
often include various tracing techniques, analysis of memory dump (or core dump)
of the crashed process. The dump of the process could be obtained automatically
by the system (for example, when process has terminated due to an unhandled
exception), or by a programmer-inserted instruction, or manually by the interactive
user.
3. Explain how automatic debugging is different from other debugging
One common limitation of manual debugging is their reliance on a set of strong
assumptions on how developers behave when debugging.
Automatic debugging is real time in its approach. They help identify system or
application faults as soon as they stop responding. Here the automatic debugger
creates a crash dump file when the system or application stops responding. The file
can later be examined by the developers.
4. Can we refer users as testers
Yes. User or customer testing is a stage in the testing process in which users or
customers provide input and advice on system testing. Users are involved in Alpha
testing, Beta testing, Acceptance testing.
5. Distinguish between black and white box test
Black box testing is a testing method in which the internal
structure/design/implementation of the item being tested is not known to the tester.
White box testing is a testing method in which the internal structure/ design/
implementation of the item being tested is known to the tester.
Black Box Testing
White Box Testing
Mainly applicable during system testing
Mainly applicable during unit testing,

Acceptance testing, integration testing
Done by software testers
Usually done by developers
Programming knowledge not required
Programming knowledge required
Implementation knowledge not required
Implementation knowledge required
Basis for test requirement specification
Basis for test Detailed Design
6. What are the differences between software debugging, testing and verification
Debugging: The process of debugging involves analyzing and possibly expanding
(with debugging statements) the given program that does not meet the
specification in order to find a new program that is close to the original and does
satisfy the specification. Thus it is the process of diagnosing the precise nature of a
known error and then correcting it
Debugging = diagnosis
Debugging = error finding and fixing
Debugging is done by developers
Debuggers fix the errors
Debugging = done in development phase
Debugging = white box testing
In contrast, given a program, and a set of specification, verification is the process of

proving or demonstrating that the program correctly satisfies the specification.
Verification = functional correctness.
Verification can be done by customers
Whereas verification proves conformance with a specification, testing finds cases
where a program does not meet its specification. Based on this definition, any
activity that exposes the program behavior violating a specification can be called
testing.
Testing = trying to break the program
Testing is done by testers
Testers dont fix problems but return it to programmers for fixing.
Testing is done in the testing phase
Testing = black box testing
Testing does not show the absence of error but the presence
Testing does not include efforts associated with tracking down bugs and fixing them
Testing doesnt ensure quality
7. If symbolic execution could not handle non-linear problems what method do we
use
We could formal methods like the Hoare Triple.
8. Differentiate among various debugging execution types
Forward Symbolic Execution: This begins execution at the start of main
Shortest-distance Symbolic Execution(SDSE): This priorities the path with the
shortest distance to the target line as computed over an inter-procedural
control flow graph
Call-chain backward Symbolic Execution(CCBSE): this will start at the target line
and work backward until it finds a realizable path from the start of the program,
using standard forward (inter-procedural ) symbolic execution as a subroutine
Mixed-strategy call-chain backward (mixed CCBSE) Symbolic execution: this
combines CCBSE with another forward search. Here we alter CCBSE with some
forward search strategy S.
GROUP 3
1. What do you mean by quality of conformance?
Quality of conformance is the degree to which the design specifications are
followed during production. The greater the degree of conformance, the higher is
the level of quality of conformance.
2. What are the components of quality of design?
Requirements
Quality of Design Encompasses:
Specifications
Design of the System
Side note: Quality of design refers to the characteristics that designers specify for
an item. The grade of materials, tolerances, and performance specifications all
contribute to the quality of design. As higher-grade materials are used, tighter
tolerances and greater levels of performance are specified, the design quality of
a product increases, if the product is manufactured according to specifications.
3. What are the components of user satisfaction?
User Satisfaction = Compliant Product + Good Quality + Delivered within
Budget and Schedule
4. *Define a Mathematical Proof of Correctness for Software Quality Assurance
Skipped
5. What is the Significance of Software Review?
Software reviews are a "filter" for the software engineering process. That is, reviews
are applied at various points during software development and serve to uncover
errors and defects that can then be removed. Software reviews "purify" the software
engineering activities that we have called analysis, design, and coding.
6. State the Measures of Reliability and Availability
A simple measure of reliability is meantime-between-failure (MTBF), where:
MTBF = MTTF + MTTR
The acronyms MTTF and MTTR are mean-time-to-failure and mean-time-to-repair,

respectively.
In addition to a reliability measure, we must develop a measure of availability.
Software availability is the probability that a program is operating according to
requirements at a given point in time and is defined as:
Availability = [MTTF/ (MTTF + MTTR)] 100%
Group 4
1. Failure intensity is the failure occurring with respect to time and it is the
alternative way of expressing software reliability.
2.
3. A failure corresponds to unexpected runtime behavior observed by a user of the

software. A fault is a static software characteristic which causes a failure to
occur.
4. Whenever we want to predict software reliability, we need to choose the best

growth model for the system under consideration since several exist. Some
common models are Musa Basic Model, Musa-Okumoto Model, JelsinskyMoranda Model, Littlewood Verrall Model, and Rayleigh Model.
After selecting the appropriate model, one need to then take into consideration
the various assumptions under the selected model. After that, we can start
observing systems behavior in order to get parameters in selected models. We
then use these parameters to calculate failure intensity () and mean time to
failure (MTTF). We can then draw conclusion on the expected system reliability
from the value of and MTTF. The model that uses equation to determine values
before predicting reliability is estimation while the one that often uses graphs is
prediction. In conclusion no onereliability model is superior to the other since
each has its strength and weakness.
GROUP 5
Group 5 Questions AND Answers
1. What are the conditions that can lead to project initiation?
ANSWER: Project initiation can emanate from these three key sources such as:
a) Managers and business units who want to replace or extend an existing
system in order to gain needed information or to provide a new service to
customers.
b) Information systems managers who want to make a system more efficient,
less costly to operate, or want to move a system to a new operating
environment.
c) Formal planning groups that want to improve an existing system in order to
help the organization meet its corporate objectives, such as providing better
customer service
2. Explain in brief the various Project Attributes
ANSWER: Projects come in all shapes and sizes. The following attributes help us to define
a project further:
a) A project has a unique purpose. Every project should have a well-defined
objective. For example, many people hire firms to design and build a new
house, but each house, like each person, is unique.
b) A project is temporary. A project has a definite beginning and a definite
end. For a home construction project, owners usually have a date in mind
when theyd like to move into their new homes.
c) A project is developed using progressive elaboration or in an iterative fashion.
d) A project requires resources, often from various areas. Resources include
people, hardware, software or other assets.
e) A project should have a primary customer or sponsor. Most projects have
many interested parties or stakeholders, but someone must take the
primary role of sponsorship. The project sponsor usually provides the
direction and funding for the project.
f) Projects are often defined broadly when they begin, and as time passes, the
specific details of the project become clearer.
3. Enumerate the constraint under which projects need to be performed and
delivered
ANSWER: Projects are performed and delivered under certain constraints, which are
scope, time and cost. The time constraint refers to amount of time available to
complete a project. The cost constraint refers to the budgeted amount available for
the project. The scope constraint refers to what must be done to produce the project's
end result. These three constraints are often competing constraints: increased scope
typically means increased time and increased cost, a tight time constraint could mean
increased costs and reduced scope, and a tight budget could mean increased time
and reduced scope.
4. Distinguish between GANTT and PERT .

ANSWER:
1. GANTT chart visually shows the duration of Tasks whereas a PERT chart visually
shows the sequence dependencies between tasks.
2. GANTT visually shows the Time overlap of Tasks whereas a Network does not show
time overlap but does show which tasks could be done in parallel.
3. Some form of GANTT chart can visually show Slack Time available within an
Earliest Start and Latest finish time.
4. Most Project Managers find PERT very helpful for scheduling, monitoring and
controlling Projects.
5. PERT is recommended for Large Projects with high inter-task dependencies and
the GANTT chart for simpler Projects.
Group 6
1. Why is software maintenance the most costly aspect of software development life
cycle :
The maintenance phase of the software development life cycle is often the longest
and the most expensive. After the software product has been released, the
maintenance phase keeps the software up to date with environment changes and
changing user requirements, also defects and bugs are fixed during this phase. It
continues throughout the lifespan of the software application to ensure the value of
the application is preserved over time.
2. Describe the three main causes of corrective maintenance:
The 3 main causes of corrective maintenance are as follows:
a. Design errors: these occur when changes made to the software are incorrect,
incomplete, wrongly communicated or the change request is misunderstood.
b. Logic errors: these result from invalid tests and conclusions, incorrect
implementation of design specifications, faulty logic flow or incomplete test of
data.
c. Coding errors: these are caused by incorrect implementation of detailed logic
design and incorrect use of the source code logic
3. Explain in brief software maintenance process
Software Maintenance process is made up of the following phases:
a. Problem/modification identification, classification, and prioritization: In this
phase, software modifications are identified, classified, and assigned an initial
priority ranking.
b. Analysis: In this phase the repository information and the modification request
validated in the previous phase, along with system and project documentation
are used to study the feasibility and scope of the modification and preliminary
plan for design, implementation, test, and delivery are devised.
c. Design: In this phase, all current system and project documentation, existing
software and databases, and the output of the analysis phase are used to
design the modification to the system.
d. Implementation: In this phase, the results of the design phase, the current source
code, and project and system documentation (i.e., the entire system as
updated by the analysis and design phases) are used to drive the
implementation effort.
e. System testing: In this phase, system testing e.g. regression testing is performed
on the modified system to validate that the modified code does not introduce
faults that did not exist prior to the maintenance activity.
f. Acceptance testing: In this phase, acceptance tests are conducted on a fully
integrated system either by the customer, the user of the modification package,
or a third party designated by the customer.
g. Delivery: This sub-clause describes the requirements for the delivery of a modified
software system.
4. Software maintenance tools
Software Maintenance tools can be defined as anything functional that can assist
the software maintainer in addressing maintenance problems. CASE (ComputerAided Software Engineering) tools are used in the phases of software development
life cycle, while CAME (Computer. Assisted Software Measurement and Evaluation)
tools are used for code analysis and measurement. E.g. VIFOR 2, xVue, RETIRE, VIFOR
2.
5. Software maintenance problems:
The major problems associated with software maintenance include:
the need for more effective software maintenance tools
a lack of software documentation,
the low status of maintainers,
and software designed without maintenance in view
(Note: these problems are discussed fully in the documentation if you want further
details pls check the doc.).
6. How is P-type different from evolutionary system :
P-type systems, or practical-type systems, are those that can be described formally,
but whose solutions are not immediately apparent. Such systems are not subject to
evolution since their solutions are usually consistent with a given paradigm. Hence,
they do not change with changing user requirements. On the other hand,
evolutionary systems are systems that serve to model real-world processes, and
through their use, become a component of the world in which they intend to
model. They are subject changing user requirements as a result of their nature.
7. Describe maintenance types
a. Corrective Maintenance: this involves changing a software application to
remove errors. Examples of errors corrected in this phase include design errors,
logic errors, coding errors and defects.
b. Adaptive Maintenance: this is any maintenance effort that is carried out as a
result of changes in a software applications operating environment. Such
changes may include Rules, laws, and regulations that affect the application,
Hardware configurations, File structures and data formats etc
c. Perfective maintenance: Perfective maintenance is software maintenance
implemented to improve the maintainability of software. It mainly deals with
accommodating new or changed user requirements, functional enhancements
to the system and activities to increase the systems performance.
d. Preventive maintenance: is defined as maintenance performed for the purpose
of preventing problems before they happen.
GROUP 7
INTERNAL REUSE
Use of company or self-built components
EXTERNAL REUSE
Usage of components built by an
external/3rd part firm
Cannot result in litigation from licensing

issues
Many software litigation claims are due to

improper license before usage of 3rd part
components
Less time is spent in understanding the

components as it is built by the firm itself
Considerable time is spent in understanding

the component and reading its
documentation
Considerable amount of paperwork and
licensing is needed before permissions for
modification can be granted. (most time
such permissions are never granted)
Freely customizable as it is built by the firm,

it can be reshaped as pleased
No cost is incurred(free)
Can be free or expensive but when used

for commercial purposes they can get
quite expensive
2. Merits and Demerits of Forked Reuse

MERITS:
Easier and more direct approach

Does not require full knowledge of the source except for the excerpt or snippet
being used
Isolated from the source hence more greater flexibility to change the reused
code; as source will not be affected by modifications
Easier packaging, deployment and version management.
DEMERITS
Code duplication
Every bug corrected in one copy will not be corrected in others (because they
are disjointed) or else they become out of date.
3 i) METRIC BASED MODELS:

This measures the amount or size of reuse by viewing reuse from a metric standpoint
reuse hence can be measured in terms of LOC (Lines of code).
ii)ECONOMIC MODELS:
This measures reuse from an economic standpoint. The Impact of reuse is measured
relative to the effort required to develop from all-new code. It can help organizations to
estimate the trade-off btw proportion of reuse and the cost of developing and reusing
components. Economic models show methods of improving cost-effectiveness of reuse
based on the metric introduced e.g cost and benefits of reuse, the number of projects
necessary for reuse to pay off can be calculated.
4. Just Explain OOP
5. overloading of Methods: Declaration of methods or functions with name that is same
as an existing method but different signature as the already existing methods.
GROUP 8
1. Differences between Reverse and Forward Engineering
The most traditional method of the development of a technology is referred to as
forward engineering. In the construction of a technology, manufacturers develop a
product by implementing engineering concepts and abstractions.
By contrast, reverse engineering begins with final product, and works backward to
recreate the engineering concepts by analysing the design of the system and the
interrelationships of its components.

Software Testing All Questions and Answers PDF

Diunggah oleh

Informasi Dokumen

Judul Asli

Hak Cipta

Format Tersedia

Bagikan dokumen Ini

Bagikan atau Tanam Dokumen

Opsi Berbagi

Apakah menurut Anda dokumen ini bermanfaat?

Apakah konten ini tidak pantas?

Hak Cipta:

Format Tersedia

Software Testing All Questions and Answers PDF

Diunggah oleh

Hak Cipta:

Format Tersedia

Software Testing FAQ

What is quality assurance?

Identification of software including version/release numbers

Revision history of document including authors, dates, approvals

Purpose of document, intended audience

Objective of testing effort

Software product overview

Relevant related document list, such as requirements, design documents,

Relevant standards or legal requirements

Trace ability requirements

Relevant naming conventions and identifier conventions

Test organization and personnel/contact-info/responsibilities

Assumptions and dependencies

Project risk analysis

Testing priorities and focus

Test outline - a decomposition of the test approach by test type, feature,

Outline of data input equivalence classes, boundary value analysis, error

Test environment - hardware, operating systems, other required

Test environment validity analysis - differences between the test and

Test environment setup and configuration issues

Software migration processes

Test data setup requirements

Database setup requirements

Outline of system-logging/error-logging/other capabilities, and tools

Discussion of any specialized software or hardware tools that will be used by

Test automation - justification and overview

Test tools to be used, including versions, patches, etc.

Test script/test code maintenance processes and version control

Problem tracking and resolution - tools and processes

Project test metrics to be used

Reporting requirements and testing deliverables

Software entrance and exit criteria

Initial sanity testing period and criteria

Test suspension and restart criteria

Personnel pre-training needs

Outside test organizations to be utilized and their purpose, responsibilties,

Relevant proprietary, classified, security, and licensing issues.

Appendix - glossary, acronyms, etc.

Why is test plan a controlled document?

What information you need to formulate test plan?

Developers (If accessible)

Previous Version documentation (if any)

Stake holders (If accessible)

What is the difference between regression automation tool and performance

What is user acceptance testing?

What is smoke testing?

Current bug status (e.g., 'Released for Retest', 'New', etc.)

The application name or identifier and version

Environment specifics, system, platform, relevant hardware specifics

Test case name/number/identifier

One-line bug description

Full bug description

Description of steps needed to reproduce the bug if not covered by a test

Names and/or descriptions of file/data/messages/etc. used in test

File excerpts/error messages/log file excerpts/screen shots/test tool logs

Severity estimate (a 5-level range such as 1-5 or 'critical'-to-'low' is

Was the bug reproducible?

Bug reporting date

Name of developer/group/organization the problem is assigned to

Description of problem cause

Code section/file/module/class/method that was fixed

Application version that contains the fix

Tester responsible for retest