目录
How to Think Beyond Traditional Testing Boundaries in Exploratory Testing
How to look product from different perspectives?(如何从不同的角度看产品?)
How to Think Beyond Traditional Testing Boundaries in Exploratory Testing
如何超越探索性测试中的传统测试边界
“I really appreciate your concern for the product and making us helpful in an understanding end-user perspective. It’s going to be very helpful. Thanks for the good work and keep it up!!!”
“我非常感谢您对该产品的关注，并使我们对最终用户的理解有所帮助。 这将非常有帮助。 感谢您的出色工作，我们会继续努力！“
This was the last e-mail of an email chain with 21 emails from our client. It was midnight, and our product release was delayed due to a critical bug we found. You might think, what is new in that? It may happen many times. But, this was really different as the critical bug we reported was not a result of any documented test case.
这是一封电子邮件中的最后一封电子邮件，其中有21封来自我们客户的电子邮件。 那是午夜，由于我们发现了一个严重的错误，我们的产品发布被推迟了。 你可能会想，这有什么新鲜的？ 它可能会发生很多次。 但是，这确实不同，因为我们报告的关键错误不是任何记录的测试用例的结果。
After completing regression testing for the last time that evening, I was just playing with the product. What does that mean? You are free to do what you are not supposed to do. Based on my experience and project knowledge, I had some ideas on how to test the product apart from our typical test repository, called Exploratory Testing.
在那天晚上最后一次完成回归测试之后，我正在玩这个产品。 那是什么意思？ 你可以自由地做你不应该做的事情。 根据我的经验和项目知识，我有一些关于如何测试产品的想法，这不在我们的典型测试库中，称为探索性测试。
The exploratory testing done found a critical bug related to a server hang issue while doing something unexpected.
完成的探索性测试发现了严重错误，它与在意外操作时服务器挂起问题有关。
Being a fan of exploratory testing, I love to explore the product in different ways. For me, the definition of software is:
作为探索性测试的粉丝，我喜欢以不同的方式探索产品。 对我来说，软件的定义是：
“It should do what it is supposed to do, and it should not do what it is not supposed to do.”
“它应该做它应该做的事情，它不应该做它不应该做的事情。”
Limiting testing boundaries to check whether products that are supposed to work are working makes you an incomplete tester. In fact, a tester’s life starts when documented regression testing ends and results are updated. Looking at products from different perspectives and understanding end-user requirements in different scenarios make a big difference. So today, let’s understand together, how that difference can be made:
限制测试边界以检查应该正常工作的产品是否正常工作，会使您成为一名不全面的测试人员。 实际上，当记录的回归测试结束并且结果更新时，测试人员的工作就开始了。 从不同的角度看待产品，了解不同情况下的最终用户需求会产生很大的不同。 所以今天，让我们一起理解，如何做出这种差异：
How to look product from different perspectives?(如何从不同的角度看产品?)
#1. Understand customer/end user(＃1.了解客户/最终用户)
Software testing is all about checking the quality of the product in terms of customer satisfaction. How do you know a customer’s viewpoint? The answer is simple – you have to be the customer. OK, let me make a correction. Being customer will not be enough. You need to understand how the customer wants to handle the product. No two customers who bought same raw materials will prepare the same recipe. Yes, the product we develop/deliver is a raw material for customer’s businesses and they have a different mindset while using it.
软件测试就是在客户满意度方面检查产品质量。 您如何了解客户的观点？ 答案很简单 - 你必须是客户。 好的，让我纠正一下。 做客户是不够的。 您需要了解客户期望如何操作产品。 没有两个购买相同原材料的客户将准备相同的配方。 是的，我们开发/交付的产品是客户业务的原材料，在使用时他们有不同的心态。
As a software tester, we need to check the purpose of the product and not the object or aspect of it.
作为软件测试人员，我们需要检查产品的用途，而不是对象或其他方面。
Let me give you some real-life practical examples(让我给你一些现实生活中的实例):
- Scissors were never limited to cut paper only. Cutting is the purpose and not the paper (object).剪刀不仅限于剪纸。 切割是目的而不是纸张（对象）。
- Cell phones were never limited to only calling, but “able to call” has always been the basic purpose.手机从不仅限于通话，但“能够通话”一直是基本目的。
- Storage boxes are used to store, but the safety of the material stored is as important as storage.存储盒用于存储，但存储的材料的安全性与存储一样重要。
Understanding stakeholders and a wide range of their expectations should be the baseline of exploratory testing.
了解利益相关者及其广泛的期望应成为探索性测试的基准。
#2. A mindset(＃2. 一种心态)
While looking for (let’s say) a job employment ad, do you see that jackpot and in between the pages with the bold font? Most of us do not (believe me, it’s true). Because we have instructed our mind to look for what is useful or to be checked. Anything else is of no use, so the mind denies us of recognizing it.
在寻找（比方说）就业广告的同时，你是否看到了大奖，并在页面之间加粗字体？ 我们大多数人都没有（相信我，这是真的）。 因为我们已经指示我们的思想寻找有用或有待检查的东西。 其他任何东西都是没用的，所以头脑不让我们关注它。
Open your mind, and do not set any expectations when you start exploring a product. Always remember, it’s not OK if the product is doing what it is supposed to do. It is also important that it should not do what it is not supposed to do.
开阔思路，在开始探索产品时不要设定任何期望。 永远记住，如果产品正在做它应该做的事情这是不够的。 同样重要的是它不应该做它不应该做的事情。
I remember one classic example(我记得一个经典的例子):
In Linux, ‘cat’ command is used to check the content of a file and the ‘ls’ command is to check the content of the directory. Working with Linux and being in software testing for five years, I never thought to do cat <dir name> because my mind was set; if I needed dir content, I need to use ‘ls’. That worked, but the reverse side of the expectation is that the product was not supposed to behave the way it was not supposed to, was wrong. One of our customers, who did not know Linux well, did cat <dir name> by mistake and the system crashed. We paid for this mindset.
在Linux中，'cat'命令用于检查文件的内容，'ls'命令用于检查目录的内容。 使用Linux并在软件测试中工作了五年，我从未想过要做cat<dir name>，因为我的思路已经固定了; 如果我需要目录的内容，我需要使用'ls'。 这是有效的，但期望的反面是产品不应该按照它不应该的方式运行，这是错误的。 我们的一位不熟悉Linux的客户误将cat <dir name>搞错了，系统崩溃了。 我们为此种心态付出了代价。
Always be ready to make mistakes with the software because that is what end user is going to do. To test the software, you have been trained, but the end user will not be as trained as you or he/she will not be as much of a technical expert as you. Also, he/she will do anything with the software when they are in trouble. Think about those scenarios, and provide testing feedback. Life of the software and yours (as a tester) will rock.
始终准备好使用软件犯错误，因为这是最终用户可能会做的事情。 为了测试软件，您已接受过培训，但最终用户不会像您那样接受过培训，或者他/她不会像您一样是技术专家。 此外，他/她在遇到麻烦时会对软件做任何事情。 考虑这些场景，并提供测试反馈。 软件和你的（作为测试人员）的生活都是“摇摆不定”的。
#3. Know the competitors(＃3. 了解竞争对手)
While testing any software application for your client, did you ever attempt to know and understand other software with the same purpose? Did you ever suggest some useful functionality you observed in a competitor’s product? It does not fall in our job description, is the typical answer. But do you know the benefit of doing it?
在为您的客户测试任何软件应用程序时，您是否曾尝试了解和理解具有相同目的的其他软件？ 你有没有建议你在竞争对手的产品中观察到一些有用的功能？ 它不属于我们的工作描述，确是是典型的答案。 但是你知道这样做的好处吗？
Here are few real-life examples to make you understand the point(以下是一些让您理解这一点的现实案例):
- Don’t you like the designer that not only stitches your dress but also provides you input about matching accessories most?难道你不喜欢这样的设计师，不仅可以缝合你的衣服，还能为你提供最匹配的配饰吗？
- Don’t you like the pizza brand who not only makes great pizzas but home delivers on time most?难道你不喜欢这样的披萨品牌，它不仅制作了很棒的比萨饼，而且能最准时送达家里吗？
- Don’t you like the photographer who not only takes good photographs but suggests a different kind of frames for the photo shoot?难道你不喜欢那些不仅拍摄好照片，而且为照片拍摄提出不同类型画面的摄影师吗？
Everyone wants to have something extra for what they pay for. Our analysis of competitive software can work the same way for us. The customer always likes to hear valuable suggestions – mainly comparative suggestions to make the product more useful or marketable.
每个人都希望为他们付出的代价获得额外的东西。 我们对竞争软件的分析对我们来说可以采用相同的方式。 客户总是喜欢听到有价值的建议 - 主要是比较建议，以使产品更有用或更有市场。
Also, this kind of comparison and analysis of the same range of products makes our analysis more powerful and eventually we create a treasure to which we can go back at any moment and find something useful.
此外，对同一系列产品的这种比较和分析，使我们的分析更加强大，最终让我们创造了一个宝藏，我们可以随时回去寻找有用的东西。
Conclusion(结论)
Exploratory doesn’t come under conventional way of testing but still, it is a very powerful way of testing.
探索性不是传统的测试方式，但仍然是一种非常强大的测试方式。
It brings out the out of box thinking of a tester and encourages them to come up with practical and real-time test cases for finding a defect. Its freestyle nature gives it an edge over the other testing types and can be performed anywhere, be it a project using Agile or waterfall or any other project which requires minimal documentation.
它带来了对测试人员的开箱即用的思考，并鼓励他们提出实用、实时的测试用例来发现缺陷。 它的自由风格使其优于其他测试类型，并且可以在任何地方执行，无论项目是使用敏捷项目或瀑布的项目还是需要最少文档的任何其他项目。
The success of exploratory testing depends on numerous intangibles like the skill of a tester, ability to create effective test cases, their experience, and the knack to follow their gut feeling.
探索性测试的成功依赖于许多无形资产，例如测试人员的技能，创建有效测试用例的能力，他们的经验以及追随他们的直觉的诀窍。
It’s imperative to remember that ET is an adaptive process rather than a predictive one and it’s essential to maintain a healthy balance between exploratory and scripted or regular testing.
必须记住，ET是一个自适应过程而不是预测过程，在探索性和脚本式或常规测试之间保持健康的平衡至关重要。