发布新日志

  • Test Plan Heuristics

    2009-03-12 11:07:18

    1.  Testing should be optimized to find important problems fast, rather than attempting to find all problems with equal urgency.(给予我的经验教训就是不要着急full sweep的测试,先smoke test,然后 new feature testfocus on 改变的部分),然后important feature testing,最后是function sweep testing)

     

    2. Test strategy should focus most effort on areas of potential technical risk, while still

    Putting some effort into low risk areas just in case the risk analysis is wrong.

    (之前做过一个项目,因为develop team没有怎么做过REGUID,开发和QA没有沟通好,应该把build兼容测试作为重点进行测试,但是test plan放到了较后,review test plan, PM等也没有提出啥异议,造成项目进行了一段时间,发现了严重的兼容问题,导致很多rework的工作,造成项目延后)

      

    3. Test strategy should address test platform. configuration, how the product will be operated, how the product will be observed, and how observations will be used to

    Evaluate the product.(就我公司而言,这些信息是PM和客户去沟通确认需求,归档到PRD中,QA按照PRD的需求制定计划。一般这些信息不是很明确,就要QA提出,以免资源浪费或是测试不够)

     

    4. Test strategy should be diversified in terms of test techniques and perspectives. Methods of evaluating test coverage should take into account multiple dimensions of coverage, including structural, functional, data, platform, operations, and requirements.(制定测试计划要考虑如何在有限资源的情况下cover更多)

     

    No single test technique can reveal all important problems in a linear fashion. We can never know for sure if we have found all the problems that matter. Diversification minimizes the risk that the test strategy will be blind to certain kinds of problems.

     

    5. The test strategy should specify how test data will be designed and generated.

    It is common for the test strategy to be organized around functionality or code, leaving it to the testers to concoct test data on the fly.  (对我公司而言就是测试素材的制作,对于多媒体软件而言,测试素材多而广,有good bad两种素材,bad素材测试软件的容错性等,这还涉及到素材的管理和更新的问题)

     

    6. Not all testing should be pre-specified in detail. The test strategy should incorporate

    reasonable variation and make use of the testers’ ability to use situational reasoning to

    focuse on important, but unanticipated problems.(要来考虑exploratoryad hoc testing的时间)

     

    7. It is important to test against implied requirements—the full extent of what the

    requirements mean, not just what they say.(在制定test plan之前,要和项目相关人员一起review requirements,模糊的问题提早明确)

    Heuristic Basis for heuristic

    8. The test project should promote collaboration with all other functions of the

    project, especially developers, technical support, and technical writing. Whenever

    possible, testers should also collaborate with actual customers and users, in order to better

    understand their requirements.(项目组各个team的合作很重要,信息的共享与传递更重要,定期的项目会议也许是个比较有效的办法)

     

    9. The test project should consult with development to help them build a more testable product.

    (什么是testableWiki的定义是It means it can be tested, but it also can be proven wrong later. In engineering this refers to the capability of an equipment or system to be tested. 

    10. A test plan should highlight the non-routine, project-specific aspects of the test strategy and test project. 我也在想尽量做到test plan不是个没有内容的的毫无价值文档)

     

    11. The test project should use humans for what humans do well and use automation for what automation does well. Manual testing should allow for improvisation and on the spot critical thinking, while automated testing should be used for tests that require high repeatability, high speed, and no judgment.  (对我而言是欠缺对自动测试的考虑和计划)

     

    12. The test schedule should be represented and justified in such a way as to highlight any dependencies on the progress of development, the testability of the product, time required to report problems, and the project team’s assessment of risk. (做好estimation非常重要)

     

    13. The test process should be kept off of the critical path to the extent possible. This can be done by testing in parallel with development work, and finding problems worth fixing faster than the developers fix them.(测试应该尽早进入到项目中工作,critical Path在一个项目工程中,需要时间最长的路径。这条路径上的工作必须尽可能快地完成, 为它决定完成总任务的时间,即完成该项目总共需要的时间不可能少于沿着关键路径去做所 需要的时

     euristic Basis for heuristic

    14. The feedback loop between testers and developers should be as tight as possible.

    Test cycles should be designed to provide rapid feedback to developers about recent

    additions and changes they have made before a full regression test is commenced. (定期developertester项目会议的召开;测试进展,BUG提交情况信息及时发送给develop team;强制开发fix bug的时候反馈tester 详尽的信息,更改的componentsrisk,如果能有建议如何regression bug那更好)

     

    15. The test project should employ channels of information about quality other than formal testing in order to help evaluate and adjust the test project. Examples of these channels are inspections, field testing, or informal testing by people outside of the test team. (尽量多渠道测试产品,这个可能会受客观环境所限)

     

    16. All documentation related to the test strategy, including test cases and procedures,should be undergo review by someone other than the person who wrote them. The reviewprocess used should be commensurate with the criticality of the document. Test plantest case review,尽量得到别人的建议和反馈)

     

  • Test plan function and quality criteria

    2009-03-10 17:09:52

    1.Test Plan Functions:
    1)enables wise and timely decisions to be made concerning the product.
    2)Promote awareness of the benefits and limitations of the test strategy.
    3)Describe and justify any special requirements or entry criteria that must be met in order for the test project to proceed, as well as any exit or process for determining when to stop testing.(曾经项目到一半,开发和QA都不明确进入和退出一些milestone的标准,感慨呀)
    4)the initiation and organization of the test project, including preparations, staffing, delegation of responsibilities, facility acquisition, task planning, and scheduling.
    5)daily management and evaluation of the test project and test strategy.
    6)effective coordination, collaboration, and other relations among members of the test team, and between the test team and the rest of the project.(会议的机制,BRB,weekly meeting....)
    7)Identify and manage any risks or issues that may impact the project.(Risk matrix)
    8)Specify the deliverables of the test project, and the delivery process.
    9)Record historical information (write project daily report...)

    2.Test Plan Quality Criteria
    _ Usefulness. Will the test plan effectively serve its intended functions?
    _ Accuracy. Is it accurate with respect to any statements of fact?
    _ Efficiency. Does it make efficient use of available resources?
    _ Adaptability. Will it tolerate reasonable change and unpredictability in the project?
    _ Clarity. Is the test plan self-consistent and sufficiently unambiguous?
    _ Usability. Is the test plan document concise, maintainable, and helpfully organized?
    _ Compliance. Does it meet externally imposed requirements?
    _ Foundation. Is it the product of an effective test planning process?

  • 关于build test plan自己存在的一些问题

    2009-03-09 16:06:23

    关于test plan自己存在的一些问题,在此记录一下:

    1)形式多于内容,制定test plan之前,对项目和产品分析不够,尤其是product coverage outline

    2)对于产品的product risk分析不够,可以说没有认真考虑,当然也没有写出有用的risk matrix,也不能发给项目相关人去review这些来自QA角度发现的风险,当然也得不到回馈,更谈不上有效的基于风险的测试。

    3)没有真正考虑如何maximum effectiveness,测试计划没有列出测试的重点,而只是泛泛而谈一些测试策略,这样可能造成测试重点偏离,浪费资源而工作质量不高。

    4)还有很重要的一点,测试计划一定要发给相关项目人,并且actively solicit opinions about the test plan。我之前的许多测试计划发过去是得不到任何的反馈,而且这种情况发生频繁,即便是review test plan,也是形式多于实质,这当然也是公司流程的问题,这样只有靠自己积极的去请求别人的feedback,也许这些feedback能让test plan 更有效指导测试工作,也许也能避责。

  • GUI Testing: Don't Sleep Without Synchronization

    2009-03-02 09:55:17

     

    GUI Testing  Don't Sleep Without Synchronization

    http://googletesting.blogspot.com/2008/10/gui-testing-dont-sleep-without.html

  • From Tran

    2008-10-30 16:48:57

     今天听Tran讲了一些QA知识,在此记录一些有价值的东西。

    首先是关于Estimate

    Source of estimate dataUse historical as your guide

    1) Previous status reports

    2) Test case libraries

    3) Bug trends from Previous release

    4) Estimates from previous release

    5) Test case time data

    Test estimation Risk factors

    1)      PRD

    a.       How well defined are the features?

    b.      How responsive is the Product Manager?

    2)      Component health

    a.       How stable is the component affected?

    b.      What is the amount of change expected?

    3)      Engineering team experience

    a.       Has the QA and dev teams worked on this project before?

    4)      External team dependencies

    a.       Are there features which require work from teams outside of your own?

    b.      Are there features which require work from teams outside of Sonic?

    5)      Logo CertificationsVista Logo …

    a.       What is the certification process and how long does it take?

    Estimation Best Practices:

    1)      Do…

    a.       Keep in mind your customer

    b.      Use historical data as a base for your estimates

    c.       Remember to account for bugs, ad-hoc and re-test time

                                                                   i.      * 2 modifier is typical

    d.      Plan for testing overhead

                                                                   i.      2 hours per day is typical

    2)      Do Not…

    a.       Estimate to meet an end date

                                                                   i.      This is your best case estimate, not your test plan

    b.      Cut testing corners to meet an end date

    c.       Estimate anything without a PRD

    d.      Plan to get more than 6 hours of work per day per tester(最好不要高估team成员的有效工作时间)

    关于test plan,有一句话是:What you do not test is just as important as what you do test.

  • Agile Project Management with Scrum

    2008-10-25 13:16:58

    公司流程的改变,这周主要对敏捷的Scrum培训和Daptiv工具 的培训,因为是英语培训,许多东西自己要整理一下。

    首先是和开发传统模型(Waterfall)的对比,传统模型随着系统因素(内部和外部因素)的复杂度增加,项目成功的可能性就迅速降低。而scrum模型非常灵活,是一个增量迭代的开发过程。在这个框架整个开发周期由若干个小的迭代周期(Iteration Cycle),每个小的迭代周期称为一个Sprint,每个sprint的周期是1430天。每个sprint inspection process 组成,各个team的成员每天碰一次头review项目进行的活动并做适当的修改。推进迭代过程的需求来自Product Backlogscrum的开发团队拿到一个排列好优先级的需求列表,因此开发的是对客户就有较高价值的需求。每个迭代结束后,都会完成可交付的产品。

     

    这里先解释两个术语:

    Product Backlog:在项目开始的时候,product owner要准备一个根据商业价值排好序的客户需求列表,这个列表就是product backlog,一个最终会交付给客户的产品特性列表,它们根据商业价值来排列优先级别。Scrum team会根据这个来做工作量的估计。

    Product Backlog应该涵盖所有用来构建满足客户需求的产品特性,包括技术上的需求。高优先级的一些产品特性需要足够的细化以便我们做工作量估计和做测试。对于那些可以在下个Sprint中完成的Product Backlog功能点,大约10人天的工作量的粒度就不错了。对于那些以后将要实现的特性可以不够详细。

    Sprint  BacklogSprint BacklogSprint规划会上产出的一个法宝。当Scrum team选择并承诺了Product Backlog 中要递交的一些高优先级的产品功能后,这些功能点就会被细化成为Sprint Backlog:一个完成Product Backlog功能点的必需的任务列表。这些点会被细化为更小的任务,工作量小于两天。Sprint Backlog完成后,scrum team会根据它重新估计工作量,如果这些工作量和原始设计的工作量有较大差异,scrum team会根据它重新估计工作量,如果这些工作量和原始估计的工作量有较大差异,scrum teamproduct owner协商,调整合理的工作量到sprint中,以确保sprint的成功实施。

    Burndown Chart现实了sprint中累积剩余的工作量,它是一个反应工作量完成状况的趋势图。在sprint开始的时候,develop team会表示和估计在这个sprint需要完成的详细的任务。所有这个sprint需要完成,但没有完成的任务的工作量是累积工作量,scrum master会根据进展情况每天更新和积累工作量,如果在sprint结束时,累计工作量降低到0sprint就成功结束。

     

    Sprint的会议形式:

    Daily Scrum 会议:Scrum组织成员每天要开Daily Scrum会议,用15分钟的时间让大家review项目的进度情况。在会上,每个团队成员需要问3个问题:(What have you done on the project since the last daily Scrum meeting?

    What do you plan on doing on this project between now and the next daily Scrum meeting?

    What impediments stand in the way of you meeting your commitments to this Sprint and to this project?)就是我昨天做了什么,今天做了什么,遇到哪些障碍。这个会议的目标是监测项目的全局,定位项目成员的要求,实时的调整当天开发计划。Note:不允许非项目内的人发言。

     

    Sprint Planning Meetingsprint规划会):参加者有product ownerdevelop teamscrummaster。需要要鸡的角色的人参与,第三方提供数据后就可以解散。第一个四个小时的会议来对product backlog进行选择,肯能否在sprint内完成。Product owner在会议之前准备好product backlogproduct owner决定哪些要在sprintdevelop team可以提出建议。然后team再从product owner选好的product backlog中决定哪些在在sprint。第二个四个小时,develop team列出所有的任务,进行时间的评估和分配。

     

    Sprint Review meetingsprint 评审会):一个小时准备时间,四个小时的review时间。参加会议的developteam表明已经完成功能,没有完成的team不能参见。会议的开始是develop team演示完成的product backlogsprint backlogdevelop team的成员会讨论在这个sprint中哪些做得好需要保持,哪些需要改进。会议的大部分时间是产品的演示,以及回答stake-holder的问题。功能演示完之后,stakeholders会对此评价,并提出想要改变的东西以及优先级。接下来product owner会和develop teamstakeholdersproductbacklog的反馈进行重现安排和规划。Stakeholders也许会发表自己对演示的想法,或是提出新要增加的product backlog。在会议的最后,会宣布下一次评审会议的时间和地点。

    Sprint Retrospective Meeting:设定三个小时,参加者有,develop teamscrummaster product owner可选。所有的develop team需要回答两个问题:上一个sprint哪里做得好,哪里需要改进。Scrummaster会记录所有的回答,并和team一起排列优先顺序。需要改进的项目添加到下一个sprint中作为高优先级非功能性product backlog

     

     

    Scrum定义了许多角色,根据Pigchicken的笑话分为两组,pigchicken

    猪是全身投入项目和scrum过程的人:Product ownerscrummaster,和Develop Team

    Product Owner的职责:

    确定产品的功能;

    决定发布日期和发布内容;

    为产品的ROI负责;

    根据市场价值确定功能优先级;

    接受或拒绝接受开发团队的工作成果。

    Develop Team

    具有不同特长的团队成员,人数控制在7个左右;

    确定sprint目标和具体说明工作成果;

    在项目向导范围内有权利做任何事情已确保到sprint的目标。

    高度的自我管理能力;

    product owner演示产品功能。

     

    ScrumMaster

    保证团队资源完全可被利用并且全部是高产出的。

    保证各个角色及职责的良好协作。

    解决团队开发中的障碍。

    做为团队和外部的接口,屏蔽外界对团队成员的干扰。

    保证开发过程按照计划进行,组织daily scrumsprint reviewsprint planning meetings

    NoteScrumMaster is not a project manager the team is self-managing.

  • Vista系统自带收集性能监视数据工具

    2008-10-13 14:07:05

    打开控制面板->管理工具->Reliability and Performance Monitor.通过Performance Monitor 程序可以检查CPU利用率,磁盘忙闲情况,内存等等,并随意添加想要监视的性能技术器。

    常用的性能计数器有:

    Processor/%processor time(除以CPU的个数):指处理器执行非闲置线程时间的百分比。这个计数器设计成用来作为处理器活动的主要指示器。它通过在每个范例间隔中衡量处理器用于执行闲置处理线程的时间,并且用 100% 减去该值得出。(每 台处理器有一个闲置线程,该线程在没有其它线程可以运行时消耗周 期)。可将其视为范例间隔用于做有用工作的百分比。这个计数器显 示在范例间隔时所看到的忙时平均值。这个值是用 100% 减去该服务不活 动的时间计算出来的

    Process/Private Bytes指这个处理不能与其它处理共享的、已分配的当前字节数。

    Process/Virtual Bytes: 指处理使用的虚拟地址空间的以字节数显示的当前大小。使用虚拟地址空间不一定是指对磁盘或主内存页的相应的使用。虚 拟空间是有限,如果使用过多,可能会限制处理加载数据 库的能力。

    Process/Working Set –Private (vista only)(note:xp(working set): 指这个处理的 Working Set 中的当前字节数。 Working Set 是在处理中被线程最近触到的那个内存页集。如果计算机上的可用内存处于阈值以上,即使页不在使用中,也会留在一 个处理的 Working Set中。当可用内存降到阈值以下,将从 Working Set 中删除页。如果需要页时,它会在离开主内存前软故障返回到 Working Set 中。

    收集性能监视数据(Create Data Collector Sets

    打开控制面板->管理工具->Reliability and Performance>Data Collect Sets>User Defined:右侧新建一个Data collection set。选择Create manually,然后create logs for Performance Counter,添加performance counter(自定义选择)。监视目标可以是本地也可以远程的。如果要长期收集性能数据,最好调整一下采样间隔时间,否则监视的数据会很多,日志文件会变得很大。设置好监视的对象和计数器后,可以在“日志文件”页调整日志文件的格式,在“schedule”页设置启动和停止日志的时间。性能计数器的日志除了默认的二进制.blg格式外,还可以保存Comma SeparatedCSV,逗号分隔的文本文件),也可以保存到SQL Severity表,如果选择了SQL Server,还要制定一个SQL Server的数据源和保存的数据表格。生成的log文件提取数据,做成性能监视数据的图标更方便些。

  • SMS配置(二)

    2008-10-09 16:43:03

    SMS的配置:

    1) 配置DHCP

    2) 安装Active Directory。(Startruntypedcpromo”,click OK to launch AD installation wizard

    SMS主站点的安装步骤:

    3) 安装和配置site database:安装SQL Server

    4) 安装SMS Primary site

    a) 展开AD Schemarun adsiedit.msc,建立system container

    b) Primary Site Installation

     

    c) 验证安装是否成功

    5) SMS 2003 Primary Site配置

    A)   配置site propertiesrun dssite.msc,打开Active Directory sites and service window

    B)   配置site system

    安装IIS

    安装BITS server extension

    6) 配置site system(主要是配置system roles

     

    Resource Discovery SMS client的安装

    1) 一共有六种discovery method,我们选择active directory system discovery

    2) Client 的安装

    配置Client 连接帐户(run dsa.msc

    SMS client的安装方法:

    Client push Installation\Manual\Windows Group Policy\Software Distribution\Logon scrīpt Initiated\Imaging.(我使用Client push Installation的方法)

  • SMS配置

    2008-10-09 16:39:06

                                                        SMS配置

    公司要做的一个项目要用到SMS,今天对SMS的一些知识进行一些记录和总结。

     

    SMSsystems Management server),是微软用于在服务器上管理客户端的综合集成软件,通过标准的internet 技术,解决永和的更改和配置需求。常用的功能有:

    1) 安装软件/补丁。SMS能够向任何用户,用户组,网段和计算机的组合发布各类软件,补丁;

    2) 资产管理。服务器会按照需求定期的收集客户端的软硬件信息以及网络状况,管理员可以监控软硬件变化。

    3) 远程桌面监控和问题的解决。

     

    SMS相关的术语和概念:

    1) 站点类型

    Primary siteSecondary sitePrimary site是拥有独立的SQL Server数据库站点,而secondary site没有自己的数据库,它的数据保存在其母站点的数据库中;

    母站点(Parent Site),子站点(Child Site)和中心站点(Central Site
    parent site
    接受child site的数据,它的数据库中存储所有更低级别站点的信息,child将软件、硬件收集等信息传递给它的parent siteparent site只能是primary site,而child site既可以是primary site,也可以是secondary sitecentral siteSMS站点结构中位于最顶端的站点,它不是其他任何站点的child site,可以在central site上查看并管理所有的站点

    2) Site boundaries

    SMS的边界分为两种,一种是站点边界,一种是漫游边界。某些SMS高级客户端是可以移动的,可以从一个物理网段移动到另一个网段,我们把这个成为漫游(roaming)。配置为自动分配(auto-assignment)的高级客户端根据站点的roaming boundary配置来选择被分配的SMS站点。也可以不考虑漫游区域而手动地分配一个站点。通过使用漫游区域,一个高级客户端可以从一个区域迁移到另一个区域,并仍能被SMS管理,接收SMS发来的软件包。站点边界只支持标准客户。

    3)                Roaming Boundary

    Regional roaming:在没有AD或者没有扩展Schema的情况下,高级客户端只能漫游到低级别的站点,这叫作regional roaming
    global roaming
    global roaming允许高级客户端漫游到高级别的站点,它需要扩展Schema
    local roaming boundary
    :通常为本地区域,共享高速连接的区域配置local roaming boundary
    remote roaming boundary
    :通常为远程区域,共享低速连接的区域配置remote roaming boundary

    4) 安全模式

    高级安全模式(Advanced Security: 使用Local System账号启动SMS服务,无需维护SMS服务账号,推荐使用。
    标准安全模式(Standard Security: SMS服务需要一个SMS服务账号来启动。这个帐号需拥有Domain admin 权限。(如果SMS服务器不是在域控制器上,同时需要扩展AD,需要有AD的更改权限。

    5) SMS客户端类型

    SMS 2003客户端有两种类型: 标准客户端(Legacy Client)和高级客户端(Advanced Client)。
    标准客户端适用于Windows 98Windows NT SP6 Windows 2000 Windows XPWindows 2003
    高级客户端适用于Windows 2000 Windows XPWindows 2003

    6)                Site system Role

    Site Server: SMS的核心服务. 用于处理SMS的数据并反映在SMS管理界面或报表中;
    Site Boundary:
    用于确定SMS Site Server的管理范围;
    SMS Provider:
    用于给site server提供SQL服务;
    Management Point (MP):
    介于SMS Site Server SMS高级客户端之间的中间节点.,高级客户端通过他与SMS联系;
    Client Access Point (CAP):
    介于SMS Site Server SMS标准客户端之间的中间节点.,标准客户端通过他与SMS联系;
    Distribution Point (DP):
    存放软件包的服务器。SMS Site Server将软件包保存到DP,然后通过MPCAP通知客户端到DP来执行软件包的安装,可以理解成文件仓库
    Server Location Point (SLP):
    用于替SMS客户端查找到合适的CAPMP
    Reporting Point (RP):
    用于提供基于WEB的报表服务;
    Data Discovery Record
    DDR: 数据发现记录;
    Client Configuration Request(CCR):
    客户配置请求。

    7) ADActive Directory

    存储关于网络上对象的信息并使这些信息可以用于用户和网络管理员的目录服务。Active Directory 允许网络用户通过单个登录过程访问网络上任意位置允许访问的资源。它给网络管理员提供了直观的网络层次结构视图和对所有网络对象的单点管理。

    8) DHCPDynamic Host Configuration protocol server

    动态、限时地分配地址库中的 IP 地址。DHCP 用于自动集中地配置 TCP/IP 网络中的计算机。这种配置具有标准化优势,不需要任何手工干预。网络管理员决定如何分配 IP 地址。管理员也决定分配的有效时间。从原则上讲,此过程的作用是为每位网络用户分配不同的 IP 地址。由于网络组件(例如 COM 服务器和打印服务器)始终通过固定的 IP 地址寻址,因此必须将这些组件排除在通过 DHCP 分配 IP 地址之外。

    9) IIS

    IISInternet Information Server的缩写,它是微软公司主推的服务器, IISWindow Server完全集成在一起,因而用户能够利用Windows NT ServerNTFSNT File SystemNT的文件系统)内置的安全特性,建立强大,灵活而安全的InternetIntranet站点

     

     

  • Be Smart

    2008-10-07 19:20:19

    今天看了Ivar Be Smart讲座,最近头一直说有smart work,对smart比较敏感。在此记录一笔。

     

    他讲到Software Development被流行和时尚所驱赶,15年前是OO,十年前是ComponentsUMLUnified Process5年前是RUPCMMI,两年前是XP,现今是Scrum。(我们公司已经在推展Scrum一段时间了,呵呵)He said all good but none is your need, we should work smarter.

     

    smart 到底是什么意思?

    Things should be done as simple as possible-but no simpler.

    Smartintelligent不是同一件事情;

    要想smart必须具备common sense(常识?);

    如果smart了也就agile(敏捷)了,但是smart包含更多的内容:

    Agile意思是灵活并且能适应不同的环境;

    Being Smart=Being Agile+在特定的环境做正确的事情;

    做正确的事情源于规则(培训和经验)。

     

    什么是smart?什么是unsmart

    People

    认为流程和工具比人重要。(unsmart)(强烈同意)

    切记软件是由人开发出来的。(smart

    Projects

    瀑布方法(unsmart)

    先构建个简洁的系统(skinny),然后增加能力,不断丰满这个系统。(smart

    Requirements

    需求之前就定义并细化不再改变(unsmart

    基于轻量级的需求决议,如果需要再细化。切记需求是可商议,优先级可以修改的。(smart)(看来我以后我不能抱怨需求老是变来变去)

    Architecture

    没有architecture,只有代码。(unsmart

    之前所有的事情都设计好,架构庞大复杂。(unsmart

    切记:决定软件质量的一个重要因素是architecture的质量。

    基于skinny system构建architecture,必须有可执行的代码,否则是空想。(smart

    Modeling

    没有modeling或处处modeling。(unsmart

    如果建模语言是不可执行的,基于skinny system。(smart

    Test:

    定义两类人:思考者和清洁问题的人,测试员就是软件的清洁工。(unsmart

    人人都是测试人员。(smart

    Documents

    过多的强调文档。(unsmart

    强调essentials(本质)(smart)(我之强经常抱怨文档做得不够,不好?)

    Process

    采用很多流程方法。(unsmart

    要基于本质,采用基于实践的方法。(smart

     

    如何变得更smart

    不断的获取只是和经验,不断的改进;

    不同领域的实践-软件工程,过程管理等;

    还有不要扔掉自己已有的……

     

     

     

     

  • 阶段式与连续式表述

    2008-10-06 18:24:58

    连续式表述

    当使用CMMI模型进行流程改善时,连续式表述可以提供最大的弹性,一个组织可以选择改善单一流程相关的问题点的绩效,或是可以使用多个领域以密切配合组织的经营目标。连续式表述也允许一个组织将不同的流程改善到不同的等级。但组织在选择上仍有一些限制,因为有一些流程领域是彼此相依赖的。

    假如你知道在你的组织中有需要改善的流程,以及了解CMMI中流程领域间的依赖性,对你的组织而言,连续式表述是一个好的选择。

    阶段式表述

    阶段式表述提供系统化结构化的方式,一次一个阶段达到以模型为基础的流程改善。达到每一个阶段可确保有足够的流程基础建设,可作为下一个阶段流程改善的基础。

    流程领域是以成熟度等级组织,并且对流程改善做一些推测工作。阶段式表述根据成熟度等级规定执行流程改善的书序,它定义一个组织有初始级到最佳化级的改善路径。达到每一个成熟度等级可确保有足够的流程基础建设,可作为下一个成熟度等级的基础,并且允许持续与渐进的改善。

    假如你不知道要选择哪一个流程开始进行改善,阶段式表述对你而言是一个好的选择。它给你一组特定的流程,针对每一个阶段进行改善,这组流程的决定,是来自十多年流程改善的研究和经验。

    阶段式与连续式表述的比较

    1.1比较每一个表述的优势,能够帮助你决定哪一个表述适合你的组织。

    连续式表述

    阶段式表述

    授予明确的自由度来选择最符合组织经营的目标与减少组织经营目标与减少组织风险范围的改善顺序。

    使组织有一个已定义且被证实的改善路径。

    增加每一个流程领域能力度透视度。

    专注一组流程领域,此组流程领域为每一成熟度等级的特征,提供组织特定的能力。

    允许对不同的流程执行不同等级的改善。

    以简单的形式总结流程改善结果-单一成熟度等级数目。

    一种新方法仍未有数据证明其与投资报酬率有关连。

    建立在一个相对长期的使用历史,包含个案研究与数据以证明投资报酬率。

     

    你的决策因素

    有三种类型的因素决定你选择的表述类型,他们是经营,文化与历史累计状况。

    经营因素

    当组织在经营目标上有成熟的知识,很可能有一个强大的流程映射到其经营的目标。这样的组织可能发现连续式表述有利于评估其流程,以及决定组织流程支援以及符合经营目标的程度。

    如果组织产品线专注于决定要改善跨组织的流程,它最好使用阶段式表述。阶段式表述将帮助组织在改善上选择要专注改善的重要流程。

    同一个组织也可能利用产品线来改善流程。那样的话,它可能选择连续式表述-每一个产品线有不同的能力度评审等级。这两种表述都是有效的。最重要的是考虑那些经营目标是你希望你的流程改善过程要支持的这些经营目标如何用两种表述调校。

    文化因素

    当选择表述与组织推展流程改善计划的能力有关时,要考虑文化因素。例如,如果企业文化是以流程为基础且流程改善有经验,或是有特定流程需要快速的改善,组织就可能选择连续式表述。若组织缺乏流程改善经验,可能选择阶段式表述,阶段式表述提供要发生的变更及顺序的额外指引。

    历史累积状况

    如果一个组织对其它模型有阶段式表述的经验,当使用CMMI时,希望继续使用阶段式表述,尤其是组织已经跨组织投入资源和推展流程,这与阶段式表述相关。会继续使用连续式表述亦是如此。

    为什么不是两种表述?

    不管是使用流程改善或评估,这两个表述是设计来提供相同的结果。这两种表述的CMMI模型内容几乎相同。因此,组织只要选择一个表述即可。

    事实上,组织可能发现此二种表述是通用的。组织很少完全的实行前述的某一种表述。在流程改善上成功的组织经常定义一个改善计划,此改善计划专注在组织的唯一需求,然后使用阶段式与连续式表述的原则。

    例如,选择阶段式表述并在成熟度第1级的组织,常常会在实行成熟度第2级的流程领域时,执行位于组织成熟度第3级下的组织流程专注流程领域。另一个例子,组织选择连续式表述,指引其内部流程改善工作,然后选择阶段式表述进行评审。

  • Participating in a meeting

    2008-10-06 09:26:06

    Participating in a meeting

     

    Getting the Chairperson's Attention

    (Mister/Madam) chairman.
    May I have a word?
    If I may, I think...
    Excuse me for interrupting.
    May I come in here?

    Giving Opinions

    I'm positive that...
    I (really) feel that...
    In my opinion...
    The way I see things...
    If you ask me,... I tend to think that...

    Asking for Opinions

    Are you positive that...
    Do you (really) think that...
    (name of participant) can we get your input?
    How do you feel about...?

    Commenting

    That's interesting.
    I never thought about it that way before.
    Good point!
    I get your point.
    I see what you mean.

    Agreeing

    I totally agree with you.
    Exactly!
    That's (exactly) the way I feel.
    I have to agree with (name of participant).

    Disagreeing

    Unfortunately, I see it differently.
    Up to a point I agree with you, but...
    (I'm afraid) I can't agree

    Advising and Suggesting

    Let's...
    We should...Vb  Obj
    Why don't you.... Vb  Obj
    How/What about...(Noun/gerund/noun phrase)
    I suggest/recommend that..SVO.

    Clarifying

    Let me spell out...
    Have I made that clear?
    Do you see what I'm getting at?
    Let me put this another way...
    I'd just like to repeat that...

    Requesting Information

    Please, could you...(tell/notify/inform) me/us…….
    I'd like you to... .(tell/notify/inform) me/us…….
    Would you mind... (/gerund/noun phrase)
    I wonder if you could...

    Asking for Repetition

    I'm afraid I didn't understand that. Could you repeat what you just said?
    I didn't catch that. Could you repeat that, please?
    I missed that. Could you say it again, please?
    Could you run that by me one more time?

    Asking for Clarification/more detail

    I don't quite follow you. What exactly do you mean?
    I'm afraid I don't quite understand what you’re getting at.
    Could you explain to me how that is going to work?
    I don't see what you mean. Could we have some more details, please?

    Asking for Verification/Confirmation

    You did say next week, didn't you? ('did' is stressed)
    Do you mean that...?
    Is it true that...?

    Asking for Spelling

    Could you spell that, please?
    Would you mind spelling that for me, please?

    Asking for Contributions

    We haven't heard from you yet, (name of participant).
    What do you think about this proposal?
    Would you like to add anything, (name of participant)?
    Has anyone else got anything to contribute?
    Are there any more comments?

    Correcting Information

    Sorry, I think you misunderstood what I said.
    Sorry, that's not quite right.
    That's not quite what I had in mind.
    That's not (really/quite) what I meant.

    Keeping the Meeting On Target (time, relevance, decisions)

    We're running short of time.
    Well, that seems to be all the time we have today.
    Please be brief.
    I'm afraid we've run out of time.
    I'm afraid that's outside the scope of this meeting.
    Let's get back on track, why don't we?
    That's not really why we're here today.
    Why don't we return to the main focus of today's meeting.
    We'll have to leave that to another time.
    We're beginning to lose sight of the main point.
    Keep to the point, please.(direct)
    I think we'd better leave that for another meeting.
    Are we ready to make a decision?

    Shall we take a vote?

  • Running a meeting

    2008-10-01 22:36:48

     

    Opening

    Good morning/afternoon, everyone.
    If we are all here, let's get started / start the meeting / start.

    Welcoming and Introducing

    Please join me in welcoming (name of participant)
    We're pleased to welcome (name of participant)
    I'd like to extend a warm welcome to (name of participant)
    It's a pleasure to welcome (name of participant)
    I'd like to introduce (name of participant)

    Stating the Principal Objectives

    We're here today to ...
    I'd like to make sure that we ...
    Our main aim today is to ...
    I've called this meeting in order to ...

    Giving Apologies for Someone Who is Absent

    I'm afraid.., (name of participant) can't be with us today. She is in...
    Unfortunately, (name of participant) ... will not be with us today because he ...
    I have received apologies for absence from (name of participant), who is in (place).

    Reading the Minutes (notes) of the Last Meeting

    To begin with I'd like to quickly go through the minutes of our last meeting.
    First, let's go over the report from the last meeting, which was held on (date)
    Here are the minutes from our last meeting, which was on (date)

    Dealing with Recent Developments

    Jack, can you tell us how the XYZ project is progressing?
    Jack, how is the XYZ project coming along?
    John, have you completed the report on the new accounting package?
    Has everyone received a copy of the Tate Foundation report on current marketing trends?

     Moving Forward

    So, if there is nothing else we need to discuss, let's move on to today's agenda.
    Shall we get down to business?
    Is there Any Other Business?
    If there are no further developments, I'd like to move on to today's topic.

    Introducing the Agenda

    Have you all received a copy of the agenda?
    There are X items on the agenda. First, ... second, ... third, ... lastly, ...
    Shall we take the points in this order?
    If you don't mind, I'd like to go in order today.
    skip item 1 and move on to item 3
    I suggest we take item 2 last.

    Allocating Roles (secretary, participants)

    (name of participant) has agreed to take the minutes.
    (name of participant), would you mind taking the minutes?
    (name of participant) has kindly agreed to give us a report on ...
    (name of participant) will lead point 1, (name of participant) point 2, and (name of participant) point 3.
    (name of participant), would you mind taking notes today?

    Agreeing on the Ground Rules for the Meeting (contributions, timing, decision-making, etc.)

    We will first hear a short report on each point first; followed by a discussion of ...
    I suggest we go round the table first.
    Let's make sure we finish by ...
    I'd suggest we ...
    There will be five minutes for each item.
    We'll have to keep each item to 15 minutes. Otherwise we'll never get through.

    Introducing the First Item on the Agenda

    So, let's start with ...
    I'd suggest we start with...
    Why don't we start with...
    So, the first item on the agenda is
    Pete, would you like to kick off?
    Shall we start with ...
    (name of participant), would you like to introduce this item?

    Closing an Item

    I think that takes care of the first item.
    Shall we leave that item?
    Why don't we move on to...
    If nobody has anything else to add, lets ...

    Next Item

    Let's move onto the next item
    Now that we've discussed X, let's now ...
    The next item on today's agenda is...
    Now we come to the question of.

    Giving Control to the Next Participant

    I'd like to hand over to (name of participant), who is going to lead the next point.
    Next, (name of participant) is going to take us through ...
    Now, I'd like to introduce (name of participant) who is going to ...

    Summarizing

    Before we close today's meeting, let me just summarize the main points.
    Let me quickly go over today's main points.
    To sum up, ...,.
    OK, why don't we quickly summarize what we've done today.
    In brief, ...
    Shall I go over the main points?

    Finishing Up

    Right, it looks as though we've covered the main items.
    If there are no other comments, I'd like to wrap this meeting up.
    Let's bring this to a close for today.
    Is there Any Other Business?

    Suggesting and Agreeing on Time, Date and Place for the Next Meeting

    Can we set the date for the next meeting, please?
    So, the next meeting will be on ... (day), the . . . (date) of.. . (month) at ...
    Let's next meet on ... (day), the . . . (date) of.. . (month) at ... What about the following Wednesday? How is that?

    Thanking Participants for Attending

    I'd like to thank Marianne and Jeremy for coming over from London.
    Thank you all for attending.
    Thanks for your participation.

    Closing the Meeting

    The meeting is finished, we'll see each other next ...
    The meeting is closed.
    I declare the meeting closed.

  • 看完了Reasearch-Based Design & Usability Guildlines

    2008-09-27 16:41:55

    标记一下!
  • Language for Meetings

    2008-09-27 09:44:34

    I - Introductions

    Opening the Meeting
    Welcoming and Introducing Participants
    Stating the Principal Objectives of a Meeting
    Giving Apologies for Someone Who is Absent

    II - Reviewing Past Business

    Reading the Minutes (notes) of the Last Meeting
    Dealing with Recent Developments

    III - Beginning the Meeting

    Introducing the Agenda
    Allocating Roles (secretary, participants)
    Agreeing on the Ground Rules for the Meeting (contributions, timing, decision-making, etc.)

    IV - Discussing Items

    Introducing the First Item on the Agenda
    Closing an Item
    Next Item
    Giving Control to the Next Participant

    V - Finishing the Meeting

    Summarizing
    Finishing Up
    Suggesting and Agreeing on Time, Date and Place for the Next Meeting
    Thanking Participants for Attending
    Closing the Meeting

  • Phone English

    2008-09-27 09:09:40

    Checking for Understanding

    Is that clear?

    Do you know what I mean?

    Do you follow?

    Are you following?

    Request clarification or Repetition

    sorry,I didn‘t quite catch that.

    sorry,could you repeat that please?

    sorry,I am not really following you.

    could you clarify that for me?

    Confirm understanding/Double checking

    OK(repetition)

    All right(repetition)

    Understood(repetition)

    Got it(repetition)

    Roger that(repetition)

    Copy that(repetition)

    DO you mean....

    So your point is...

    SO if I understood correctly....

    Language Problems

    I am not sure I understood you, could you please simplify/rephrase it?

    what was that word?

    could you spell that for me?

     

     

     

  • Live Style

    2008-09-27 08:51:17

    Simple

    Stressful

    colorful(interesting)

    leisurely

    lonely

    healthy

    economical-extravagant

    frugal-luxurious

    thrifty

    busy-idle

    tiring

    traditional

     

  • How to write better Test Cases(二)

    2008-09-09 15:32:57

    Handling challenges to good test cases

    Challenge: Requirements changes

    Response:

    1.     最好的降低的风险的方法是能够得到通知,在写case之前,或是每个项目状态会议,找出改变的需求引起风险最大的地方,找出那些case受到影响,哪些不会,险些不受变更影响的case

    2.     制定variables or "to be decided"case目录,以后继续填写。

    3.     让制定预算的人知道修订case的成本。

    4.     项目管理制定case修订的优先级。

    5.     发布不太正确的没有修订的case。让测试人员标出那些需要修改的case,制定计划的时候要考虑测试加维护的时间。

    Challenge: Schedule changes

    Response:

    1.     如果测试日期提前,让项目管理人员讨论出那些case受到影响,如同需求改变一样,让他们选择哪些方面可以冒险。

    2.     如果时间允许有12个星期培训新人并能进入项目中,可以添加人手,最好有导师可以指导他们工作。

    3.     改变写case的次序,优先写最先要测试的case

    4.     case简化成被测的需求和配置。制定多一些的时间测试这样的case

    5.     让一些人先测试,然后记录测试的过程。

    Challenge: Staff turnover

    Response:

    1.     新员工需要了解有文字记录的项目架构,进度,目标等,口头上的一些信息就丢失了。

    2.     新员工更多是关注软件的业务使用,然后才是需求和原型,写出的case较少。

    3.     要对新员工进行实用的培训,组好有实践的例子,并在早期对他们的工作进行检查。

    4.     让新员工参与需要较高技术的case

     

    Test case assets

    Protecting test case assets

    维护有价值case的标准:

    命名和编号的惯例;

    格式和文件类型;

    版本;

    Case的测试对象,如数据库;

    只读存储;

    受限访问;

    隔离备份。

    Test Case Checklist

    Quality Attributes

    o Accurate - tests what the descrīption says it will test.

    o Economical - has only the steps needed for its purpose

    o Repeatable, self standing - same results no matter who tests it.

    o Appropriate - for both immediate and future testers

    o Traceable - to a requirement

    o Self cleaning - returns the test environment to clean state

    Structure and testability

    o Has a name and number

    o Has a stated purpose that includes what requirement is being tested

    o Has a descrīption of the method of testing

    o Specifies setup information - environment, data, prerequisite tests, security access

    o Has actions and expected results

    o States if any proofs, such as reports or screen grabs, need to be saved

    o Leaves the testing environment clean

    o Uses active case language

    o Does not exceed 15 steps

    o Matrix does not take longer than 20 minutes to test

    o Automated scrīpt is commented with purpose, inputs, expected results

    o Setup offers alternative to prerequisite tests, if possible

    o Is in correct business scenario order with other tests

    Configuration management

    o Employs naming and numbering conventions

    o Saved in specified formats, file types

    o Is versioned to match software under test

    o Includes test objects needed by the case, such as databases

    o Stored as read

    o Stored with controlled access

    o Stored where network backup operates

    o Archived off-site

     

  • How to write better Test Cases

    2008-09-08 13:38:04

    How to write better Test Cases

    by Dianne L. Runnels

    Investing in test cases

    好的case包括三项:

     1. Productivity - less time to write and maintain cases

    2. Testability - less time to execute them

    3. Scheduling reliability- better reliability in estimates

    1. Productivity-书写和维护需要较少的时间

    2. Testability-执行test cases需要较少的时间

    3. Scheduling reliability-评估时可靠性更高。

    Looking inside test cases

    Cases包括的元素:

    1.     测试的目的或是描述出哪个需求被测试到;

    2.     测试方法;

    3.     测试步骤:应用程序的版本号,硬件,软件,操作系统,数据文件,安全接入,时间,逻辑或物理数据,及其他测试的前提提条件和设备相关的建立信息;

    4.     期望结果,输入或暑促;

    5.     附件(可选).

     

    Quality of test cases:

    case的质量是客观并可测量的。建立客观的checklist很简单。Cases必须要满足的质量标准:

    Accurate:根据case的描述测试。

     

    Economical:只是描述测试目的相关的步骤,不给出软件使用的向导。

     

    Repeatable, self standing:测试的每一条case,无论测试时间和测试者的结果都是一样的。如果一条case不同的测试人员得出不同的测试结果,就需要在case的建立和步骤上多做些工作,看case是否写得准确。

     

    Appropriate:考虑case执行的测试者和测试环境的可实施性。如果理论上要求的技术测试者不具备,case就需要搁置。

     

    Self cleaning: 能够回到测试之前的测试环境。

     

    Using test types

    Best uses for each type of case

    Step-by-step

    一步的用例,每步都不同;

    业务场景变化频繁;

    许多处理的规则;

    GUI接口;

    输入和输出很难表现在matrix上。

     

    Matrix

    有许多变量去填表格,相同的域,不同的值,输入文件;

    相同的输入,不同的平台,浏览器,配置;

    Character based screens;

    输入和输出能够很好的表现在matrix上。

    Choosing a test type

     

    错误观念一:Step-by-step test cases需要花费很多时间,承担不起。

    Reality:也不全需要很多时间写cases 细的颗粒度让cases更强健,维护更简单,如需要充分详尽测试某些功能,就要采用step-by-step test cases

     

    错误观念二:Matrix是最好的选择。

    RealityMatrix上必须有配置的信息,经常这些信息被遗漏,如果是不同的配置和种类,很难放到matrix上。

     

    错误观念三:高技术就是最好的,如果能实用自动化,就用。

    Reality:使用自动测试由好多因素决定。

     

    错误观念四:没有时间写手动的test cases,就采用自动测试。

    Reality:自动测试的用例要比两外两种的用例花费更长的时间。

    Improving test cases

    Improving testability of test cases

    Testability的定义就是准确的容易测试,容易的程度可以用执行测试的时间长短来度量,准确是指按照测试步骤执行,测试通过和不过的结果是正确的。

    Improving testability with language

    写测试用例要实用主动语态,告诉测试人员要做什么;

    An easy habit to fall into if we know a subject inside and out is to refer to the same thing in different ways.

    Testing can be accelerated if you build in structured fields for the tester to note inputs that will be verified later.

    Improving testability by controlling length

    Step-by-step 的用例的最佳长度是10-15个步,用例简短有以下几个好处:

    测试每步花较短的时间;

    测试人员不易犯错,或不知道如果执行而需要帮助;

    测试精力能准确估计测试需要的时间;

    测试结果更容易追踪。

    Matrix的最贱长度是执行差不多20分钟的时间。

    自动测试脚本的问题不是长度的问题,而是内容,维护和缺陷追踪的管理问题,业务场景或用例是否充分,是否可以载入不同数据可变量组合执行多次。

    Pros and cons of cumulative cases

    Cumulative cases 是指那些依赖于以前casecase。我们的目标是尽量保证每条测试用例的独立性,这个对时间安排测试很灵活,并且能减少维护时间,但是,弊端局势和其它的一些标准违背,比如保持case的简短,并且不重复。

    Improving productivity with templates

    Improving productivity with clones

    Improving productivity with clones

    Mistakes and challenges

    The seven most common test case mistakes

    1. Making cases too long

    2. Incomplete, incorrect, or incoherent setup

    3. Leaving out a step

    4. Naming fields that changed or no longer exist

    5. Unclear whether tester or system does action

    6. Unclear what is a pass or fail result

    7. Failure to clean up

    1.Case太长;

    2.Setup信息不完整,不正确;

    3.遗留了某个测试步骤;

    4.对改变的或是不存在的域命名;

    5.不清楚测试者或系统是否可以执行测试步骤;

    6.不清楚通过与否的结果是什么;

    7.不能回复到测试之前。

     

  • Key QA Document

    2008-08-04 14:50:29

    一.PRADThe Product Requirement Analysis Document is the document

    这个文档定义了产品的寻求,“什么”,开发人员用来构建功能规格说明,QA用来作为撰写测试策略初稿的参考。

    二.Functional Specification
        Function specification定义了如何实现各个功能,QA参考这份文档制定测试计划。

    三.Test Strategy
        Test strategyQA准备的第一份文档,整个项目需要不断的更新和维护,初稿需要在   PRAD批准前完成,还要发给PMreview

    Test strategy 包括以下标准:

    1)   Project overview:介绍产品

    2)   Project scope:产品的哪些模块要测试

    3)   Testing:使用的测试方法,测试优先次序,哪些测试要做,哪些不做,以及相关的风险。也包括了系统配置的略述和测试人员的分配。

    4)   Completion CriteriaRelease的标准

    5)   Schedule:定义项目的进度情况,包括PRADFunctional SpecTest strategy的完成日期,build 交付日期,Readiness reviewQA process reviewRelease board meetings的日期。

    6)   Materials Consulted:准备test strategy的的文档

    7)   Test setup:测试所需的硬件和软件,也说明了哪些部分不用测试(不过第三方软件)。

    四.Test Matrixtest plan

    Test matrixExcel的模板。

    五.Test cases

    六.Test Result by Build

    每个build的完成的test matrixResults summary 文档。

    七.Release package

    Release package QA准备的最后文档。每个release package会随着项目和team的不通而变化,一般都包括一下信息:

    1)   project overview:是项目的大纲,它的scope,测试过程中遇到的任何问题,QA建议release或不建议。是对test strategy的反馈,并说明哪些策略是成功的,哪些需要修正。

    同时project overview也是QA提出过程改进建议的地方。

    2)   Project PRAD:定义了哪些功能包含在产品中,如果产品没有PRAD,必须在project overview注明。

    3)   Functional Specification:如果没有Functional specification,必须在project overview中注明。

    4)   Test strategy:对整个QA测试过程的概述。

    5)   Result Summaries:每轮测试结果

    6)   Know Issue document

    7)   Installation Instruction

    8)   Open defects

    9)   Deferred Defects

    10)Pending issues:等待决议的bug

    11)  Fixed Defects

    12)  Closed Defects

    八.Readiness Review Meeting

    The readiness review meeting 是技术产品经理,项目开发人员和QA一起出席的会议,是在GCbuild之前开会。

    九.QA Process Review Meeting

    这个会议在Readiness Review meeting会议之后举行。

    十.Release Board Meeting

    技术产品经理和高级执行人员一起讨论产品的状况和发布的建议。如果Readiness meetingQA process Review Meeting是积极的正面的,这个会议可以不用开。这个会议是对产品发布之前的最后检查。

561/3123>
Open Toolbar