南方的大雪持续了好久，很多人受灾，很多人因此回不了家，停电停水。早上来到公司看到一个湖南的同事非常焦急。因为天气家里停了电，停了水，电话手机都断了，想了很多办法才打听到家里的情况。蔬菜比肉买的贵。看到她焦急的样子。真心的希望南方的天气早点好起来，大家的生活可以恢复正常，可以及时回家和亲人团聚。

Saw a good article on the website http://www.sqablogs.com/portal.php. share it here for us. I found this website in our 51testing forums.

Software testing is about executing a set of test cases which are well documented and probably anyone after a few rounds of rehearsal can do it well. While practitioners would not agree with this since in practice, you dont find all the bugs from documented test cases. At most you document the basic workflows or the core cases but its not realistic to assume that one would be able to document all the test cases. Typically you would document the ones which are most important, so the big questions is that ‘how much to document’.

I am sure all of us have been into a situation where we found a bug at some crucial time and then everyone would want to look at test cases and while the witch hunting is going on, you as a test manager wonder that we never document everything. So after testing for many years and then managing a small team and complete products, here are some tips on test-case documentation.

1. Divide the functionality-area into sub-area keywords rather then writing sentences. So if one has to test a login screen then start with listing sub-areas as Albhabets, Numerics, Alphamuerics, Blanks, Special Chars, High Ascii Chars, Unicode Chars, UI guidelines, Button etc rather then listing cases as

- Enter a name comprising of ‘Albhapbets’ and click OK and then see….blabla.

Its not worth it. While testing you would not benefit from long sentences and its assumed that the idea is to cover everything and find bugs rather then write well made sentences. The downside is that over time, it may not make sense as functionality area changes hands. It would be difficult for a new person to understand the context from just keywords but the cost of writing clear-complete sentences is not worth the pain and need.

2. Have check-lists of first level actions. So make a list of all the buttons which you can click and while executing just keep ticking off from the list.

3. Dont write simple straight cases or the ones which you know would get covered as you do the complex ones. I have seen so many times where you would see loads n loads of these simple cases. They are not worth documenting, esp in a bulky format.

4. Keep the format simple. Dont add too many fields like Title, Step By Step Procedure, Area, Sub Area, Kind of Test, OS, Milestone etc etc. Think and prioritize a list based on your goal. The goal is to find bugs in areas which users are going to exercise.

5. Dont go over-board in keeping results. Though for a fast changing project, it might help to isolate a break, it might not be worth it over a long period of time.

6. Keep updating the test case document, not only by adding cases but by also removing the unwanted ones. Keep it trimmed and live and meaningful.

    好久没来打理自己的空间了！项目不忙，有很多区域还没有ready，不能测！就偷闲来写几笔。：）

    适逢年关，各个公司跳槽换工作的XDJM肯定不少。最近身边的几个关系不错的同事离开了公司选择了新的岗位。所做项目和之前在公司的项目有很大的差别，可以说是跨了一个领域。最近一直在思考一个问题。我们如何才能保持自己的竞争力，为自己留个后路。本人所在的公司是一家外包公司，大家知道一般外包公司的项目特点。哪天客户把项目转移了，我们就没有项目做了。不能在一棵树上吊死吗，呵呵！像任正非写的文章《华为的冬天》一样，我们也要想到自己的冬天。看了很多关于测试工程师的招聘信息，除了项目的本身具体内容的要求，其他的都类似。为了提高自己的竞争力，或者说保持竞争力。我们需要不停的学习，提高。对于我们测试人员，我想了以下几点。

1. 计算机编程基础：不要把自己上学时候学得东西丢掉。大家应该都能体会到，大部分的测试人员的代码能力都不强。对于我们测试的工作，虽然不要精通。但是我们需要有代码思想。所以没事的时候把大学学的c,数据结构再复习一下，绝对有用。还可以自学些语言。

2。CMMI及软件工程相关知识：现在中国是个公司就在搞CMMI,了解学些这些知识没错。测试是软件工程中很重要的一环，质量对于测试来讲很重要。

3。学习了解一种自动化测试工具

4。测试理论：熟练掌握测试的相关理论。如测试的类型，bug的生命周期，bug管理，测试用例的编写等。

5。项目管理知识（可选）：如果大家要做项目lead的话，这方面的知识是比不要可少的。

    做测试时间长的朋友都应该知道，所有的项目都有很多共性的，他们的区别就是细节不同，那些细节对于不熟悉的人，肯定会有相关的培训，有在学习熟悉的过程。对于公共的部分我们掌握好了，换了新项目，所需要做的就是学习细节的东西。呵呵，写了这多自己也需要按照这个执行。以上是自己的一些想法和观点，也许有些和大家的不同。

   由于公司计划年底进行CMMI4的过级预评审，最近天天在进行“中国式”的CMMI工作：大量的准备更新文档。在四级中有一个比较重要的方面就是度量与分析。工时，项目规模，劳动生产率。。。bug分析也是一个很重要的方面，一般在里程碑点的时候需要做着方面的工作。

   一般来说我们对于bug有不少分类的方法。

   按照功能区域，模块来分。

   按照严重程度来分，一般情况下bug的严重程度分为4等，1-Low，2-Medium，3-High，4-Catastrophic。

   按语言来分，这种bug发生在那些语言上面。按目前bug的状态来分，open, fixed/resolved,closed。

   按bug被处理的方式来分. code change, not a defect, will never fix, specification change

   不管大家用什么方法来分，定期的对之前报过的bug进行分析汇总，对我们的测试会有很大的帮助。将收集的数据生成相应的chart,柱状图，饼图随你选择。

   比如我们按照bug被处理的方式来分，发现近一个月之内上报的很多bug，都被开发人员标为not a defect.这个时候我们需要考虑分析一下了，为什么有这莫多的not a defect的bug。这里面的原因有很多: 开发人员对于需求文档的理解不透澈，有歧义.测试人员对需球的理解有问题，测试执行过程出现了问题。对于这些进行了分析之后得出原因，可以就此对下阶段的工作进行相应的调整。

  如果我们按照功能区域来进行分析。可以清晰地看到各个功能区域存在的bug现状。对于发现bug少的区域，我们可以在下阶段的测试中侧重对该区域的测试安排，在这区域做更多的ad hoc测试，发现没有覆盖到问题。对于bug多的区域还可以进行“嵌套”式的分析，从另外一种方向进行分类。

  做这些数据分析，可能会花费一定的时间，但是回报绝对是大于付出的，呵呵！

    最近的好消息似乎不少，除了个人的，所在城市也不少。武汉城市圈刚被国家发改委批注为综合实验新区，美国领事馆明年年初即将开馆，etc.这些好消息预示着武汉的发展会越来越好。

   似乎这些消息对我来说不是最好的。前天的报纸报道HP高层到武汉考察有意将其全球测试中心放在这里，完成其来自全球的业务，规模在千人以上。看到这个消息眼前一亮阿，呵呵。我们又有了更多的机会，更多的奔头。如果HP最终决定将其定在武汉，那末它是继富士康，EDS,华为，微软，IBM又落户武汉的著名IT企业。

   说到这里不禁让我想起刚刚毕业的时候，大部分武汉本地高校毕业生的去向。武汉有7所部署重点高校，还有其他省级重点高校等。但是培养的毕业生大部分选择离开了武汉到其他的城市。原因大部分为好公司太少，工资太低。

   目前大批公司到武汉建立分之结构，这里的消费低，人力成本低，高校多可以为他们提供大量的人才，地处中部，交通便利。湖北省武汉市也在出来大量的优惠政策支持高科技企业的发展。曾经看到过相关的文件，那个政策优惠的阿，相对公司盈利来讲几乎让你租个写字楼不花钱。软件园在疯狂的盖楼，旁边还安置了海关，公安局。在武汉的同志们，努力奋斗，机会多多，看准时机出手吧！呵呵！

   开辟了这一片田地，但是一直没有开写！今天决定要好好打理一下，写下自己每天的点滴感想。

   刚刚在客户哪里有了自己的帐号，开始了独立的沟通，独立带项目。两年的努力，自己的目标终于实现了，实现了自己从一个tester到Test Lead的转变，自己身上的责任更重了，自己的一句话也许就代表了公司的实力和形象。刚刚弄好CSD,CDP帐号，就收到了mail. 更新CSD site上的文档，短短的一句话，忙了一上午，任务完毕。写了回复的邮件，来来回回看了三遍（虽然对方是个中国人，但是人家也是客户阿，呵呵），紧张的点了发送。既紧张又兴奋的等待回复。

“Thanks very much for the updating. And please go ahead to update the Readiness Tool.”收到了这样的回复。Ok,放心了，第一次平安通过。更新了readiness tool， 又一次紧张的回复，这次的等待心里就平静了许多。

“Could you please also update the TSS links in the web? Thanks!”哎，还是漏了个小细节。看来“再好的软件也会有bug，只是你没发现”呵呵。赶紧更新了回复。又一次等待。

  这次等来的不是错误，而是问题，还好不是错误！解答了问题，发送，等待。

“In this case, I will ask our asset test engineer first, then decide. Please wait for my notice.”简单回复。

   今天的邮件骚扰到此为止。总体还行，80分吧。唯一的不足就是漏掉了一部分没有更新，这个错误是可以避免的！所做的就是再细心些，对CSD项目结构再熟悉些。今天的经历又让我找到了当年做GL时的感觉和目标，下次提交结果一定要不犯错或者降低错误数量。时刻准备着被邮件“骚扰”