In a previous post, I discussed items that can help a tester provide value to his or her team: https://testingfromthehip.wordpress.com/2016/01/08/am-i-really-a-valuable-member-of-my-team/.

These ideas I brought forward, were more for someone in a tester ‘role’ and not necessarily the specific act of testing itself.

In this post, I want to address what the real goal of testing should be, and provide some ideas and suggestions about how our actual hands on testing can help. What prompted this post, was some recent interviews I had done with interviewees. Many struggled with giving examples of the value their testing provides. As testers, we should always be striving to provide maximum value from our testing. If we don’t know what this is ourselves, how can our organizations truly appreciate and value the work that we do?  To simply say things like ‘catch all bugs’, ‘execute all tests’, ‘release or regression test’, does not indicate what the point of our testing is, nor what value any of those activities help with.



在这篇文章中,我想来探讨下测试的真正目标应该是什么,并且提供一些关于我们亲自动手测试可以怎么做的想法和建议。我想写这篇文章的,是由于最近跟几位面试者所做的面试谈话深有感触而发。很多人都在努力提供各种事例,来说明他们的测试带来的价值。作为测试者,我们应该总是要努力让我们的测试提供最大的价值。如果连我们自己都不知道这是什么,那我们的组织怎么可能会真正的欣赏并珍视我们的工作呢? 仅仅说些向想“找出所有的bug”、“执行所有的测试”以及“发布或者回归测试”之类云云的话并不能表明我们测试的意义是什么,或者这些活动能够产生怎样的价值。


In my humble opinion, the main purpose of testing can be summed up as…

Help your team make an informed opinion about the perceived quality of the products and features that they own.”

That’s it. That’s all.

I like to call it: “Perceived Quality Assessment”.  I will be briefly touching on ideas and techniques that can allow us to help our teams do this better. Before I continue further, I want to state that the notion of the ‘perception of quality’ is not new, nor is it my idea. There are many thought leaders who have written about this before, like Gerald Weinberg for example. This post is not to take credit for the concept of perceived quality, but my own take on it, and how we can help.




我喜欢叫它:“感知质量评估”。我将会简要地介绍一些能够帮助团队更好的完成这项工作的一些思想和技术。 在我继续之前,我想要声明一下,‘质量的感知’这个概念并不是什么新玩意,也不是我自己创造的。之前已经有很思想领袖写过关于它的东西,比如Gerald Weinberg。这篇文章并不是想要通过感知质量这个概念来哗众取宠,只是讲述我自己对它的看法以及我们如何能够帮助。


Before I get to my list, let’s first talk about perceived quality. A team can never really know the quality of their products or how they will be perceived in the marketplace. They can know things like: the number of open defects, the missed requirements, the poorly written / thought out designs, or early feedback from demos. Our testing should be helping to provide our teams with as much information as we can, to make an informed opinion on their own perceived view of quality. This perception should help teams decide things like: when to release / not release, when to enhance, when to bug fix, when to scale back, when to move on, etc.



The following, is a brief list of items that can help us provide this information to our teams. I am only including 5 items in this list for the sake of brevity. There are many more, but I like these 5 as starters🙂

  1. Unknowns
  2. Risks
  3. Test Coverage – specifically what is not being tested
  4. Non functional testing like ‘quality attributes’
  5. Testing how customers and various personas use your features

Let’s talk unknowns. Testing should always be trying to uncover unknowns. This does not necessarily mean bugs. This can be anything we never thought of, may have overlooked, did not know about in the first place, or that may have dire consequences. This is all just information that your team needs to know about. Look hard, explore and find it. Your team needs you for this!


  1. 未知事物
  2. 风险
  3. 测试覆盖率 – 具体地说,就是什么东西没有被测试到
  4. 非功能性测试,像“质量属性”
  5. 测试客户和不同角色的人是如何使用你们的功能的



Let’s talk risk. Risk can manifest itself in many ways. As the aforementioned – unknowns for example. It can also be lurking in new bug fixes or enhancements that were added, other teams work that may impact yours, problems with integrating with other products or features, or really anything that has changed. Testing should always be monitoring these, investigating and exploring. This is something automation can do to a certain extent (by checking known conditions), but a good skilled tester can uncover those risky areas that automation does not know exist.



Let’s talk test coverage. One of my favorite topics that not many really understand that well. Without knowing what your testing (and automation) is covering and more specifically is not covering, is to me incredibly important information that your team needs to know. It’s great to have lots of testing in place, but your team needs to understand what that testing is all about and what is not being tested. This can roll up to the previous two topics I mentioned: unknowns and risk. Without understanding this, can a team really have an educated perceived quality assessment? I think not.

让我们谈谈测试覆盖。 我最喜欢的主题之一,很少人能够真正理解这一点。 不知道你的测试(和自动化)覆盖了什么,更具体地说,没有覆盖什么,这点对我来说是你的团队需要知道的非常重要的信息。 有很多测试自然是一件非常愉快的事,但是你的团队需要了解这些测试用来做什么以及哪些不需要测试。 这可以上升到我前面提到的两个主题:未知和风险。 不理解这一点,一个团队真能有一个受过教育的感知质量评估? 我想是没有的。


Let’s talk non-functional testing. Not that I am a fan of this terminology necessarily, but since it widely used I am using it here. A tester should always be testing to uncover potential problems with quality attributes that matter. These are also sometimes referred to as the ‘ilities’ of testing. These are critical in many customers minds when basing their perception of a software’s quality. Customers typically do not care that the requirements were met, that the acceptance criteria passed or that test cases have all been executed successfully. The perception of the quality of software can seriously be impacted by things like security, performance, accessibility, usability, and the like. Test for these. Your teams need to know this information.

让我们谈谈非功能测试。 这并不是说我是这个术语的爱好者,但由于它被广泛使用,所以我在这里使用它。 测试者应该总是测试以发现重要的质量属性的潜在问题。 这些有时也被称为测试的“质量(ilities)”。当基于对软件质量的感知时, 这些在许多客户的心中是至关重要的。 客户通常不关心需求得到满足,验收标准通过或测试用例都已成功执行。 对软件质量的感知可以严重地受到诸如安全性,性能,可访问性,可用性等的影响。 对于这些测试。 你的团队需要知道这些信息。


Let’s talk how customers use software. Since software can be highly configurable, we need testing to flush out potential problems that may occur when using it in differing or in some cases, unintended ways. Our testing should be factoring these in. Seek out information on how your customers use your products and the various personas involved. Test accordingly. Your teams need this information too.

Take a moment and think of the value you are providing with your testing. Are you really helping your team make informed decisions? Are you testing the right things, at the right time? Are you a lighthouse, shining light so your teams boat can avoid obstacles and problems on its way to its destination?  Let’s hope you are!

Thanks for reading. I hope something resonated with you. If anyone agrees or disagrees with anything I wrote, feedback is always welcomed.

Test well my friends!

让我们谈谈客户如何使用软件。 由于软件可以高度可配置,因此我们需要进行测试,以清除在不同或在某些情况下以非预期的方式使用时可能出现的潜在问题。 我们的测试应该考虑这些因素。了解客户如何使用你的产品和各种相关的角色的信息。 按照这样测试。你的团队也需要这些信息。

花一点时间,想想你提供的测试的价值。 你真的帮助你的团队做出明智的决定了吗? 你在正确的时间测试正确的东西吗? 你是一座发出闪亮光线,以使你的团队在驶向终点前能够避免障碍和问题的灯塔吗? 我们希望你是!

谢谢阅读。 我希望以上内容能够与你产生共鸣。 如果有人同意或不同意我写的内容,欢迎反馈。