香港优才计划测试

香港优才计划测试 | 楼主 | 2017-07-11 17:14:23 共有3个回复
  1. 1香港优才计划
  2. 22017香港优才计划申请条件
  3. 3香港理工大学-软件测试计划

核心摘要:综合计分制下设五个得分范畴而成就计分制则设有一个得分范畴,甄选程序会定期进行为申请人分配名额,分为综合计分制及成就计分制两种,最新适用的最低及格分数为分,在特殊情况下能附以证明文件的良好技术资历可证明的专。

香港优才计划2017-07-11 17:13:35 | #1楼回目录

香港优才计划

1.计划释义

优才计划,全称优秀人才入境计划 (Quality Migrant Admission Scheme),由香港特区政府推出,目的是为了吸引优秀外地人材来香港定居。计划于2006年2月23日公布,为了吸引更多的优秀人才到香港工作,特区政府于2006年6月28日正式开始推行“优秀人才计划”。

2.计划宗旨

本计划是一项设有配额的移民吸纳计划,旨在吸引新入境而不具有进入香港和在香港逗留权利的高技术人才或优才来港定居,藉以提升香港在全球市场的竞争力。获批准的申请人无须在来港定居前先获得本地雇主聘任。所有申请人均必须首先符合基本资格的要求,才可根据计划所设两套计分制度的其中一套获取分数,与其他申请人竞争配额。获批准的申请人可带同配偶及18岁以下未婚及受养的子女来港,惟其必须能自行负担受养人在香港的生活和住宿,不需依赖公共援助。

3.不适用人士

本计划不适用于右列地区的国民:阿富汗、亚尔巴尼亚、柬埔寨、古巴、老挝、朝鲜、尼泊尔及越南。

4.甄选程序

第一阶段:基本资格

根据本计划提出申请的人士,必须首先符合一套「基本资格」的要求,然后才能根据计划所设的两套计分制度的其中一套获取分数。

第二阶段:计分制度

符合「基本资格」所有要求的申请人,可选择以「综合计分制」或「成就计分制」的方式接受评核。「综合计分制」下设五个得分范畴,而「成就计分制」则设有一个得分范畴。

「综合计分制」设有最低及格分数,选择以「综合计分制」获取分数的申请人应先评估其个人资历是否已达到最低及格分数,才提交申请。

第三阶段:甄选程序

甄选程序会定期进行,为申请人分配名额。在每次甄选程序中,同时符合「基本资格」并在「综合计分制」下累计得分达到最低及格分数的申请,及符合「基本资格」并在「成就计分制」下获得分数的申请,依总得分排列名次后,得分较高的申请将获提选作进一步评核。入境事务处处长(下简称「入境处处长」)可就如何根据本计划评核、评分及分配名额征询一个谘询委员会的意见。该谘询委员会由香港特区政府行政长官委任的官方及非官方成员组成。谘询委员会将考虑香港的社会经济需要﹑各申请人所属界别及其他相关因素,向入境处处长建议如何分配每次甄选程序中可分配的名额。

得分较高的申请人不一定获分配名额。每次甄选结果会在入境处网页公布。由于甄选程序需时,除非入境处向有关申请人发出申请被拒绝的通知,否则申请人可视其申请为正在办理中。。

第四阶段:原则上批准

在甄选程序中获分配名额的申请人将获发一封「原则上批准通知书」,在接获该函件后,有关申请人须亲身前来香港出席会面,并出示其在申请期间递交的所有文件的正本,以便入境处查证。申请人可以访客身份来港出席上述会面。获发「原则上批准通知书」,并不自动保证申请人最终可循本计划获准入境香港或逗留香港。

第五阶段:获签发入境签证/进入许可

在入境处满意查证所有文件而且各相关申请程序均告完成后,获批准的申请人可根据本计划获发逗留香港的入境签证/进入许可。

5.计分方式

分为“综合计分制”及“成就计分制”两种。

第一种“综合计分制”:按照申请人的年龄、财政要求、良好品格、语文能力、基本学历5项条件打分,最高分为165分。适合普通人的综合计分方式。申请的人士,在预估其个人资历已达到最低及格分数条件下,可提交申请。最新适用的最低及格分数为80分。

第二种是成就计分:为“具备超凡才能或技术并拥有杰出成就的个别人士”提供的另一套申请定居香港的计分制度,该计分制以申请人的成就为评核基准,须符合以下两项要求中的一项:一是申请人曾获得杰出成就奖(例如奥运奖牌、诺贝尔奖、国家/国际奖项);二是申请人可以证明其工作得到同业肯定,或对其界别的发展有重大贡献(例如获业内颁发的终身成就奖)。

6.基本资格

优秀人才入境计划每年限额约为1,000个,香港优秀人才入境计划申请人基本资格包括:

申请人必须符合下列所有的基本资格:

年龄

申请人根据本计划提交申请时,年龄必须在18岁或以上。

财政要求

申请人必须证明能独力负担其本人及受养人(如果有)居港期间的生活和住宿,不需依赖公共援助。

良好品格

不论在香港或其他地方,申请人不得有任何刑事罪行记录或不良入境记录。 语文能力

申请人须具备良好中文或英文的书写及口语能力(中文口语指普通话或粤语)。

基本学历

申请人必须具备良好学历,一般要求为具备由认可大学或高等教育院校颁授的大学学位。在特殊情况下,能附以证明文件的良好技术资历、可证明的专

业能力及/或经验及成就亦可获考虑。

申请人如未能提供令人信纳的证明文件,证明符合上述所有基本资格,其申请将会即时被拒绝,不获继续处理。

7.计分制度

符合「基本资格」所有条件的申请人,可选择以「综合计分制」或「成就计分制」接受进一步评核。每名申请人只能在同一时间提交一份申请,并只能在同一次申请中选择以一种计分制进行评核。

综 合 计 分 制

得分范畴 分数 得分

1 :年龄(最高30分)

18-39:30

40-44:20

45-50:15

51华以:0

2; 学历 / 专业资格(最高45分)

2个或以上博士学位 45

博士学位 / 2个或以上硕士学位 40

硕士学位 / 2个或以上学士学位 30

学士学位 / 由国家或国际认可或著名的专业团体颁授,证明持有人具有极高水平的专门知识或专业技能的专业资格 30

3 :工作经验(最高50分)

不少于10年相当于学位程度或专家水平的工作经验,当中最少5年担任高级职位 50

不少于5年相当于学位程度或专家水平的工作经验,当中最少2年担任高级职位 40

不少于5年相当于学位程度或专家水平的工作经验 30

不少于2年相当于学位程度或专家水平的工作经验 20

4: 语文能力(最高20分)

a.良好中文及英文的书写及口语能力(中文口语指普通话或粤语) 20b.了具备良好中文或英文的书写及口语能力外(中文口语指普通话或粤语),也能流利应用不少于一种外国语言(包括书写及口语能力) 15

c.良好中文或英文的书写及口语能力(中文口语指普通话或粤语)10 5 :家庭背景(最高20分)

5.1 至少一名直系家庭成员(已婚配偶、父母、兄弟姊妹、子女)是现居于香港的香港永久性居民 5

5.2 随行已婚配偶的学历相当于大学学位或以上的水平 5

5.3 每名随行的18岁以下未婚及受养的子女得5分,最高可得10分 5/10最高165分

最低及格分数

「综合计分制」设有最低及格分数,有兴趣申请的人士,应先评估其个人资历是否已达到最低及格分数,才提交申请。最低及格分数可能会不时更改。最 新 适 用 的 最 低 及 格 分 数

最新适用的最低及格分数是80分。

成 就 计 分 制

本计划亦为具备超凡才能或技术并拥有杰出成就的个别人士,提供另一套申请来港的计分制度。这类别的申请人可选择以「成就计分制」接受评核。此计分制的要求极高。此计分制以申请人的成就作为评核基准,选择以此计分制评核其申请者,只能从一个得分范畴获取165分。申请人如被视作符合下段所述此计分制所列的其中一项要求,可获取165分,不符合者则不会获得分数,而不能取得分数的申请人,其申请会即时被拒绝。

如符合下述要求,可依此计分制获取分数:

i. 申请人曾获得杰出成就奖(例如奥运奖牌、诺贝尔奖、国家/国际奖项);或

ii. 申请人可以证明其工作得到同业肯定,或对其界别的发展有重大贡献(例如获业内颁发终生成就奖)。

8.入境安排

于甄选程序中获分配名额的申请人,将获发「原则上批准通知书」,持有该通知书的申请人会获邀请前来香港亲自出席会面,并提交紧接「原则上批准通知书」签发日前的10年内曾居住12个月或更长时间的每个国家/地区开具的无犯罪记录证明或具同等效力的证明文件的正本,以及出示其在申请期间提交的所有文件的正本,以便入境处查证。此外,如申请人为中国内地的居民,包括现时暂居于香港或澳门的内地居民,还需要提交其现时所属内地工作单位或负责备存其记录的内地有关当局所发出的赴港居留同意书。同意书的样本会与「原则上批准通知书」一并寄予有关申请人。申请人的受养人(如果有)无须来港出席会面。

获「原则上批准」并不等同根据本计划获发入境签证/进入许可的正式批准。申请人必须令入境处信纳其在申请期间所作的一切声明和资料为真实和完备,才会获得正式批准。

在获正式批准后,申请人及其受养人(如果有)将会根据本计划获发逗留香港的入境签证/进入许可。该入境签证/进入许可标签应贴在申请人的有效旅行证件的空白签注页上,在进入香港时向入境处人员出示。

曾根据任何入境政策或计划(包括但不限于一般就业政策及输入内地人才计划)来港并受一项或数项在港逗留条件限制的香港居民可申请参加此计划,条件是当局评核其申请时,会视申请人、其配偶及受养子女(如果有)为不具有进入香港和在香港逗留权利的新入境人士。在申请获正式核准后,申请人将根据本计划获签发入境签证/进入许可。

中国内地的居民,包括现时暂居于香港或澳门的内地居民,若其申请获批准,于根据本计划来香港居留前必须先取得因私「往来港澳通行证」(「通行证」)和相关的赴港签注。

持有中华人民共和国护照的中国公民在海外提交申请,并已取得外国永久居留或在紧接申请前已在海外居住满一年,(「海外」指中国内地、香港特区和澳门特区以外的地区),可使用其有效的中国护照申请根据本计划在香港居留。就循本计划进入香港的目的而言,此类别的海外中国公民并不需要上述的

「通行证」及相关的赴港签注。

2017香港优才计划申请条件2017-07-11 17:13:58 | #2楼回目录

环球移民 http://chddh.com

2017香港优才申请条件

2017年1月14日香港施政报告公布,香港暂停投资移民,同时香港优秀人才入境计划调整将于2017年第二季正式实施。

香港优才计划基本申请条件如下:

1、无犯罪记录

2、年龄18-50周岁之间

3、至少单人满足10万以上的资产证明及全家20万以上的资产证明

4、选择综合计分制或者成就计分制来获取合格分数

对比之前的申请,2017年香港优才入境计划新政内容作了以下改变:

一、 放宽逗留期限

1. 通过综合计分制申请优才获批的申请人,签证期限由现行模式1+2+2+3,变更为2+3+3;

2. 成就计分制获批后直接给与8年逗留签证;

3.综合计分制下的顶尖人才(通过优才计划赴港不低于2年,年薪200万港币以上),可获准2+6;

二、 增加额外加分制度

港府为吸引更为优秀的人才,新政中对于申请人的工作经验、学历方面分数有所降低,但新增了额外加分制度。

环球移民 http://chddh.com

在综合计分制下给予有优秀教育背景和2年以上国际工作经验额外分数。以泰晤士高等教育世界大学排名为指标,若申请人就读排名靠前具备竞争力的高等学府,额外再加30分。2年国际工作经验加15分。

新政放宽申请条件的同时,但对于人才的要求实则更高,评分更严格。新政更加注重国际高等学府的受教育经历及海外工作经历,可以预见的是,随着新政的实施,竞争将更加激烈。

值得一提的是国内之前办理香港优才计划的机构除了环球移民以外并没几家,总体上都是办理香港投资移民的,而1月14日的施政报告无疑成为继2017年加拿大暂停投资移民以后的又一次风暴,随着投资移民的暂停,越来越多的香港申请人会转投优才计划或者其他国家的移民项目。

香港理工大学-软件测试计划2017-07-11 17:12:01 | #3楼回目录

TEST PLAN FOR (PRODUCT)

________________________________________________________________________ This is a sample of an outline for a test plan.It has been designed for medium to small test projects, and thus is fairly lightweight.It is by necessity general, because each enterprise, each development group, each testing group, and each development project is different.This outline should be used as a set of guidelines for creating your own standard template; add to it or subtract from it as you find appropriate.Bear in mind that it is generally better to have an exceof detail in the template—detail which can be removed when creating a specific test plan—than to have to remember to add something that is not in the template.

(Looking for a heavy-duty test plan?The government and the military are good sources.Try the one on the IRS Web site:

http://chddh.com )

Make sure to fill in the running headers and footers with the product name, draft

numbers, revision dates, and page numbers; this is important in places with lots of test projects on the go.Make sure to include the author’s name, too, so that errors or questions can be addressed to the right person.

1. OVERVIEW

1.1.

1.2.

1.3. PRODUCT NAME PRODUCT REVISION PROJECT LEADS

Marketing Lead (or other customer representative)

Program Manager

Development Lead

Test Lead

Build and Release Control Engineer

Legal representative 1.3.1. 1.3.2. 1.3.3. 1.3.4. 1.3.5. 1.3.6.

Include names, phone numbers, and email addresses for each.Note that this table will differ for a particular company or group.The goal is to ensure that anyone walking into the company or into the test role can easily identify and

contact the people he/she needs to reach.

1.4. TEST PROJECT STAFF

Test requirements designers

Test case designers

Test personnel

For manual (i.e. non-automated) tests

For automated tests

Page 1

3/30/20171.4.1. 1.4.2. 1.4.3. 1.4.3.1. 1.4.3.2. Author Revision Number

TEST PLAN FOR (PRODUCT)

________________________________________________________________________

1.4.3.3.

1.4.4.

1.4.5. Test automation programmers Documentation reviewers Legal reviewer

Include names, phone numbers, and email addresses for each.Note that there may be several people in each role, that one person may be obliged to fill multiple roles, and that some roles (e.g. legal reviewer) won’t be required for all projects.

1.5. PRODUCT OVERVIEW

This could also be ―description of the change requirements‖ for maintenance projects.

1.5.1. Cut and paste from requirements document or specification a brief

summary description of the product or change, or describe the project

as understood by the developers—if the latter, make sure that there is

agreement and sign-off from the customer.

Identify the defect tracking system in use.

Identify the manner and schedule by which defect reports are expected

to be delivered to developers.

Identify parties that may have acceto the tracking system.

Identify the change control system.

Identify the means by which the team is to be notified of changes to the

requirements, the product, the test plan, etc. 1.6. TRACKING AND REPORTING SYSTEMS 1.6.1. 1.6.2. 1.6.3. 1.6.4. 1.6.5.

2. TESTING SYNOPSIS

2.1. Items to be tested

Refer to the functional requirements that specify the features and

functions to be tested.The description of the change need not be

excessively detailed when there is a complete description to refer to in

some other document.On the other hand, if there is no reasonable

specification available, more detail is called for here.

List the features and functions that will not be covered in this test plan.

Identify briefly the reasons for leaving them out.

This section should be filled out in detail for new projects.For

existing maintenance tasks, a simple cross-reference to the document

describing existing system requirements is fine. Note any changes to

previous system requirements, especially when support for a given

product or platform is being dropped.

Page 2

3/30/20172.1.1. 2.2. Items not to be Tested 2.2.1. 2.3. System Requirements 2.3.1. Author Revision Number

TEST PLAN FOR (PRODUCT)

________________________________________________________________________

2.3.2. If there is a system requirement that could be unclear, make it specific;

for example, for Web-based projects, identify not only the supported

browsers but also the minimum versions of the supported browsers.

List any standards or other reference material used in the creation of

this test plan.

Identify standards for acceptance criteria, defect severity, testable

specifications, and so on.(These standards may have to be created,

or adapted from time to time; the first use of this test plan will require

more work than later iterations.)

In cases where terminology could be unfamiliar or open to

interpretation, provide a list defining the unclear terms.

Obtain agreement on these terms from all interested parties.

Note:If no one is forthcoming with the information you need, make

something up; they might not have done their jobs from the outset, but

they’ll be happy to correct your work!You will have achieved the

goal, which is clarity and agreement. 2.4. Standards/Reference material 2.4.1. 2.4.2. 2.5. Glossary 2.5.1. 2.5.2. 2.5.3.

3. TYPES OF TESTING

3.1. ACCEPTANCE TESTING

Detail a set of acceptance criteria—conditions that must be met before

testing can begin.A smoke test should represent the bare minimum of

acceptance testing.

As noted above, the ideal is to create a separate document for

acceptance criteria that can be reused and referred to here.If any

particular, specialized test cases not listed in that document will be

used, refer to them here. 3.1.1. 3.1.2.

3.2. FEATURE LEVEL TESTING

This is the real meat of the test plan.The test categories below are filled in

itemizing categories of tests, along with references to the test library or catalog.Individual test cases should not be listed here; test requirements generally should not be either; the details should exist elsewhere and can be cross-referenced.

3.2.1. Task-Oriented Functional Tests

This is a detailed section, listing tests requirements for program

features against functional specifications, user guides or other

design related documents.If there are test matrices available

listing these features and their interdependence (and there should

be), refer to them. 3.2.1.1.

Author

Revision Number Page 33/30/2017

3.2.2. Forced-Error Tests

Provide or refer to a list of all error conditions and messages.

Identify the tests that will be run to force the program into error

conditions.

Boundary tests—tests carried out at the lines between valid and

invalid input, acceptable and unacceptable system requirements

(such as memory, disk space, or timing), and other tests at the

limits of performance—are the keys to eliminating duplication of

effort.Identify the types of boundary tests that will be carried

out.Note that such tests can also fall into the categories

outlined below, so this section may be removed, or made a sub-

section of those categories.

Identify components or modules that can be combined and tested

independently to reduce dependence on system testing.Identify

any test harnesses or drivers that need to be developed.

Specify the tests will be carried out to fully exercise the program

as a whole to ensure that all elements of the integrated system

function properly.Note that when unit and integration testing

have been properly performed, the dependence upon system

testing can be reduced.

In contrast to types of testing designed to find defects, identify

tests that will demonstrate the successful functioning of the

program as you expect the customer to use it.What type of

workflow tests will be run?What type of ―real work‖ will be

carried out using the program?

Specify the amount of ad-hoc or exploratory testing that will be

carried out.Identify the scope and the time associated with this

form of testing.

Indicate the types of tests will be carried out to see how the

program deals with very large amounts of data, or with a large

demand on timely processing.Note that these tests can rarely

be performed without automation; identify the automation tools,

test harnesses, or scripts that will be used.Ensure that the

programs developed for the test automation effort are

3.2.2.1. 3.2.3. Boundary Tests 3.2.3.1. 3.2.4. Integration Tests 3.2.4.1. 3.2.5. System-Level Tests 3.2.5.1. 3.2.6. Real World User-Level Test 3.2.6.1. 3.2.7. Unstructured Tests 3.2.7.1. 3.2.8. Volume Tests 3.2.8.1.

accompanied by their own sets of requirements, specifications,

and development processes.

3.2.9. StreTests

Identify the limits under which the program is expected to

perform.These may include number of transactions per unit

time, timeouts, memory constraints, disk space constraints, and

so on.Volume tests and stretests are closely related; you may

consider wrapping both into the same category.

How will the product be tested to push the upper functional limits

of the program?Will specific tools or test suites be used to

carry out stretests?Ensure that these are reusable.

Refer to the functional requirements that specify acceptable

performance.Identify the functions that need to be measured,

and the tests needed to show conformance to the requirements. 3.2.9.1. 3.2.9.2. 3.2.10. Performance Tests 3.2.10.1.

3.3. REGRESSION TESTING

At each stage of new development or maintenance, a subset of the

regression test library should be run, focusing on the feature or

function that has changed from the previous version.Unit,

integration, and system tests are all viable places for regression

testing.For small maintenance fixes, identify this subset.A good

version control system can allow the building of older versions of the

software for comparative purposes.

In the final phase of a complete development cycle, a full regression

test cycle is run.Identify the test case libraries and suites that will be

run.

Whether a subset or a full regression test run, existing test scripts,

matrices and test cases should be used, whether automation is

available or not.Identify the documents that describe the details.

Emphasize regression tests for functions that are new or that have

changed, for components that have had a history of vulnerability, for

high-risk defects, and for previously-fixed severe defects.

If applicable, identify the types of software and hardware compatibility

tests that will be carried out.

List operating systems, software applications, device drivers etc. that

the product will be tested with or against.

List hardware environments required for in-house testing. 3.3.1. 3.3.2. 3.3.3. 3.4. CONFIGURATION AND COMPATIBILITY TESTING3.4.1. 3.4.2. 3.4.3.

3.5. DOCUMENTATION TESTING/ONLINE HELP TESTING

Documentation and online help testing will be carried out to verify

technical accuracy of documented material.

If a license agreement is included in or displayed by the product, or the

portion of it to which this test plan refers, ensure the correct one is

being used (see the next item below).

Identify any copyright notices displayed by the program.Verify that

they are accurate and up to date.

In cases where an End-User License Agreement (EULA) is displayed by

the program, which EULA will be used in this product?Provide a

link to the file.Ensure that it is the consistent with the one included in

the product.

Receive sign-off from the legal department that this is the correct

EULA for this product.

If there are any additional products or components to be included in

the final product, or on the distribution media, list the types of tests that

will be carried out, and the extent to which they shall be performed.

How will deployment and installation be tested?

How will the uninstallation or rollback procebe tested?

Since some form of deployment is required for all software products,

what generic installation and uninstallation test catalogs will be used

or adapted for these tests?

What tools or processes will be used to assure that each line of code is

run at least once during testing?

Have the developers performed coverage tests during unit or

integration testing?Have they provided the results of these tests?

Have they provided source code, test harnesses, or test tools?

Are there plans to cover all code during regression testing?If not,

why not?

Identify date and time values that are accepted, calculated, and output

by the program.Pay attention both to hard dates and timespans. 3.5.1. 3.5.2. 3.6. COPYRIGHTS AND LICENSE AGREEMENT 3.6.1. 3.6.2. 3.6.3. 3.7. UTILITY, TOOL KIT, AND COLLATERAL TESTS 3.7.1. 3.8. INSTALL/UNINSTALL TESTS 3.8.1. 3.8.2. 3.8.3. 3.9. CODE COVERAGE 3.9.1. 3.9.2. 3.9.3. 3.10. YEAR 2000 AND DATE COMPLIANCE 3.10.1.

3.10.2. What tests, if any, will be carried out to make sure the program will

continue to work correctly when dates on both sides of the year 2000

are processed?

What tests, if any, will be run to ensure that other forms of date

processing are done correctly?

For products intended for global markets, what tests will be carried out

to make sure the product can be easily localized (that is, adapted for a

specific local market)?For products intended for Asian markets,

what tests will be performed to verify that the program correctly

handles multiple-byte character sets? 3.10.3. 3.11. INTERNATIONALIZATION 3.11.1.

4. TEST SCHEDULE AND RESOURCES

4.1. Identify the estimated effort required to execute the test plan.Include a both

a range and a confidence http://chddh.com e the guidelines on pp. 3.23 – 3.44 of the course book to plan and review estimates.

Identify the resources available to carry out the test plan.

Identify time or resource constraints that will lead to a risk of the test project falling behind schedule, below expected scope, or below expected quality.

Cross-reference this with the Unresolved Issues and Risks section later in this document.

If any testing is to be handled by another entity, such as another department

or a third party test lab, identify them.List names and contact information

at the beginning of this document.List the specific tasks they will be

assigned to carry out. Include references to contracts with these people, and

ensure that contracts are approved and signed.

Detail the planned test cycles and phases; these should be linked to the

development plan for the project.Specify the type of testing being done in

each phase.Typically unit testing will be done by the developer of the code, and need not be covered in detail in the test http://chddh.com egration and system

testing phases should be detailed here.

Outline the criteria for assessing the severity of found defects.List

expectations for setting the priorities on resolving http://chddh.com llaborate with

the developer(s), project managers, and the customer representatives on this. Identify in advance the criteria that must be fulfilled before each stage of

testing can be considered complete.Make these specific, measurable, and

decidable; otherwise, expectations will differ and time will be wasted on

discussion and debate.

If there are to be staged releases of system testing – typically alpha for

internal releases, beta for limited releases to external test sites, and final

4.2. 4.3. 4.4. 5. TEST PHASES AND COMPLETION CRITERIA 5.1. 5.2. 5.3. 5.4.

releases – sometime called ―gold master‖, define http://chddh.com fine acceptance

standards for each phase.Ideally these should be in a separate document

that can be referred to here

Bear in mind that there is a chance that the standards set here are subject to

being overruled by some authority or another; for example, a product may

ship with a higher than satisfactory number of minor defects, at the behest of a marketing department or CFO that wants the product released with time as the most important consideration.Be prepared to accept such decisions

dispassionately, but also be prepared to record them as failures to fulfill the

standards set and agreed upon in http://chddh.com panies and individuals can forget easily and repeat mistakes when there is no record of breached

agreements and their consequences; people learn and improve more easily

when records of successes and failures are available.

6. UNRESOLVED ISSUES AND RISKS

6.1.

6.2. Identify issues that have yet to be decided as of this draft of the plan.Note these as risks to the schedule, scope, or quality of the test effort. Identify other risks that may have an impact on the succeof the http://chddh.com e

the risks outlined in the course book and the attached speaker notes as a

guideline to identifying common risks.Refer also to the Software Project

Survival Guide (Steve McConnell), which includes a good list of risks for

every phase of development.When assessing risk, don’t be optimistic; the

quality of the test plan and the risk assessment is weakened by failure to

asserisk realistically.

Include plans for review of this test plan.Identify the parties to review and

approve the document, either within the test group or with another set of

developers or test engineers.Look at sample test plan checklists, such as

that on p. 3.45 – 3.47 of the course book, or those in Software Project

Survival http://chddh.com e ideas from these checklists to develop your own

checklists, appropriate to the size and scope of the product.Identify here

the checklist(s) that will be used.

Meet with developers and customers or customer representatives to ensure

that the test plan meets their requirements. 7. TEST PLAN REVIEW 7.1. 7.2.

回复帖子
标题:
内容: