Subversion perfect software: software testing need to know a few things (study notes 3)

Fourth, test, and modify the software BUG What is the difference? (Chapter 4)

  Test can not be defined properly, it may result in endless debate. Let testers or developers do not know what the nature of their work, but also lead to the failure of the project.

  1, the division of large institutions and small institutions task

  In a small organization or a small company, a person can be simultaneously played many a variety of roles, we can identify problems, identify problems, locate, determine the importance, modify and solve the problem.

  In a large organization or company must define the specific responsibilities and the division of testing and development, so as to avoid conflicts and failed projects. When the individual mandate covering the test team, development team and support team, we need clear who is responsible for what work. Only a clear division of work can be improved for the entire project, increase the likelihood of project success.

  2, time management rules heuristics

  No one can take your project to waste anyone's time.

  By this principle, there are two applications:

  1) tester before informing the developer, time study of single defect is limited to 10 minutes or less

    After 10 minutes, if the problem defect or defects caused by still do not understand, you can request the help of others.

  2) Do not waste time to make subtle distinctions

    Find and identify not have a very clear distinction between defects, do not waste time arguing whether a particular activity to pinpoint the problem and let the testers and developers have invested come together to complete the work. Such as the establishment of discussion groups, or positioning problems with testers and developers.

  3, relevant knowledge

  1) locating defects takes time, do not estimate locate the wrong time.

  2) Every time a task switch will lose some time if the number of tasks you want to switch up to five, might not complete any work. When the staff assigned to work, do not feel free to add work, it is best not more than three.

  3) If you need reliable test, we need to focus on, it can not be used as a low-priority work is interrupted.

  4) can not ask testers to identify each fault, if the test personnel have the appropriate time, we can arrange to help developers. But essentially this work duties or developers.

  5) does not require developers to locate each problem, this is entirely the work of developers.

  6) modify the procedure is completed, if you do not hurry, be sure to re-test (regression testing) .

  7) When designing and building codes need to consider testability, which can significantly reduce the time and effort required for testing.

  8) of intermittent defects to put a lot of effort to track, rather than use it as an excuse to postpone and postpone the test changes. You can use the defect information already available, and do not waste time testers, let testers continue to test, go to "revive" the problem.

  9) the work of testers to include not only determined by the test cases, should be converted to thinking in accordance with the testing activities. For example, the tester should be able to build test cases according to the project, and execute test cases. ? ? A need to consider this.

  10) When has these features, the company may need to change: 1 think that testers need to identify and locate defects; 2 developers to think Songcha delivery of water works testers...

Fifth, the meta-information about the quality of software products have? (Chapter 5)

  The purpose of software testing is to provide information about the quality of products, this chapter provides a lot of meta information that caused the failure, by observing and identifying meta information, can significantly improve the efficiency of testing and reduce costs.

  1, all kinds of information about the quality of products

  1) No Specifications

  We want to test the product, you need to have the test specification for content. If you can not find these specifications, the content will need to be tested were questioned.

  2) testers no record of test problems in the non-own group

  3) it is the wrong application testers may test

  4) the worst because more components takes time, so does the worst component testing

  5) Information provided ignore testers

  6) for fear of angry developers not to report defects

  7) because developers a relatively high level without testing

  2, relevant knowledge

  1) Test reports do not include all relevant information, which contains at most only half of the information you need

  2) testing and implementation process to deal with the situation implied by direct observation to verify the test report

  3) test only shows something failed, or did not fail under certain conditions. Testing is not about confirmed, but the evidence and reasoning.

  4) there is no value in the case file is not in use. If the document to the wrong, even worse than worthless.

  5) If you modify the defect is slower than the growth rate of defects, can stop making new defects, then repair those defects already.

  6)有效的测试是,既要集中精力又要有目的。没有目的地集中精神,看似不错,但不会取得多少成果。

  7)对发现故障应进行记录,不应该进行忽略。为了“节省时间”而不记录故障情况,会导致事与愿违的效果。

  8)不应该过度记录发现的每一个缺陷。因为记录每一个缺陷的代价是很高的,对于某些缺陷,不用准备正规的详细说明,而是将相关信息放到电子邮件中,或在会议中进行提及,或向开发经理进行口头报告。提高报告的成本会提升测试人员自我审查的可能性。有些类型的缺陷可以作为一个记录按批提交。

  9)某个模块或者某个项目,已经发现的缺陷越多,将要发现的缺陷就会越多。完美的开发人员是不存在的。

  10)模板保证了文档的形式是标准的,可能会掩饰一些不可靠的信息。

六、如何应对由于不同人因恐惧造成的防卫反应?(第6章和第7章)

  测试的目的是提供信息,但人们常常会将这些信息看成某种威胁。测试很容易触及人们的恐惧点,我们要做的就是识别每个人表现出的防卫行为,然后主动的去应对,这样才能避免混乱的情绪而影响测试工作。

  防卫反应的类别和特征

  在我们的自尊程度比较低而某些交互触发了生存规则的时候,我们会采取防卫措施。因为如果生存规则被打破,会导致我们对自身安全产生强烈的恐惧感。而测试非常容易触及这样的生存规则。比如测试发现了一堆缺陷,项目无法顺利完成可能会触发自己的生存规则,说:“我必须按进度工作”或者“我必须实现承诺”。

  心理学家将这些防卫错误分成六个类别:压抑、合理化、投射、转移、过度补偿和强迫。

  1、压抑无法接受的事物

  压抑就是不承认或者忽略我们认为无法接受的想法、感觉和记忆。压抑的一个例子:鸵鸟将自己脑袋埋到沙子里:“如果我看不见,那就不存在”,掩耳盗铃。

  2、让不可接受的事物合理化

  合理化就是试图让没有意义的、愚蠢的或者是无理的举动看上去合理。例如,一名开发人员声称:“我在程序中留下错误就是为了检验测试人员是否工作得很好”就是在进行合理化。对于测试人员,应如何引起开发人员的注意而不让他们感到威胁增加?他可以通过解除掉开发人员的防卫(用合乎逻辑的过程进行解释),然后说明需要做出一个修复。

  3、将自己的负面品质投射给其他人

  负面的投射,就是批评其他人具有我们自己身上也有的某种并不希望的品质。比如,如果我私底下怀疑自己有些自私或者专横,我可能会在其他人身上找出这些负面品质,抱怨说:“他很贪婪”,或者“他很有控制欲”。

  4、转移指责从而免除自己的责任

  转移就是指责并非问题真正来源的人或事,从而免除我们自己的责任。例如,“我的铅笔断了,所以我没法完成家庭作业。”。当开发人员面对测试人员提出的“无法接受”的问题时,可能将抱怨向测试人员,向其他开发人员,向他们的经理,向整个世界进行转移。

  5、对自己的不足进行过度补偿

  过度补偿就是为了弥补某些真实的或者是想象的个人不足而做得过了头。例如,某个人因为觉得自己不够可爱而变成一个工作狂。

  6、我们觉得失去控制时开始强迫自己

  强迫就是无法摆脱某种负面的行为模式。例如,某人不允许对已定义的过程有任何微小的偏差。

  7、相关常识

  1)在人们害怕时,需要注意观察,很容易看出别人采取的防卫机制。

  2)不能制造恐慌的环境,因为报信的人带来了不想听到的消息而指责他,你将再也无法听到你应该听到的信息了。

  3)一个人的强迫行为,往往会导致其他人产生恐惧和防卫行为。最优的做法应该是努力让自己的行为合乎道理。

  4)学会带着赞赏的态度听取异议和辩解。试着在反对观点中寻找和尊重那些有价值的内容,实际上总会有些内容是有价值的。争论者辩解说“太难修复了”,也许是为了表示,“我不知道如何才能快速或者廉价地修复它,我也不确定我花时间在这里是否是个好主意。”

  5)防卫行为是人的普遍反应,在任何地方都可能发生。

  如何应对防卫反应

  对于应对防卫反应,不需要了解他们为什么这样进行防卫,需要通过建立合理的规则和指导原则来纠正这种情况。规则:首先不将对方的行为定义为防卫性的,但按照它是防卫性反应来看待,看看它是否会在温和的测试下表现出来。

  1、确定恐惧

  首先,需要了解防卫性反应是受恐惧驱动的。尝试一下能否确定对方害怕的是什么,再看看在找到方法减轻那种恐惧之后会怎么样。 

  2、使用危机思维

  危机思维:在顺境中要有警惕心。对某些防卫反应用危机思维来思考,就是,某些防卫反应可能就是无效的论点,可能就是一些个人攻击。这种情况下,通过使用逻辑方法找到比人论点是否是基于逻辑。

  3、实践,实践,再实践

  通过足够的时间,可以更好的辨识别人的防卫反应,并加以解决。例如,一些常见的防卫反应说法:“这是为了用户自身利益”,“这是按照我设计的方式工作”,“修复它“太冒险””。

  4、相关常识

  1)要考虑差异,每个人都有自己的规则。每个人在自己的规则受到威胁的时候都会感到恐惧。规则不同,做出的反应也是不同的。要平等地对待每个人,但不一定要采取完全相同的方法。

  2)不要对别人说他们不关心质量。每个人都是相当关心质量,他们也许不了解如何获得高质量。每个人对质量的看法都是不一致的,要教育他们,使得大家对于质量的理解统一。

  3)需要通过实践来学习如何辨识和有效地应对防卫反应。如果出了一些错误,让自己稍微放松一下。

  4)如果你是经理,需要处理其他人可能影响他们工作完成情况的反应就是你的职责。

 

Guess you like

Origin www.cnblogs.com/chengabc/p/11631149.html