发布新日志

  • QA grows

    2012-01-10 15:52:34

    Our lives are guided by natural rhythms that are particular to each of us and cannot be altered by force of will alone
    (我们的生命是由对我们每个人来说都是非常特别的自然规律所引导的，而且不能被个人意愿所改变。)

    What a QA engineer does?
    （一个测试工程师要干些什么？）

    Write test plans from the requirements, specifications and test strategies.
    （根据测试需求，规格和策略书写测试计划。）
    Use versioning systems to code test scripts. 
    （使用版本控制系统开发测试用例。）
    Create and perform. test campaign whenever it is necessary to fit in the overall planning.
    （总体规划测试活动，创建和执行测试活动，并在必要时进行调整。）
    Use bug tracking database to report bugs. 
    （使用可长期维持的数据系统对问题报告进行报告和跟踪。）
    Analyses test results. 
    （分析测试结果。）
    Report results to the QA manager. 
    （向测试经理发送可依赖的测试结果报告。）
    Raise an alert when an important issue is likely to put in jeopardy the whole project. 
    （当某个严重问题将会对整个系统产生严重影响前，对整个项目组发起警告。）

    What makes a good QA Engineer?
    （怎样才能做一个好的测试工程师？）

    1. Broad understanding of the product
    （深入了解整个项目）

    To test efficiently a product, the QA engineer must know it well enough. This sounds obvious must unfortunately, this is often under-estimated. Knowing well the product includes also knowing how end-users expect it to work. Again this may sound obvious but remember that the biggest part in testing is black-box testing. The QA engineer must have a "customer-focus" vision.
    （为了更加有效率的测试一个产品，测试工程师必须对产品有很深刻的了解。听起来这是很明显的一个人人皆知的道理，但是大部分时间都无法达到。除了产品知识，终端用户的体验也同样重要。尽管这也是个人人皆知的道理，而且是黑盒测试的主要组成部分。测试工程师必须拥有“客户观点”的测试策略。）

    But a good QA engineer must also know how the product is designed because the more you know the product; the better you're able to test it. However, the QA engineer will have to analyses the design only after his black-box test plan is completed. Indeed, knowing the design can widely influence the test strategy. It is better to first write the test plan with a high-level vision, then getting more and more information to refine the testing.
    （同样，好的测试工程师也必须对产品的架构比较熟悉，这样会有助于你对产品测试的更加完善。当然，对产品设计架构的分析一般是在黑盒测试计划设计完成之后。而且对产品架构的熟悉，可以有助于增强你的测试策略。一般来说，测试计划的初始版本都是都是比较泛泛的。然后会根据细节一点点的丰富。）


    2. Effective communication
    （高效率的沟通）

    Communication is an extremely important skill for a QA engineer. Of course, meetings (stand-up etc.) and status reports are part of the communication but more importantly.
    （良好的沟通是测试工程师最重要的技能。其中通过会议和状态报告进行交流是胃肠重要的。）
     
    A QA engineer must be particularly efficient in the following tasks: 
    （一个好的测试工程师必须在如下任务中非常有效率：）

    1）Directly communicate with both Development and Product definition teams. 
    （同开发团队和设计团队的直接交流）

    2）Has capability to communicate with technical and non-technical people. 
    （同有技术背景和没有技术背景的人进行沟通）

    3）Having the diplomacy to say "no" when a bug is considered as not fixed.
    （在对一个未被修复的产品错误具有外交策略的说“不”。） 

    4）Having the diplomacy to communicate a bug that without "offending" to the developer.
    （在和开发人与讨论一个产品错误的时候具有“无冒犯”意味的外交策略）

    Developers may often feel offended when a bug is submitted. This is 100% natural. This is why the QA engineer must have the ability to "criticize without offending". 
    （开发人员经常在一个问题报告被提交后具有“被冒犯”的感觉。完全出自绝对的人性自然。所以需要测试工程师具有“对事不对人”的技巧。

    5）Do not rely on "bug tracking" database for communication! 
    （不要仅仅依赖问题报告跟踪库进行交流。 ）

    There is nothing better that a bug tracking system to create "misunderstanding" between Development and QA teams. 
    （再也没有别的方式能比问题报告跟踪库那样给开发和测试团队带来那么多的相互误解。）

    3. Creativity
    （创新性）

    Testing requires a lot of creativity. Bugs are often hidden and just performing the obvious positive tests will have only a few chances to actually find bugs. Hence, the QA engineer must use its creativity to figure out all the scenarios that are likely to detect a bug. In other words, the QA engineer must be able to "see beyond the obvious".
    （测试需要创新的能力。如果仅仅通过常规的正向测试，很难发现那些隐藏的问题。所以，测试工程师要用自己的创新能力去是设计更多的非常规场景来发现问题。简单的说，测试工程师要能够看到现象背后隐藏的真相。）


    4. Development knowledge
    （开发背景知识。）

    Quality Assurance requires knowledge about software development for two basic reasons: 
    （测试人员需要知道软件开发知识的原因一般有如下两个：）

    1） Development capabilities are required to eventually code automated tests 
    （自动化测试需要具有开发能力）

    2）If you know how to develop, you have better ideas on what is "dangerous" to code, so what to test more thoroughly 
    （如果你知道如何去开发产品，那么就更容易的知道哪里会有危险代码，从而更加有针对性的进行测试。）

    5. Driving for results
    （结果驱动）

    A good QA engineer never forgets that the ultimate goal is not only to find bugs but also have them fixed. Once a bug has been found and has been "acknowledged" by the development team, the QA engineer may be required to "convince" people to fix it.
    （一个好的测试工程师要记住测试的最终目的不是发现问题而是保障隐藏的问题被修复。一旦一个问题被发现和得到开发团队的确认，那么测试工程师就要保证有人完全修复这个问题。）


    6. Additionally
    （其他技巧）

    Getting a nice automation framework with smart tools does not bring anything if it does not find any bug at the end. 
    （引入一个漂亮的自动化测试框架和高科技的测试工具，并不意味着就能发现更多的软件缺陷。）

    Ask yourself if the automation is going to help to find more bugs and when.
    （如果自动化测试能够帮你发现更多的缺陷，那就要问问你自己为什么漏掉了。）

    Prioritize your testing tasks on the only important criteria.
    优化你的测试基于这些重要标准：
    How many bugs is this likely going to find? 
    （有多少问题可以被这种测试发现？）
    How major will be the found bugs? 
    （有多少严重的缺陷可以被这种测试发现？）

    Detecting thousands of cosmetic bugs is irrelevant/useless - and often easy - until all major/show-stopper bugs have been found。

    （发现上千的无关紧要的问题是没有任何意义的，而且这样一般是很容易的。只有所有的严重和阻塞性的问题被全部发现后，测试才有意义。

    查看(542) 评论(0) 收藏 分享 管理

  • How to automate your project

    2012-01-10 15:47:08

    Now, more and more requirements come from client that they want to make the testing to be automated, but how we start it? Here are some tips to share with you:

     

    Automation design process

    Analyze Automation Type

    Identify Automation Scope

    Case design methodology

    Case structure

    查看(355) 评论(0) 收藏 分享 管理

  • How to make a Test Plan

    2012-01-10 15:43:58

    What should be included in a test plan? In general, they are: goals, scopes, methods, schedules, resources, templates, standards, reports.

     

    The goals of a test plan are the reasons and results that you need to do a testing: 

    1.          Completion rate

    2.         Error-free rate

    3.        Time on Tasks

    4.         Subjective measures

    5.        Start/complete criteria

    6.        Approach

    7.          Output

     

    The scopes of a test plan are that you will test: 

    1.          Task list

    2.         Fail/pass scenarios

    3.        Test depth

    4.         Test width

    5.        Methods

    6.        Metrics

    7.          Acceptable/unacceptable issues

    8.        Trainings

    9.        Release documents

    10.     Reports

    11.       Priority and severity sets

    12.      Test methodology

    13.     Test tools

     

    The methods of a test plan are the ways to do test: 

    1.          Test case development methodology 

    2.         Manual testing methodology

    3.        Auto testing methodology

    4.         Process to review test case

    5.        Process to manage test case

    6.        Process to execute test case

    7.          Process to report bug

    8.        Process to fix bug

    9.        Process to verify bug

    10.     Process to generate reports

    11.       Process to generate documents

     

    The schedules of a test plan are the time sheets to set milestones and checkpoints:

    1.          When the design docs ready for test case development

    2.         When the test case ready for test case review

    3.        When the test environment ready for test

    4.         When the milestones get the deadline

    5.        When to start smoke testing

    6.        When to start functional testing

    7.          When to start regression testing

    8.        When to deploy a new build

    9.        When to verify bugs

    10.     When to GA build

    11.       When to close the testing               

     

    The resources of a test plan are what you can use to do the testing: 

    1.          What human resources that you need

    2.         What hardware resources that you need

    3.        What software resources that you need

     

     

    The templates of a test plan are used to generate each required documents in the testing: 

    1.          Design documents template

    2.         Test outline template

    3.        Test case template

    4.         Bug templates

    5.        Reports templates

    6.        Release templates

     

    The standards of a test plan are needed to follow in the testing: 

    1.          Test case development standards

    2.         Test case execution standards

    3.        Bug actions standard

    4.         Release standard

     

    The reports of a test plan are exaction trace of the testing:

    1.          Phase reports

    2.         Build reports

    3.        Daily reports

    4.         Weekly reports

    5.        Monthly reports

    6.        Release reports

    7.          Process reports

    8.        Management reports

    9.        Resources reports

    10.     Progress reports


    (Objectiva QA forum, Eddie Zhang)

    查看(681) 评论(0) 收藏 分享 管理

  • “Powerful” flags in Bugzilla

    2012-01-10 15:32:22

    Although Bugzilla has already provides powerful search and report function, we still want to get some special information from the Bugzilla. To get this, the additional flags sound powerful than we expected.

     

    Here are some examples to show these powerful flags:

    Example #1:

    We can search out all bugs that have been set to REOPEN status by search, but how to know which bug is reopened by code fixing failed?

     

    We set a flag named “FailedinQA”. So when the bug was reopened by a failed code fixing, we marked this flag to “+”. So, we can easily tell these actually failed bugs.

     

    Example #2:

    There are bugs were found after one round test case execution. We want to know all these bugs that still working on previous build.

     

    We set a flag named “Regressed”. When the bug is verified working on previous build, the flag was set to “+”. Set to “-“means this is a new feature bugs or it not working on previous build too. So, the “-“marked bugs are missed one. We should take more regression test on these areas.

     

    Example #3:

    There are some bugs need to log into release note. So, technic writer need a way to search out all bugs easily.

     

    We set a flag named “ReleaseNotesReq”. We marked all these bugs to “-” for the technic writer. The writer set to “+” means it has been updated into release notes.

     

    Example #4:

    Sometimes, the created bug is not create for a real issue, but created for an opening discussion. So, BA, Dev., and QA can work together on it for enter comments as logs.

     

    We set a flag named “InternalCommunication”. Set to “-“means it still opening. Set to “+” means is closed.


    (Objectiva QA Forum - Eddie Zhang) 

    查看(551) 评论(0) 收藏 分享 管理

  • 上传的相关文档

    2007-08-06 13:51:54

    1. 如何在window平台安装bugzilla和testopia组件

    2. Testopia的中文用户手册,自己翻译的.

    3. 现用的测试用例的模板

    查看(577) 评论(0) 收藏 分享 管理

  • 用于bugzilla的format

    2007-08-06 13:38:54

    Environments: (optional)

    OS: Window XP SP2

    Browser: IE 6.0 SP2

    JRE: 1.6.1

    Others: XXXXX

     

    Build Version

    Application: 67306

    DB2: XXXXX

    Others: XXXXX

     

    Pre-Configuration:

    XXX

     

    Test Cases Path: (If the bug was found in your cases execution)

    File: XXX_Cases.xls

    Tab XXX

    OR

    Functional Area: (If the bug out of your cases)

    XXXX

     

    Error Case number: (optional)

    XXXXXXX

     

    Reproduce steps:

    1.       Login to XXX with use/password

    2.        

    Expect Result:

     

    Actual Result:

     

     

    Attachment:

    1.       The log file

    2.       Screen shot

    3.       others

     

    查看(434) 评论(0) 收藏 分享 管理

1468/8<12345678
Open Toolbar