Question Bank - 2

NOTE: Only one answer per question
1-When what is visible to end-users is a deviation from the specific or expected behavior, this is called:
a) - An error
b) - A fault
c) - A failure
d) - A defect
e) - A mistake

2-Regression testing should be performed:
v) - Every week
w) - After the software has changed
x) - As often as possible
y) - When the environment has changed
z) - When the project manager says

a) - v & w are true, x – z are false
b) - w, x & y are true, v & z are false
c) - w & y are true, v, x & z are false
d) - w is true, v, x y and z are false
e) - All of the above are true

3-IEEE 829 test plan documentation standard contains all of the following except:
a) - Test items
b) - Test deliverables
c) - Test tasks
d) - Test environment
e) - Test specification

4-Testing should be stopped when:
a) - All the planned tests have been run
b) - Time has run out
c) - All faults have been fixed correctly
d) - Both a) and c)
e) - It depends on the risks for the system being tested

5-Order numbers on a stock control system can range between 10000 and 99999 inclusive. Which of the following inputs might be a result of designing tests for only valid equivalence classes and valid boundaries:
a) - 1000, 5000, 99999
b) - 9999, 50000, 100000
c) - 10000, 50000, 9999
d) - 10000, 99999
e) - 9999, 10000, 50000, 99999, 10000

6-Consider the following statements about early test design:
i. Early test design can prevent fault multiplication
ii. Faults found during early test design are more expensive to fix
iii. Early test design can find faults
iv. Early test design can cause changes to the requirements
v. Early test design takes more effort

a) - i, iii & iv are true. Ii & v are false
b) - iii is true, I, ii, iv & v are false
c) - iii & iv are true. i, ii & v are false
d) - i, iii, iv & v are true, ii us false
e) - i & iii are true, ii, iv & v are false

7-Non-functional system testing includes:
a) - Testing to see where the system does not function properly
b) - Testing quality attributes of the system including performance and usability
c) - Testing a system feature using only the software required for that action
d) - Testing a system feature using only the software required for that function
e) - Testing for functions that should not exist

8-Which of the following is NOT part of configuration management:
a) - Status accounting of configuration items
b) - Auditing conformance to ISO9001
c) - Identification of test versions
d) - Record of changes to documentation over time
e) - Controlled library access

9-Which of the following is the main purpose of the integration strategy for integration testing in the small?
a) - To ensure that all of the small modules are tested adequately
b) - To ensure that the system interfaces to other systems and networks
c) - To specify which modules to combine when and how many at once
d) - To ensure that the integration testing can be performed by a small team
e) - To specify how the software should be divided into modules

10-What is the purpose of test completion criteria in a test plan:
a) - To know when a specific test has finished its execution
b) - To ensure that the test case specification is complete
c) - To set the criteria used in generating test inputs
d) - To know when test planning is complete
e) – To plan when to stop testing

11-Consider the following statements
i. An incident may be closed without being fixed
ii. Incidents may not be raised against documentation
iii. The final stage of incident tracking is fixing
iv. The incident record does not include information on test environments
v. Incidents should be raised when someone other than the author of the software performs the test

a) - ii and v are true, I, iii and iv are false
b) - i and v are true, ii, iii and iv are false
c) - i, iv and v are true, ii and iii are false
d) - i and ii are true, iii, iv and v are false
e) - i is true, ii, iii, iv and v are false

12-Given the following code, which is true about the minimum number of test cases required for full statement and branch coverage:
Read P
Read Q
IF P+Q > 100 THEN
Print “Large”
ENDIF
If P > 50 THEN
Print “P Large”
ENDIF

a) - 1 test for statement coverage, 3 for branch coverage
b) - 1 test for statement coverage, 2 for branch coverage
c) - 1 test for statement coverage, 1 for branch coverage
d) - 2 tests for statement coverage, 3 for branch coverage
e) - 2 tests for statement coverage, 2 for branch coverage

13-Given the following:
Switch PC on
Start “outlook”
IF outlook appears THEN
Send an email
Close outlook

a) - 1 test for statement coverage, 1 for branch coverage
b) - 1 test for statement coverage, 2 for branch coverage
c) - 1 test for statement coverage. 3 for branch coverage
d) - 2 tests for statement coverage, 2 for branch coverage
e) - 2 tests for statement coverage, 3 for branch coverage

14-Given the following code, which is true:
IF A > B THEN
C = A – B
ELSE
C = A + B
ENDIF
Read D
IF C = D Then
Print “Error”
ENDIF

a) - 1 test for statement coverage, 3 for branch coverage
b) - 2 tests for statement coverage, 2 for branch coverage
c) - 2 tests for statement coverage. 3 for branch coverage
d) - 3 tests for statement coverage, 3 for branch coverage
e) - 3 tests for statement coverage, 2 for branch coverage

15-Consider the following:
Pick up and read the newspaper
Look at what is on television
If there is a program that you are interested in watching then switch the the television on and watch the program
Otherwise
Continue reading the newspaper
If there is a crossword in the newspaper then try and complete the crossword

a) - SC = 1 and DC = 1
b) - SC = 1 and DC = 2
c) - SC = 1 and DC = 3
d) - SC = 2 and DC = 2
e) - SC = 2 and DC = 3

16-The place to start if you want a (new) test tool is:
a) - Attend a tool exhibition
b) - Invite a vendor to give a demo
c) - Analyze your needs and requirements
d) - Find out what your budget would be for the tool
e) - Search the internet

17-When a new testing tool is purchased, it should be used first by:
a) - A small team to establish the best way to use the tool
b) - Everyone who may eventually have some use for the tool
c) - The independent testing team
d) - The managers to see what projects it should be used in
e) - The vendor contractor to write the initial scripts

18-What can static analysis NOT find?
a) - The use of a variable before it has been defined
b) - Unreachable (“dead”) code
c) - Whether the value stored in a variable is correct
d) - The re-definition of a variable before it has been used
e) - Array bound violations

19-Which of the following is NOT a black box technique:
a) - Equivalence partitioning
b) - State transition testing
c) - LCSAJ
d) - Syntax testing
e) - Boundary value analysis

20-Beta testing is:
a) - Performed by customers at their own site
b) - Performed by customers at their software developer’s site
c) - Performed by an independent test team
d) - Useful to test bespoke software
e) - Performed as early as possible in the lifecycle

21-Given the following types of tool, which tools would typically be used by developers and which by an independent test team:
i. Static analysis
ii. Performance Testing
iii. Test Management
iv. Dynamic Analysis
v. Test Running
vi. Test Data Preparation

a) - Developers would typically use i, iv and vi; test team ii, iii and v
b) - Developers would typically use i and iv; test team ii, iii, v and vi
c) - Developers would typically use i, ii, iii and iv; test team v and vi
d) - Developers would typically use ii, iv and vi; test team I, ii and v
e) - Developers would typically use i, iii, iv and v; test team ii and vi

22- The main focus of acceptance testing is:
a) - Finding faults in the system
b) - Ensuring that the system is acceptable to all users
c) - Testing the system with other systems
d) - Testing for a business perspective
e) - Testing by an independent test team

23-Which of the following statements about the component testing standard is false:
a) - Black box design techniques all have an associated measurement technique
b) - White box design techniques all have an associated measurement technique
c) - Cyclomatic complexity is not a test measurement technique
d) - Black box measurement techniques all have an associated test design technique
e) - White box measurement techniques all have an associated test design technique

24-Which of the following statements is NOT true:
a) - Inspection is the most formal review process
b) - Inspections should be led by a trained leader
c) - Managers can perform inspections on management documents
d) - Inspection is appropriate even when there are no written documents
e) - Inspection compares documents with predecessor (source) documents

25-A typical commercial test execution tool would be able to perform all of the following EXCEPT:
a) - Generating expected outputs
b) - Replaying inputs according to a programmed script
c) - Comparison of expected outcomes with actual outcomes
d) - Recording test inputs
e) - Reading test values from a data file

26-The difference between re-testing and regression testing is
a) - Re-testing is running a test again; regression testing looks for unexpected side effects
b) - Re-testing looks for unexpected side effects; regression testing is repeating those tests
c) - Re-testing is done after faults are fixed; regression testing is done earlier
d) - Re-testing uses different environments, regression testing uses the same environment
e) - Re-testing is done by developers, regression testing is done by independent testers

27-Expected results are:
a) - Only important in system testing
b) - Only used in component testing
c) - Never specified in advance
d) - Most useful when specified in advance
e) - Derived from the code

28-Test managers should not:
a) - Report on deviations from the project plan
b) - Sign the system off for release
c) - Re-allocate resource to meet original plans
d) - Raise incidents on faults that they have found
e) - Provide information for risk analysis and quality improvement

29-Unreachable code would best be found using:
a) - Code reviews
b) - Code inspections
c) - A coverage tool
d) - A test management tool
e) - A static analysis tool

30-A tool that supports traceability, recording of incidents or scheduling of tests is called:
a) - A dynamic analysis tool
b) - A test execution tool
c) - A debugging tool
d) - A test management tool
e) – A configuration management tool

31-What information need not be included in a test incident report:
a) - How to fix the fault
b) - How to reproduce the fault
c) - Test environment details
d) - Severity, priority
e) - The actual and expected outcomes

32-Which expression best matches the following characteristics or review processes:
1. Led by author
2. Undocumented
3. No management participation
4. Led by a trained moderator or leader
5. Uses entry exit criteria

s) - Inspection
t) - Peer review
u) - Informal review
v) - Walkthrough

a) - s = 4, t = 3, u = 2 and 5, v = 1
b) - s = 4 and 5, t = 3, u = 2, v = 1
c) - s = 1 and 5, t = 3, u = 2, v = 4
d) - s = 5, t = 4, u = 3, v = 1 and 2
e) - s = 4 and 5, t = 1, u = 2, v = 3

33-Which of the following is NOT part of system testing:
a) - Business process-based testing
b) - Performance, load and stress testing
c) - Requirements-based testing
d) - Usability testing
e) - Top-down integration testing

34- What statement about expected outcomes is FALSE:
a) - Expected outcomes are defined by the software’s behaviour
b) - Expected outcomes are derived from a specification, not from the code
c) - Expected outcomes include outputs to a screen and changes to files and databases
d) - Expected outcomes should be predicted before a test is run
e) - Expected outcomes may include timing constraints such as response times

35-The standard that gives definitions of testing terms is:
a) - ISO/IEC 12207
b) - BS7925-1
c) - BS7925-2
d) - ANSI/IEEE 829
e) - ANSI/IEEE 729

36-The cost of fixing a fault:
a) - Is not important
b) - Increases as we move the product towards live use
c) - Decreases as we move the product towards live use
d) - Is more expensive if found in requirements than functional design
e) - Can never be determined

37-Which of the following is NOT included in the Test Plan document of the Test Documentation Standard:
a) - Test items (i.e. software versions)
b) - What is not to be tested
c) - Test environments
d) - Quality plans
e) - Schedules and deadlines

38-Could reviews or inspections be considered part of testing:
a) - No, because they apply to development documentation
b) - No, because they are normally applied before testing
c) - No, because they do not apply to the test documentation
d) - Yes, because both help detect faults and improve quality
e) - Yes, because testing includes all non-constructive activities

39-Which of the following is not part of performance testing:
a) - Measuring response time
b) - Measuring transaction rates
c) - Recovery testing
d) - Simulating many users
e) - Generating many transactions

40-Error guessing is best used
a) - As the first approach to deriving test cases
b) - After more formal techniques have been applied
c) - By inexperienced testers
d) - After the system has gone live
e) - Only by end users

Answers - Question Bank -2

Requirements Analysis Process

Requirements Analysis Process: Requirements Elicitation, Analysis And Specification

Requirements Analysis is the process of understanding the customer needs and expectations from a proposed system or application and is a well-defined stage in the Software Development Life Cycle model.

Requirements are a description of how a system should behave or a description of system properties or attributes. It can alternatively be a statement of ‘what’ an application is expected to do.

Given the multiple levels of interaction between users, business processes and devices in global corporations today, there are simultaneous and complex requirements from a single application, from various levels within an organization and outside it as well.

The Software Requirements Analysis Process covers the complex task of eliciting and documenting the requirements of all these users, modeling and analyzing these requirements and documenting them as a basis for system design.

A dedicated and specialized Requirements Analyst is best equipped to handle the job. The Requirements Analysis function may also fall under the scope of Project Manager, Program Manager or Business Analyst, depending on the organizational hierarchy.

Software Requirements Analysis and Documentation Processes are critical to software project success. Requirements Engineering is an emerging field which deals with the systematic handling of requirements.

Why is Requirements Analysis necessary?

Studies reveal that inadequate attention to Software Requirements Analysis at the beginning of a project is the most common cause for critically vulnerable projects that often do not deliver even on the basic tasks for which they were designed. There are instances of corporations that have spent huge amounts on software projects where the end application eventually does not perform the tasks it was intended for.

Software companies are now investing time and resources into effective and streamlined Software Requirements Analysis Processes as a prerequisite to successful projects that align with the client’s business goals and meet the project’s requirement specifications.

Steps in the Requirements Analysis Process

I. Fix system boundaries

This initial step helps in identifying how the new application integrates with the business processes, how it fits into the larger picture and what its scope and limitations will be.

II. Identify the customer

In more recent times there has been a focus on identifying who the ‘users’ or ‘customers’ of an application are. Referred to broadly as the ‘stake holders’, these indicate the group or groups of people who will be directly or indirectly impacted by the new application.

By defining in concrete terms who the intended user is, the Requirements Analyst knows in advance where he has to look for answers. The Requirements Elicitation Process should focus on the wish-list of this defined group to arrive at a valid requirements list.

III. Requirements elicitation

Information is gathered from the multiple stakeholders identified. The Requirements Analyst draws out from each of these groups what their requirements from the application are and what they expect the application to accomplish.

Considering the multiple stakeholders involved, the list of requirements gathered in this manner could run into pages. The level of detail of the requirements list is based on the number and size of user groups, the degree of complexity of business processes and the size of the application.

a) Problems faced in Requirements Elicitation

• Ambiguous understanding of processes

• Inconsistency within a single process by multiple users

• Insufficient input from stakeholders

• Conflicting stakeholder interests

• Changes in requirements after project has begun

A Requirements Analyst has to interact closely with multiple work-groups, often with conflicting goals, to arrive at a bona fide requirements list. Strong communication and people skills along with sound programming knowledge are prerequisites for an expert Requirements Analyst.

b) Tools used in Requirements Elicitation

Traditional methods of Requirements Elicitation included stakeholder interviews and focus group studies. Other methods like flowcharting of business processes and the use of existing documentation like user manuals, organizational charts, process models and systems or process specifications, on-site analysis, interviews with end-users, market research and competitor analysis were also used extensively in Requirements Elicitation.

However current research in Software Requirements Analysis Process has thrown up modern tools that are better equipped to handle the complex and multilayered process of Requirements Elicitation. Some of the current Requirements Elicitation tools in use are:

• Prototypes

• Use cases

• Data flow diagrams

• Transition process diagrams

• User interfaces

IV. Requirements Analysis Process

Once all stakeholder requirements have been gathered, a structured analysis of these can be done after modeling the requirements. Some of the Software Requirements Analysis techniques used are requirements animation, automated reasoning, knowledge-based critiquing, consistency checking, analogical and case-based reasoning.

V. Requirements Specification

Requirements, once elicited, modeled and analyzed should be documented in clear, unambiguous terms. A written requirements document is critical so that its circulation is possible among all stakeholders including the client, user-groups, the development and testing teams. Current requirements engineering practices reveal that a well-designed, clearly documented Requirements Specification is vital and serves as a:

• Base for validating the stated requirements and resolving stakeholder conflicts, if any

• Contract between the client and development team

• Basis for systems design for the development team

• Bench-mark for project managers for planning project development lifecycle and goals

• Source for formulating test plans for QA and testing teams

• Resource for requirements management and requirements tracing

• Basis for evolving requirements over the project life span

Software requirements specification involves scoping the requirements so that it meets the customer’s vision. It is the result of collaboration between the end-user who is often not a technical expert, and a Technical/Systems Analyst, who is likely to approach the situation in technical terms.

The software requirements specification is a document that lists out stakeholders’ needs and communicates these to the technical community that will design and build the system. The challenge of a well-written requirements specification is to clearly communicate to both these groups and all the sub-groups within.

To overcome this, Requirements Specifications may be documented separately as

• User Requirements - written in clear, precise language with plain text and use cases, for the benefit of the customer and end-user

• System Requirements - expressed as a programming or mathematical model, addressing the Application Development Team and QA and Testing Team.

Requirements Specification serves as a starting point for software, hardware and database design. It describes the function (Functional and Non-Functional specifications) of the system, performance of the system and the operational and user-interface constraints that will govern system development.

VI. Requirements Management

Requirements Management is the comprehensive process that includes all aspects of software requirements analysis and additionally ensures verification, validation and traceability of requirements. Effective requirements management practices guarantee that all system requirements are stated unambiguously, that omissions and errors are corrected and that evolving specifications can be incorporated later in the project lifecycle.