原文译文操作

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.

在之前的一篇文章里,我讨论了一些可以帮助测试者给他的团队提供有价值信息的一些建议
https://testingfromthehip.wordpress.com/2016/01/08/am-i-really-a-valuable-member-of-my-team/.

我提出的这些想法更多的是针对一个处于测试者“岗位”的人,而并不是测试这个具体动作本身。

在这篇文章中,我想来探讨下测试的真正目标应该是什么,并且提供一些关于我们亲自动手测试可以怎么做的想法和建议。我想写这篇文章的,是由于最近跟几位面试者所做的面试谈话深有感触而发。很多人都在努力提供各种事例,来说明他们的测试带来的价值。作为测试者,我们应该总是要努力让我们的测试提供最大的价值。如果连我们自己都不知道这是什么,那我们的组织怎么可能会真正的欣赏并珍视我们的工作呢? 仅仅说些向想“找出所有的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.

修改翻译

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!

修改翻译

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.

修改翻译

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!

修改翻译