Documentation and Strategy and Key QA Documents

Documentation and Strategy

This is a quick reference guide to the Quality Assurance process. It explains at a high level the key documents QA must receive or prepare during the course of a project cycle to adequately assess the readiness of a product for release. Although the level of detail in each document may vary by team and project, each is mandatory

Key QA Documents

1. PRAD

The Product Requirement Analysis Document is the document prepared/reviewed by marketing, sales, and technical product managers. This document defines the requirements for the product, the "What". It is used by the developer to build his/her functional specification and used by QA as a reference for the first draft of the Test Strategy.

2. Functional Specification

The functional specification is the "How" of the product. The functional specification identifies how new features will be implemented. This document includes items such as what database tables a particular search will query. This document is critical to QA because it is used to build the Test Plan.

QA is often involved in reviewing the functional specification for clarity and helping to define the business rules.

3. Test Strategy

The Test Strategy is the first document QA should prepare for any project. This is a living document that should be maintained/updated throughout the project. The first draft should be completed upon approval of the PRAD and sent to the developer and technical product manager for review.

The Test Strategy is a high-level document that details the approach QA will follow in testing the given product. This document can vary based on the project, but all strategies should include the following criteria:
· Project Overview - What is the project.

· Project Scope - What are the core components of the product to be tested

· Testing - This section defines the test methodology to be used, the types of testing to be executed (GUI, Functional, etc.), how testing will be prioritized, testing that will and will not be done and the associated risks. This section should also outline the system configurations that will be tested and the tester assignments for the project.

· Completion Criteria - These are the objective criteria upon which the team will decide the product is ready for release

· Schedule - This should define the schedule for the project and include completion dates for the PRAD, Functional Spec, and Test Strategy etc. The schedule section should include build delivery dates, release dates and the dates for the Readiness Review, QA Process Review, and Release Board Meetings.

· Materials Consulted - Identify the documents used to prepare the test strategy

4. Test Matrix (Test Plan)

The Test Matrix is the Excel template that identifies the test types (GUI, Functional etc.), the test suites within each type, and the test categories to be tested. This matrix also prioritizes test categories and provides reporting on test coverage.
· Test Summary report
· Test Suite Risk Coverage report

Upon completion of the functional specification and test strategy, QA begins building the master test matrix. This is a living document and can change over the course of the project as testers create new test categories or remove non-relevant areas. Ideally, a master matrix need only be adjusted to include near feature areas or enhancements from release to release on a given product line.

5. Test Cases

As testers build the Master Matrix, they also build their individual test cases. These are the specific functions testers must verify within each test category to qualify the feature. A test case is identified by ID number and prioritized. Each test case has the following criteria:
· Purpose - Reason for the test case
· Steps - A logical sequence of steps the tester must follow to execute the test case
· Expected Results - The expected result of the test case
· Actual Result - What actually happened when the test case was executed
· Status - Identifies whether the test case was passed, failed, blocked or skipped.
· Pass - Actual result matched expected result
· Failed - Bug discovered that represents a failure of the feature
· Blocked - Tester could not execute the test case because of bug
· Skipped - Test case was not executed this round
· Bug ID - If the test case was failed, identify the bug number of the resulting bug.

6. Test Results by Build

Once QA begins testing, it is incumbent upon them to provide results on a consistent basis to developers and the technical product manager. This is done in two ways: A completed Test Matrix for each build and a Results Summary document.

For each test cycle, testers should fill in a copy of the project's Master Matrix. This will create the associated Test Coverage reports automatically (Test Coverage by Type and Test Coverage by Risk/Priority). This should be posted in a place that necessary individuals can access the information.
Since the full Matrix is large and not easily read, it is also recommended that you create a short Results Summary that highlights key information. A Results Summary should include the following:
· Build Number
· Database Version Number
· Install Paths (If applicable)
· Testers
· Scheduled Build Delivery Date
· Actual Build Delivery Date
· Test Start Date
· Scope - What type of testing was planned for this build? For example, was it a partial build? A full-regression build? Scope should identify areas tested and areas not tested.
· Issues - This section should identify any problems that hampered testing, represent a trend toward a specific problem area, or are causing the project to slip. For example, in this section you would note if the build was delivered late and why and what its impact was on testing.
· Statistics - In this section, you can note things such as number of bugs found during the cycle, number of bugs closed during the cycle etc.

7. Release Package

The Release Package is the final document QA prepares. This is the compilation of all previous documents and a release recommendation. Each release package will vary by team and project, but they should all include the following information:

· Project Overview - This is a synopsis of the project, its scope, any problems encountered during the testing cycle and QA's recommendation to release or not release. The overview should be a "response" to the test strategy and note areas where the strategy was successful, areas where the strategy had to be revised etc.

The project overview is also the place for QA to call out any suggestions for process improvements in the next project cycle.

Think of the Test Strategy and the Project Overview as "Project bookends".

· Project PRAD - This is the Product Requirements Analysis Document, which defines what functionality was approved for inclusion in the project. If there was no PRAD for the project, it should be clearly noted in the Project Overview. The consequences of an absent PRAD should also be noted.

· Functional Specification - The document that defines how functionality will be implemented. If there was no functional specification, it should be clearly noted in the Project Overview. The consequences of an absent Functional Specification should also be noted.

· Test Strategy - The document outlining QA's process for testing the application.

· Results Summaries - The results summaries identify the results of each round of testing. These should be accompanied in the Release Package by the corresponding reports for Test Coverage by Test Type and Test Coverage by Risk Type/Priority from the corresponding completed Test Matrix for each build. In addition, it is recommended that you include the full Test Matrix results from the test cycle designated as Full Regression.

· Known Issues Document - This document is primarily for Technical Support. This document identifies workarounds, issues development is aware of but has chosen not to correct, and potential problem areas for clients.

· Installation Instruction - If your product must be installed as the client site, it is recommended to include the Installation Guide and any related documentation as part of the release package.

· Open Defects - The list of defects remaining in the defect tracking system with a status of Open. Technical Support has access to the system, so a report noting the defect ID, the problem area, and title should be sufficient.

· Deferred Defects - The list of defects remaining in the defect tracking system with a status of deferred. Deferred means the technical product manager has decided not to address the issue with the current release.

· Pending Defects - The list of defects remaining in the defect tracking system with a status of pending. Pending refers to any defect waiting on a decision from a technical product manager before a developer addresses the problem.

· Fixed Defects - The list of defects waiting for verification by QA.

· Closed Defects - The list of defects verified as fixed by QA during the project cycle.
The Release Package is compiled in anticipation of the Readiness Review meeting. It is reviewed by the QA Process Manager during the QA Process Review Meeting and is provided to the Release Board and Technical Support.

· Readiness Review Meeting:

The Readiness Review meeting is a team meeting between the technical product manager, project developers and QA. This is the meeting in which the team assesses the readiness of the product for release.

This meeting should occur prior to the delivery of the Gold Candidate build. The exact timing will vary by team and project, but the discussion must be held far enough in advance of the scheduled release date so that there is sufficient time to warn executive management of a potential delay in the release.

The technical product manager or lead QA may schedule this meeting.

· QA Process Review Meeting:

The QA Process Review Meeting is meeting between the QA Process Manager and the QA staff on the given project. The intent of this meeting is to review how well or not well process was followed during the project cycle.

This is the opportunity for QA to discuss any problems encountered during the cycle that impacted their ability to test effectively. This is also the opportunity to review the process as whole and discuss areas for improvement.

After this meeting, the QA Process Manager will give a recommendation as to whether enough of the process was followed to ensure a quality product and thus allow a release.

This meeting should take place after the Readiness Review meeting. It should be scheduled by the lead QA on the project.

· Release Board Meeting:

This meeting is for the technical product manager and senior executives to discuss the status of the product and the teams release recommendations. If the results of the Readiness meeting and QA Process Review meeting are positive, this meeting may be waived.

The technical product manager is responsible for scheduling this meeting.

This meeting is the final check before a product is released.
Due to rapid product development cycles, it is rare that QA receives completed PRADs and Functional Specifications before they begin working on the Test Strategy, Test Matrix, and Test Cases. This work is usually done in parallel.

Testers may begin working on the Test Strategy based on partial PRADs or confirmation from the technical product manager as to what is expected to be in the next release. This is usually enough to draft out a high -level strategy outlining immediate resource needs, potential problem areas, and a tentative schedule.

The Test Strategy is then updated once the PRAD is approved, and again when the functional specifications are complete enough to provide management with a committed schedule. All drafts of the test strategy should be provided to the technical product manager and it is QA's responsibility to ensure that information provided in the document (such as potential resource problems) is clearly understood.

If the anticipated release does not represent a new product line, testers can begin the Master Test Matrix and test cases at the same time the project's PRAD is being finalized. Testers can build and/or refine test cases for the new functionality as the functional specification is defined. Testers often contribute to and are expected to be involved in reviewing the functional specification.

The results summary document should be prepared at the end of each test cycle and distributed to developers and the technical product manager. It is designed more to inform interested parties on the status of testing and possible impact to the overall project cycle.

The release package is prepared during the last test cycle for the readiness review meeting.

8. Test Strategy Template

QA Test Strategy: [Product and Version]

[Document Version history in format MM-DD-YYYY]

1.0 PROJECT OVERVIEW

[Brief description of project]

1.2 PROJECT SCOPE

[More detailed description of project detailing functionality to be included]

2.0 MATERIALS CONSULTED

[Identify all documentation used to build the test strategy]

3.0 TESTING

· CRITICAL FOCUS AREAS

[Areas identified by developers as potential problems above and beyond specific feature enhancements or new functionality already given priority 1 status by QA]

· INSTALLATION:

[Installation paths to be qualified by QA. Not all products require installation testing. However, those that do often have myriad installation paths. Due to time and resource constraints, QA must prioritize. Decisions on which installation paths to test should be made in cooperation with the technical product manager. Paths not slated for testing should also be identified here.]

· GUI

[Define what if any specific GUI testing will be done]

· FUNCTIONAL

[Define the functionality to be tested and how it will be prioritized]

· INTEGRATION

[Define the potential points of integration with other MediaMap products and how they will be prioritized and tested]

· SECURITY

[Define how security issues will be tested and prioritized]

· PERFORMANCE

[Define what if any performance testing will be done and its priority]

· FAILURE RECOVERY

[Define what if any failure recovery testing will be done and its priority]

3.1 TECHNIQUE

· [Technique used for testing. Automation vs. Manual]

3.2 METHODOLOGY

[Define how testers will go about testing the product. This is where you outline your core strategy. Include in this section anything from tester assignments to tables showing the operating systems and browsers the team will qualify. It is also important to identify any testing limitations and risks]

4.0 TEST SET-UP

4.1 TEST PRE-REQUISITES

[Any non-software or hardware related item QA needs to test the product. For example, this section should identify contact and test account information for 3rd party vendors]

4.2 HARDWARE

QA has the following machines available for testing:

Workstations: Servers:
[Include processor, chip, and memory and disk space]

Other:
[Identify any other hardware needed such as modems etc.]

4.3 SOFTWARE

[Identify all those software applications QA will qualify with the product and those QA will not qualify. For example, this is where you would list the browsers to be qualified. It is also important to identify what will not be qualified (for example, not testing with Windows 2000)]

4.4 PERSONNEL

[Identify which testers are assigned to the project and who will test what. It is also important to identify who is responsible for the creation of the test strategy, test plan, test cases, release package, documentation review etc.]

5.0 COMPLETION CRITERIA

[Identify how you will measure whether the product is ready for release. For example, what is the acceptable level of defects in terms of severity, priority, and volume?]

6.0 SCHEDULE

6.1 Project Schedule
· PRD Review completed by [MM-DD-YYYY] - [STATUS]
· Functional Specification completed [MM-DD-YYYY] - [STATUS]
· Release Date approved by [MM-DD-YYYY] - [STATUS]
· Test Strategy completed by [MM-DD-YYYY] - [STATUS]
· Core Test Plan (functional) completed by [MM-DD-YYYY] - [STATUS]
· Readiness Meeting - [STATUS]
· QA Process Review Meeting - [STATUS]
· Release Board Meeting - [STATUS]
· Release on [MM-DD-YYYY] - [STATUS]

6.2 Build Schedule
· Receive first build on [MM-DD-YYYY] - [STATUS]
· Receive second build on [MM-DD-YYYY] - [STATUS]
· Receive third build on [MM-DD-YYYY] - [STATUS]
· Receive fourth build on [MM-DD-YYYY] - [STATUS]
· Receive Code Freeze Build on [MM-DD-YYYY] - [STATUS]
· Receive Full Regression Build on [MM-DD-YYYY] - [STATUS]
· Receive Gold Candidate Build on [MM-DD-YYYY] - [STATUS]
· Final Release on [MM-DD-YYYY] - [STATUS]

7.0 QA Test Matrix and Test Cases:

Characteristics of a Tester

Introduction

All professions in the world have certain traits or features attached to it. Software testing is no exception to this. Many a times you must have seen that as a tester your inputs are not being accepted in the real time software projects. You must also be working overtime for no fault of yours but due to bad planning by others. You are often asked to "complete the testing" or "windup testing" but also asked to ensure to deliver a defect free product. What should you do to be prepared in such situations? How to tackle the different sections of persons in the software projects? What characteristics portrays a successful "software tester"? Read on…

Communication skills - oral and written

There are situations when as a tester, you would have to meet / interact with different sections of people - the business analysts, the design team, the development team and other testing teams. In those situations, it is necessary to explain yourself (the issues/problems/clarifications that you may have) to them. It has to be conveyed in the correct way so that the person(s) sitting across the table is/are able to understand clearly. Also, it is very important that any defect that is written by you has to be understood clearly by the receiving team.

Be clear/ concise in your oral and written communication skills.

Critical eye

Look out for details. As a tester you should be in a position to look out for any implicit or unstated requirements that need clarification from the clients. Always check for "what if " scenarios and get the answers. Think in multi dimensional way about a problem/requirement.

For example, during testing of a home banking application, there was a requirement to display all balances in dual currencies (Euro/local currency). The business requirement stated the list of screens pertaining to the withdrawal and Balance Inquiry modules for which this requirement was supposed to be implemented. On analysis this requirement was impacting more places like the screen in which the user checks out the history of transactions, or does a deposit, or sets up a standing instruction to the bank. On discussing the issue with the client, it was found that they thought that this was implied!!

Have a critical eye for minor details though others might think them as insignificant.

Do not assume things

This is the continuation from previous point that as a tester it is very important that you should not assume any of the requirement / issues / problems / defects. For example, never assume that in a screen where data is captured a field labeled "Clear" clears the entire content, though it is pretty evident. Ask more questions and get the affirmations from the respective persons.

Also, remember that it is necessary to test the software from the end-user's perspective and not just compliance with the requirements given by the client.

Never assume anything. It may not be true as you think!

Convincing skills

It is a skill to convince and explain to a person who has developed the software as to why a defect report written is indeed a defect. Put forth this in such a way that the developer also starts thinking along the lines of the scenario given in the defect report / requirement. Remember in such situations to put you in other person's shoes and speak accordingly. Avoid using accusing words, do not get into any arguments and do not rise to any bait a developer may throw at you. Concentrate on the issue and not on the person.

Also, while deciding the end of testing activities, it is important to bring out the impact of the open defects in the software and the implications to the business analyst / client or whoever is the logical end point contact. It is necessary to push your point through either to continue with further testing activities or to stop testing.

Develop good convincing skills!

Be factual

While reporting a defect or clarification of a requirement, be as factual as possible. Do not bring in your own suggestions / views into picture. Do not use words that describe the type of work or the person who developed the software.

For example, do not bring in words like, "badly developed software", "often crashing software", etc. Do not spell out such phrases even during interaction with the developer. Such activities will only be counter productive. This is result in people not viewing your defect reports with seriousness.

Be a good reporter of facts!

Effective listening

While discussing a defect report / requirement clarification, give a good hearing to other person's view or perspective. Understand the limitations of the software and try to find ways to resolve such issues. For example, if there exists an issue that is pertaining to display / functionality in one particular browser version, ensure that it is listed as one of the "Known issues" in the Release Notes or Limitations section or in the Read me file.

Be flexible whenever required!

Provide constructive criticism

While discussing any issues / defects / requirements clarifications with developer / business analyst do not use words that are pointing to their personal characteristics. Be very tactful in describing issues / defects and try not to point fingers at the person who developed the software or who collected the requirements for the software.

Be empathetic

Listen to the developer / the business analyst who developed / collected the requirements carefully. Try to understand the reality and limitations. Do not argue over trivial issues. Try to resolve limitations / issues in different possible ways.

Develop good rapport with other teams, it helps!

Effective follow up of issues

Many a times, defects are written and deferred to next release. At the start of next release not all of them are picked up and fixed. The status of defects that are left out from previous releases need to be discussed at the beginning of every release with the business analyst / development team. Also, any issue that has not been converted to defect needs to have a closer follow up. This needs to be documented as Open issues at the end of the testing activity.

Be good at follow-ups!

Good reviewer

Be a good reviewer and look out for inconsistencies of implementation of a particular requirement across different sections. Review all user documentation apart from testing the software. Check out for inconsistencies in the description of the software, look for glossary and an index. This enables for easy search on topics of user's choice.

Sharpen your reviewing skills!

Conclusion

As a tester you need special set of interpersonal skills more than the technical and functional skills. More importantly patience should be there. Make a start, be aware and practice.

How to Write a Useful Bug Report?

How to Write a Useful Bug Report

Useful bug reports are ones that get bugs fixed. A useful bug report normally has two qualities:

1. Reproducible. If an engineer can't see the bug herself to prove that it exists, she'll probably stamp your bug report "WORKSFORME" or "INVALID" and move on to the next bug. Every detail you can provide helps.

2. Specific. The quicker the engineer can isolate the bug to a specific area, the more likely she'll expediently fix it. (If a programmer or tester has to decipher a bug, they may spend more time cursing the submitter than solving the problem.)

Description: Please provide a detailed problem report in this field. Your bug's recipients will most likely expect the following information:

Overview Description: More detailed expansion of summary.

-Drag-selecting any page crashes Mac builds in NSGetFactory

Steps to Reproduce: Minimized, easy-to-follow steps that will trigger the bug. Include any special setup steps.

1) View any web page. (I used the default sample page, resource:/res/samples/test0.html)
2) Drag-select the page. (Specifically, while holding down the mouse button, drag the mouse pointer downwards from any point in the browser's content region to the bottom of the browser's content region.)

Actual Results: What the application did after performing the above steps.

-The application crashed. Stack crawl appended below from MacsBug.

Expected Results: What the application should have done, were the bug not present.

-The window should scroll downwards. Scrolled content should be selected. (Or, at least, the application should not crash.)

Build Date & Platform: Date and platform of the build that you first encountered the bug in.

ISTQB Question Paper with Answers

1	We split testing into distinct stages primarily because: a) Each test stage has a different purpose. b) It is easier to manage testing in stages. c) We can run different tests in different environments. d) The more stages we have, the better the testing.
2	Which of the following is likely to benefit most from the use of test tools providing test capture and replay facilities? a) Regression testing b) Integration testing c) System testing d) User acceptance testing
3	Which of the following statements is NOT correct? a) A minimal test set that achieves 100% LCSAJ coverage will also achieve 100% branch coverage. b) A minimal test set that achieves 100% path coverage will also achieve 100% statement coverage. c) A minimal test set that achieves 100% path coverage will generally detect more faults than one that achieves 100% statement coverage. d) A minimal test set that achieves 100% statement coverage will generally detect more faults than one that achieves 100% branch coverage.
4	Which of the following requirements is testable? a) The system shall be user friendly. b) The safety-critical parts of the system shall contain 0 faults. c) The response time shall be less than one second for the specified design load. d) The system shall be built to be portable.
5	Analyse the following highly simplified procedure: Ask: “What type of ticket do you require, single or return?” IF the customer wants ‘return’ Ask: “What rate, Standard or Cheap-day?” IF the customer replies ‘Cheap-day’ Say: “That will be £11:20” ELSE Say: “That will be £19:50” ENDIF ELSE Say: “That will be £9:75” ENDIF Now decide the minimum number of tests that are needed to ensure that all the questions have been asked, all combinations have occurred and all replies given. a) 3 b) 4 c) 5 d) 6
6	Error guessing: a) supplements formal test design techniques. b) can only be used in component, integration and system testing. c) is only performed in user acceptance testing. d) is not repeatable and should not be used.
7	Which of the following is NOT true of test coverage criteria? a) Test coverage criteria can be measured in terms of items exercised by a test suite. b) A measure of test coverage criteria is the percentage of user requirements covered. c) A measure of test coverage criteria is the percentage of faults found. d) Test coverage criteria are often used when specifying test completion criteria.
8	In prioritising what to test, the most important objective is to: a) find as many faults as possible. b) test high risk areas. c) obtain good test coverage. d) test whatever is easiest to test.
9	Given the following sets of test management terms (v-z), and activity descriptions (1-5), which one of the following best pairs the two sets? v – test control w – test monitoring x - test estimation y - incident management z - configuration control 1 - calculation of required test resources 2 - maintenance of record of test results 3 - re-allocation of resources when tests overrun 4 - report on deviation from test plan 5 - tracking of anomalous test results a) v-3,w-2,x-1,y-5,z-4 b) v-2,w-5,x-1,y-4,z-3 c) v-3,w-4,x-1,y-5,z-2 d) v-2,w-1,x-4,y-3,z-5
10	Which one of the following statements about system testing is NOT true? a) System tests are often performed by independent teams. b) Functional testing is used more than structural testing. c) Faults found during system tests can be very expensive to fix. d) End-users should be involved in system tests.
11	Which of the following is false? a) Incidents should always be fixed. b) An incident occurs when expected and actual results differ. c) Incidents can be analysed to assist in test process improvement. d) An incident can be raised against documentation.
12	Enough testing has been performed when: a) time runs out. b) the required level of confidence has been achieved. c) no more faults are found. d) the users won’t find any serious faults.
13	Which of the following is NOT true of incidents? a) Incident resolution is the responsibility of the author of the software under test. b) Incidents may be raised against user requirements. c) Incidents require investigation and/or correction. d) Incidents are raised when expected and actual results differ.
14	Which of the following is not described in a unit test standard? a) syntax testing b) equivalence partitioning c) stress testing d) modified condition/decision coverage
15	Which of the following is false? a) In a system two different failures may have different severities. b) A system is necessarily more reliable after debugging for the removal of a fault. c) A fault need not affect the reliability of a system. d) Undetected errors may lead to faults and eventually to incorrect behaviour.
16	Which one of the following statements, about capture-replay tools, is NOT correct? a) They are used to support multi-user testing. b) They are used to capture and animate user requirements. c) They are the most frequently purchased types of CAST tool. d) They capture aspects of user behaviour.
17	How would you estimate the amount of re-testing likely to be required? a) Metrics from previous similar projects b) Discussions with the development team c) Time allocated for regression testing d) a & b
18	Which of the following is true of the V-model? a) It states that modules are tested against user requirements. b) It only models the testing phase. c) It specifies the test techniques to be used. d) It includes the verification of designs.
19	The oracle assumption: a) is that there is some existing system against which test output may be checked. b) is that the tester can routinely identify the correct outcome of a test. c) is that the tester knows everything about the software under test. d) is that the tests are reviewed by experienced testers.
20	Which of the following characterises the cost of faults? a) They are cheapest to find in the early development phases and the most expensive to fix in the latest test phases. b) They are easiest to find during system testing but the most expensive to fix then. c) Faults are cheapest to find in the early development phases but the most expensive to fix then. d) Although faults are most expensive to find during early development phases, they are cheapest to fix then.
21	Which of the following should NOT normally be an objective for a test? a) To find faults in the software. b) To assess whether the software is ready for release. c) To demonstrate that the software doesn’t work. d) To prove that the software is correct.
22	Which of the following is a form of functional testing? a) Boundary value analysis b) Usability testing c) Performance testing d) Security testing
23	Which of the following would NOT normally form part of a test plan? a) Features to be tested b) Incident reports c) Risks d) Schedule
24	Which of these activities provides the biggest potential cost saving from the use of CAST? a) Test management b) Test design c) Test execution d) Test planning
25	Which of the following is NOT a white box technique? a) Statement testing b) Path testing c) Data flow testing d) State transition testing
26	Data flow analysis studies: a) possible communications bottlenecks in a program. b) the rate of change of data values as a program executes. c) the use of data on paths through the code. d) the intrinsic complexity of the code.
27	In a system designed to work out the tax to be paid: An employee has £4000 of salary tax free. The next £1500 is taxed at 10% The next £28000 is taxed at 22% Any further amount is taxed at 40% To the nearest whole pound, which of these is a valid Boundary Value Analysis test case? a) £1500 b) £32001 c) £33501 d) £28000
28	An important benefit of code inspections is that they: a) enable the code to be tested before the execution environment is ready. b) can be performed by the person who wrote the code. c) can be performed by inexperienced staff. d) are cheap to perform.
29	Which of the following is the best source of Expected Outcomes for User Acceptance Test scripts? a) Actual results b) Program specification c) User requirements d) System specification
30	What is the main difference between a walkthrough and an inspection? a) An inspection is lead by the author, whilst a walkthrough is lead by a trained moderator. b) An inspection has a trained leader, whilst a walkthrough has no leader. c) Authors are not present during inspections, whilst they are during walkthroughs. d) A walkthrough is lead by the author, whilst an inspection is lead by a trained moderator.
31	Which one of the following describes the major benefit of verification early in the life cycle? a) It allows the identification of changes in user requirements. b) It facilitates timely set up of the test environment. c) It reduces defect multiplication. d) It allows testers to become involved early in the project.
32	Integration testing in the small: a) tests the individual components that have been developed. b) tests interactions between modules or subsystems. c) only uses components that form part of the live system. d) tests interfaces to other systems.
33	Static analysis is best described as: a) the analysis of batch programs. b) the reviewing of test plans. c) the analysis of program code. d) the use of black box testing.
34	Alpha testing is: a) post-release testing by end user representatives at the developer’s site. b) the first testing that is performed. c) pre-release testing by end user representatives at the developer’s site. d) pre-release testing by end user representatives at their sites.
35	A failure is: a) found in the software; the result of an error. b) departure from specified behaviour. c) an incorrect step, process or data definition in a computer program. d) a human action that produces an incorrect result.
36	In a system designed to work out the tax to be paid: An employee has £4000 of salary tax free. The next £1500 is taxed at 10% The next £28000 is taxed at 22% Any further amount is taxed at 40% Which of these groups of numbers would fall into the same equivalence class? a) £4800; £14000; £28000 b) £5200; £5500; £28000 c) £28001; £32000; £35000 d) £5800; £28000; £32000
37	The most important thing about early test design is that it: a) makes test preparation easier. b) means inspections are not required. c) can prevent fault multiplication. d) will find all faults.
38	Which of the following statements about reviews is true? a) Reviews cannot be performed on user requirements specifications. b) Reviews are the least effective way of testing code. c) Reviews are unlikely to find faults in test plans. d) Reviews should be performed on specifications, code, and test plans.
39	Test cases are designed during: a) test recording. b) test planning. c) test configuration. d) test specification.
40	A configuration management system would NOT normally provide: a) linkage of customer requirements to version numbers. b) facilities to compare test results with expected results. c) the precise differences in versions of software component source code. d) restricted access to the source code library.

Question number	Correct answer
1	A
2	A
3	D
4	C
5	A
6	A
7	C
8	B
9	C
10	D
11	A
12	B
13	A
14	C
15	B
16	B
17	D
18	D
19	B
20	A
21	D
22	A
23	B
24	C
25	D
26	C
27	C
28	A
29	C
30	D
31	C
32	B
33	C
34	C
35	B
36	D
37	C
38	D
39	D
40	B