什么是探索性测试？

What is Exploratory Testing?(什么是探索性测试？)

“Exploratory testing” – as the name suggests, is a simultaneous learning, test design, and test execution process. We can say that in this testing test planning, analysis, design and test execution, are all done together and instantly.

“探索性测试” – 顾名思义，是一种，测试设计和测试执行同步进行过程。 我们可以说，在测试中，测试计划，分析，设计和测试执行中，所有这些都是一起完成的。

This testing is about exploring the system and encouraging real-time and practical thinking of a tester. 

该测试是关于探索系统并鼓励测试人员进行实时和实际思考。

************************************

Overview(概览)

In layman terms, exploratory testing involves concurrent test case design and test execution of an application or system under test. The tester will create or write down a test idea to give direction, and explore the system while testing to further create critical, practical and useful tests for the successful testing of an application.

通俗地说，探索性测试涉及并行地进行测试用例设计和待测的应用程序或系统的测试执行。 测试人员将创建或记下测试想法以指导方向，并在测试时探索系统，以进一步为成功测试应用程序创建关键，实用和有用的测试。

This requires minimal planning. Testers continuously make a decision on her next step of action. It completely depends upon the tester’s thought process.

这需要最少的计划。 测试人员不断对下一步行动作出决定。 它完全取决于测试人员的思维过程。

Sometimes this testing can be more beneficial than the formal testing approach for finding some subtle defects which go missing in formal testing.

有时，这种测试比常规的测试方法更有利于找到在常规测试中缺失的一些微妙缺陷。

Consciously or unconsciously each and every tester would have done exploratory testing at some point in their career.

有意识或无意识地，每个测试人员都会在他们职业生涯的某个阶段进行探索性测试。

As we all know, a learner will learn better through hands-on experience rather than cramming the theory.

众所周知，学习者将通过实践经验更好地学习，而不是填补理论。

Same way, a tester will know the application better only while exploring and learning about all the functionality it provides by itself. It is always good to have a customer and business perspective while testing to ensure successful testing of an application.

同样，测试人员，只有在探索和了解其应用程序提供的所有功能时，才能更好地了解应用程序。 在测试期间拥有客户和业务视角以确保成功的测试应用程序，这总是好的。

For Example, if you open a shopping website, you have a general idea that this shopping website will let you shop by selecting a product of your choice and then paying for the same.

例如，如果您打开一个购物网站，您可以大致了解该购物网站——通过选择您选择的产品然后支付费用来购物。

During this process, you might learn that the website provides you with virtual human look-alike which helps you in product selection process. You also found that you can order a number of products for home trial or that you can make payment through rewards points of some banks, etc.

在此过程中，您可能会了解到该网站为您提供了虚拟的人类外观，可以帮助您进行产品选择。 您还发现您可以订购一些产品进行家庭试用，或者您可以通过某些银行的奖励积分等进行支付。

As a tester, you not only need to verify whether a system is working as expected but also check if that system is not behaving in a way which is not expected.

作为测试人员，您不仅需要验证系统是否按预期工作，还要检查该系统的行为是否不符合预期。

Few things to remember while performing this testing(执行这种测试时要记住的几件事情):

• Your mission should be clear你的任务应该是清晰的.
• Make sure to create notes and report on what you are doing and how a system is behaving, which could be a potential bug.确保创建笔记并报告您正在做什么以及系统的行为方式，这可能是一个潜在的错误
• Learn, observe and then come up with new test cases.学习，观察并提出新的测试用例

Exploratory Testing Examples探索性测试实例

Example# :

I was once included in a small project which involved the addition of a new Mutual fund in the application. My task was to test the application to make sure that the new Mutual fund is available for users to buy and check if the associated valuation is correct. I had only 2 days to complete my testing.

我曾经被纳入一个小项目，该项目涉及在申请中增加一个新的共同基金。 我的任务是测试应用程序，以确保新的共同基金可供用户购买并检查相关评估是否正确。 我只有2天时间完成测试。

Being given the tight deadline and severity of testing, I used the exploratory approach of testing. My goal was to test new features and to find violations of compatibility requirements.

由于测试的紧迫期限和严格性，我使用了探索性的测试方法。 我的目标是测试新功能并发现违反兼容性要求的行为。

The above-mentioned goal became my charter for this test session.

上述目标成为我参加本次测试的章程。

Following test cases were evolved during this testing(以下测试案例在此测试期间得到了执行):

• Testing to make sure that the new Mutual fund has been added to the application.进行测试以确保新的共同基金已添加到应用程序中
• New MF is bought successfully.新MF可以成功购买。
• Valuation of new MF is correct.新MF的评估是正确的。
• Tried to buy new MF for an existing portfolio.试图为现有的投资组合购买新的MF。
• Can new MF be added to all Portfolios?可以将新MF添加到所有投资组合吗？
• Impact of New MF on a valuation of existing.新MF对现有估值的影响。
• So in other test cases were evolved.其他测试用例也类似进行。

I prepared notes and reports during my testing to discuss my observation with the BA and client involved.

我在测试期间准备了笔记和报告，与BA和客户讨论我的观察结果。

The fundamental strategy of exploratory testing is to a have a plan of attack. Start testing with your idea and improvise new test cases based on your knowledge and observation.

探索性测试的基本策略是制定攻击计划。 根据您的想法开始测试，并根据您的知识和观察即兴创建新的测试用例。

Testing Approach测试方法

• Make use of heuristics to guide testing.利用启发式方法指导测试
• Test cases execution and test case creation go hand in hand.测试用例执行和测试用例创建齐头并进。
• Test cases keep on evolving based on the tester observation and learning.基于测试人员的观察和学习，测试用例不断扩展
• Different testing techniques like Boundary value analysis, equivalence testing etc. can be applied to ET.边界值分析，等效性测试等不同的测试技术可以应用于ET。
• Session-based ET can be used to make it more structured and focused.基于会话的ET可用于使其更具结构性和聚焦
• Testers can branch out there ideas but never stray from your mission.测试人员可以提出想法但不会偏离自己的目标。
• ET testing does not use scripts, instead depends on tester’s intuition, skill, and experience.ET测试不使用脚本，而是取决于测试人员的直觉，技能和经验

Benefits优点

Benefits of this testing include(这种测试包括的优点):

• Promote real-time thinking and helps in uncovering more defects.促进实时思考，并帮助发现更多缺陷。
• Promote use cases and scenario-based testing.促进使用用例和基于场景的测试。
• Minimal documentation, maximum testing.最少的文档，最大化的测试。
• Emphasis is more on learning and broadening the horizon of a tester.重点更多的放到了测试人员的学习和拓宽视野上。
• Avoid duplicate work.避免重复工作。
• Useful when you want to audit other tester’s work.当您想要审核其他测试人员的工作时很有用。

Demerits缺点

Demerits are enlisted below(缺点如下):

• Testing depends on tester experience, skill, and knowledge.测试依赖测试人员的经验，技能和知识
• Require time to learn the application. Tester is more likely to miss if they know less about the application.需要时间来学习应用程序。 如果他们对应用程序知之甚少，测试人员更容易错过。
• Not appropriate for projects with long execution time.不适合执行时间长的项目。

Session-based Exploratory Testing基于会话的探索性测试

While doing exploratory testing, it’s very difficult for testers to put into words on how much he has tested and on what basis.

在进行探索性测试时，测试人员很难对他测试的程度以及测试结果进行说明。

Basically, it’s difficult to quantify the work and the time spent. However, in every project, we need to provide metrics, estimates and progress report to team leads and the managers. As the saying goes, “if you can’t quantify it, you cannot manage it”.

基本上，很难量化工作和花费的时间。 但是，在每个项目中，我们都需要向团队负责人和经理提供指标，估算和进度报告。 俗话说，“如果你无法量化它，你就无法管理它”。

Session-based testing is a time basis approach to perform this testing which helps in managing and tracking. It includes a dedicated time-boxed testing session with no interruption from email, phone, messages etc.

基于会话的测试是执行此测试的基于时间的方法，有助于管理和跟踪。 它包括一个专门的时间盒测试会话，不会中断电子邮件，电话，消息等。

Approach(方法):

Testing tasks are divided into sessions.测试任务分为会话。

Following are the components of session-based testing (SBT):以下是基于会话的测试（SBT）的组成：

• Mission: Mission shout out the purpose of the session and in a way provide the focus for the tester. It will also include session time duration.使命：使命宣传会议的目的，并以某种方式为测试人员提供重点。 它还将包括会话持续。
• Charter: Includes the scope of the testing. Basically, an agenda detailing the goals that need to be completed during the session.章程：包括测试范围。 基本上，该议程详细说明了在会话期间需要完成的目标。
• Session: Pre-defined time-boxed testing session without any interruption. Each session can have the following duration:会话：预定义的时间框测试会话，没有任何中断。 每个会话可以具有以下持续时间：
  • “Short” (60min)
  • “Normal” (90min)
  • “Long” (120 min)
• Session report: Include notes and lightweight report to provide metrics to the leaders and managers. It gives details about the charter session remaining or done, session setup time, scenario tested, about the testing process, a list of bugs and the issues found and other information for the metrics.会话报告：包括注释和轻量级报告，以向领导者和经理提供指标。 它提供了有关剩余或完成的章程会话，会话设置时间，测试过的场景，测试过程，错误列表和发现的问题以及用于度量的其他信息。
• Session De-brief: A short meeting or stand-up between the tester and Test Lead/Manager to review the test session findings.会议简介：测试人员和测试主管/经理之间的简短会议或站立，以审查测试会议结果。
• Managers can get hands-on following metrics based on session report:管理人员可以根据会话报告获得下面的指标：
• The number of sessions completed and remaining.完成和剩余的会话数。
• The number of bugs reported.报告的错误数量。
• Time spent on session setup.花在会话设置上的时间。
• Time spent on testing.花在测试上的时间。
• Time spent on analyzing issues or problems.花在分析问题上的时间。
• Features covered.功能涵盖。

To summarize the above(总结以上内容):

SBT allows for accountability is exploratory testing and offers better management of time spent on testing. It also increases productivity and provides a better grasp on bug detection. It is a great way to provide team leads and managers with metrics to check the project progress.

SBT允许问责制来探索性测试，并提供更好的测试时间管理。 它还可以提高工作效率，更好地发现问题。 这是为团队负责人和经理提供指标以检查项目进度的好方法。

Pair Based Exploratory Testing基于结对的探索性测试

Pair Testing is an approach in which two people test the same thing/feature of the application at the same time by sharing a PC. They continuously share their thoughts and ideas. During this testing, one person takes charge of the keyboard whereas the other person suggests test cases and takes note.

结对测试是一种方法，其中两个人通过共享PC同时测试应用程序的相同模块/功能。 他们不断分享他们的思路和想法。 在此测试期间，一个人负责键盘，而另一个人建议测试用例并做记录。

It is always helpful to have a good communication between the partners so that both are aware of what is being done and why. A pair in which strength of the testers mutually complements their weakness is considered as a strong grouping.

在合作伙伴之间建立良好的沟通总是有帮助的，这样两人都知道正在做什么和为什么这么做。 结对测试中，测试者的强项与他们的弱点相互补充，这是一个强大的分组。

Such pairing benefits both the parties and each can learn something from their partner. It is also a good way to train new resources by pairing them with experienced resources.

这种配对对双方都有好处，每个人都可以从他们的伙伴那里学到一些东西。 通过将他们与经验丰富的人员配对，这也是培养新资源的好方法。

Benefits of Pair Testing(结对测试的优点)

• Helps a tester to focus on the task at hand.帮助测试人员专注于手头的任务。
• Encourage mutual trust and respect among partners.鼓励合作伙伴之间的相互信任和尊重。
• Brainstorming between paired testers usually, lead to more constructive ideas.配对的测试人员之间的头脑风暴通常会带来更具建设性的想法。
• Avoid tunnel vision.避免隧道视角。
• There is a lesser chance of others interrupting them.其他人打断他们的可能性较小。

Exploratory Testing Techniques探索性测试技术

Tours: It is a simple technique which allows a tester to use his imagination and think of himself as a tourist exploring a city he visits. Here an application to test is the city and the testers are the tourists. It is very difficult to explore the entire city unless you have a lot of time and money in your hand, so a tourist needs to have a plan with a certain goal in mind.

旅游：这是一种简单的技术，可以让测试人员运用他的想象力，将自己视为探索游览城市的游客。 这里测试的应用程序是城市，测试人员是游客。 除非你手上有大量的时间和金钱，否则很难探索整个城市，因此游客需要制定一个有一定目标的计划。

A tourist can take the following tours(游客可以参考以下旅游):

• Guidebook tour – Testing highlighted feature of the application. Use user-based scenarios.指南参观 – 测试应用程序的重点功能。 使用基于用户的方案。
• Exploring the history of the city – Test old features of an application.探索城市的历史 – 测试应用程序的旧功能。
• Money tour, which means making sure that all the critical features in reference to the customer or client are tested and working successfully.资金游览，这意味着确保参考客户或客户的所有关键功能都经过测试并成功运行。
• Crime spree tour – Enter invalid input and test negative scenarios.犯罪狂欢之旅 – 输入无效输入和测试否定方案。
• Back alley tour – Test the least used features of the application.后巷游览 – 测试应用程序中使用最少的功能。
• Boring tour – Spend minimum time on each screen of the application, fill minimum fields and take the shortest path. This will help with the default value and validation testing.无聊之旅 – 在应用程序的每个屏幕上花费最少的时间，填充最小字段并采用最短路径。 这将有助于默认值和验证测试。

While taking a tour, you always have the choice of taking any route. You can navigate through software and find a unique path to test the feature.在参观游览时，您总是可以选择任何路线。 您可以浏览软件并找到测试该功能的唯一路径。

Below are some tips/tricks that you can use in ET以下是您可以在ET中使用的一些提示/技巧:

• Divide the application into modules and bifurcate modules into different pages. Start your ET from the pages. This will give the right coverage.将应用程序划分为模块并将模块分成不同的页面。 从页面开始ET。 这将达到正确的覆盖度。
• Make a checklist of all the features and put a check mark when that is covered.制作所有功能的清单，并在覆盖时添加复选标记。
• Start with a basic scenario and then gradually enhance it to add more features to test it.从基本场景开始，然后逐步增强它以添加更多功能来测试它。
• Test all the input fields.测试所有输入字段
• Test for the error message测试错误消息
• Test all the negative scenarios.测试所有消极/逆向场景。
• Check the GUI against the standards.根据标准检查GUI。
• Check the integration of the application with other external applications.检查应用程序与其他外部应用程序的集成。
• Check for complex business logic.检查复杂的业务逻辑。
• Try to do the ethical hacking of the application.尝试对应用程序进行黑客攻击般的尝试。

Factors which affect ET are as follows影响ET的因素如下:

• The objective of the project该项目的目标
• Testing strategy测试策略
• The testing goal of a particular phase特定阶段的测试目标
• Available tools and facilities可用的工具和设施
• Testers role and skills测试人员的角色和技能
• Available time空闲时间
• Management support管理支持
• Peer support同伴支持
• Available resources (study materials, test conditions etc)可用资源（学习材料，测试条件等）
• Clients interest客户兴趣
• Understandability of the product.对产品的理解。
• The UI of the application应用程序的UI
• The functionality of the application应用程序的功能
• Previous test results以前的测试结果
• Risks associated with the application与应用程序相关的风险
• Previous defects以前的缺陷
• Recent changes近期变动
• Types of data to use for testing用于测试的数据类型
• Type of user who will be using it将使用它的用户类型

Instead of asking the testers what to run, we leave it to tester’s judgment to decide what they want to test and how they want to test.

我们不是要求测试人员运行什么，而是让测试人员判断他们想要测试什么以及他们想要测试的方式。

Difference between Exploratory Testing and Ad-hoc Testing探索性测试和随机测试之间的区别

Do not confuse ET with Ad-hoc testing.不要将ET与Ad-hoc测试混淆。

• Ad-hoc testing refers to a process of unscripted, unplanned and impromptu defect searching whereas exploratory testing is a thoughtful methodology to Ad-hoc testing.随机测试指的是无脚本，无计划和即兴缺陷搜索的过程，而探索性测试是Ad-hoc测试的深思熟虑的方法。
• Ad-hoc testing is a hit and trial method of finding a bug whereas ET is not. In ET approach, a tester learns about the system as they explore and eventually evolve the tests using the acquired knowledge.随机测试是一种找到错误的试验方法，而ET不是。 在ET方法中，测试人员在探索测试时要了解系统，并最终使用获得的知识进行测试。
• Ad-hoc testing is an unstructured activity whereas ET is somewhat a structured activity.随机测试是一种非结构化的活动，而ET在某种程度上是一种结构化的活动。

Exploratory Automated Testing (EAT)探索性自动化测试（EAT）

Exploratory Automated Testing is a method that helps a tester in streamlining bug reporting & reproduction, snapshots gathering and in preparation of future regression suit. It’s a process that combines automation testing with the Exploratory testing.

探索性自动化测试是一种帮助测试人员简化错误报告和复制，快照收集以及准备未来回归的方法。 这是一个将自动化测试与探索性测试相结合的过程。

There are two types of EAT approach有两种类型的EAT方法:

• Passive EAT被动的EAT
• Active EAT积极的EAT

Passive EAT(被动的EAT):

Passive EAT can be performed by a single tester or in a pair as well. In this methodology, usually, a tool, which captures and records every single activity performed by a testing resource(s) and is installed on the resource’s PC.

被动EAT可以由单个测试者或成对执行。 在这种方法中，通常是一种工具，它捕获并记录由测试资源执行的每个单独的活动，并安装在资源的PC上。

Passive EAT is similar to the ET that is performed manually as there is no change in the way the tests are executed apart from crafting the test result based on the captured session. These test results can be used for reporting and reenacting of recorded actions later in time.

被动EAT类似于手动执行的ET，因为除了基于捕获的会话制作测试结果之外，测试的执行方式没有变化。 这些测试结果可用于稍后报告和所记录的操作重现。

The installed video tool helps a tester with test case recording and defect reporting.安装的视频工具可帮助测试人员进行测试用例记录和缺陷报告。

It also has few other benefits like它还有其他一些好处，如:

• Provides clear steps to reproduce the bugs.提供重现错误的明确步骤
• Reproducing defects is easier even when the defect reporter is not available.即使没有缺陷报告人，再现缺陷也更容易。
• Do away with the conflicts between the testing and development team when an intermittent bug is reported.当报告间歇性错误时，消除测试和开发团队之间的冲突。
• Helps in performance testing by getting the system response time at the specific point in time.通过在特定时间点获取系统响应时间来帮助进行性能测试。

Here are few other points to be taken into consideration before Passive EAT在被动EAT之前，还有以下几点需要考虑:

• It is advised to perform a pilot test before completely adapting the tool for Automated EAT. This is to ensure that the time required for re-designing of the test logs created during the test session is not more than test execution. If so, then the team needs to take a mutual decision on the following建议在完全适应自动EAT工具之前进行试验测试。 这是为了确保在测试会话期间重新设计测试日志所需的时间不超过测试执行时间。 如果是这样，那么团队需要就以下事项做出共同决定:
  • If at all test automation is required for the particular project.如果特定项目需要测试自动化。
  • If the tool being used needs to be changed.如果需要更改正在使用的工具。
  • If the performance of the tool being used can be optimized.如果可以优化所使用工具的性能。
• The tool used for performing automated EAT needs to be installed on every testing resource involved in testing. It is also a good idea to involve the developers which can be achieved by either giving the developers VPN or remote access to test machines or by installing the tool in the development environment.用于执行自动EAT的工具需要安装在测试中涉及的每个测试资源上。 通过向开发人员提供VPN或远程访问测试机器或在开发环境中安装该工具，可以让开发人员参与进来也是一个好主意。
• It is always a good idea to have GUI object of the application organized in the test tool so that when the time comes for analyzing the bug or an issue, the object is recognizable due to a meaningful name.在测试工具中组织应用程序的GUI对象始终是一个好主意，以便在分析错误或问题时，由于名称有意义，该对象是可识别。
• It is a great practice to give a meaningful name to the GUI object used in AUT and keep them organized for later use.为AUT中使用的GUI对象赋予一个有意义的名称，并将它们组织起来供以后使用，是一种很好的做法。

Now, let’s move on to the second approach.现在，让我们继续第二种方法。

Active EAT(积极的EAT):

It is advisable to perform Active EAT with Pair Testing. In this approach, the Keyword Driven testing is used in sync with Session testing. One tester creates the automated test script and the second tester executes the test scripts created by the first tester.

建议使用结对测试执行积极的 EAT。 在这种方法中，关键字驱动测试与会话测试同步使用。 一个测试人员创建自动测试脚本，第二个测试人员执行第一个测试人员创建的测试脚本。

Creation of automation test scripts in this approach takes a different path than in conventional testing. Automated test scripts are made during testing and what has been discovered in the previous tests determine their design.

在这种方法中，创建自动化测试脚本采用与传统测试不同的路径。 在测试期间会生成自动化测试脚本，并根据之前测试中发现的内容，决定了脚本的设计。

A closure phase is executed at the end of the testing session. And it should have the following tasks:

在测试会话结束时执行闭环阶段。 它应该有以下任务：

• Testers involved should swap roles so that the testing resource who created the test script has a chance to re-execute the scripts to confirm the reliability & robustness of the created suite.涉及的测试人员应交换角色，以便创建测试脚本的测试人员，有机会重新执行脚本以确认创建的套件的可靠性和健壮性。
• A brief description along with few identifying characteristics should be provided for every automated test script.应为每个自动化测试脚本提供简要描述，以及一些识别特征。
• A criterion needs to be defined to identify which Automated test scripts can be used for Regression test.需要定义一个标准，以确定哪些自动化测试脚本可用于回归测试。

Benefits of EAT(EAT的好处)

• At the start of each session, already created automated test scripts are executed thus enhancing the test coverage every-time.在每个会话开始时，执行之前创建的自动测试脚本，从而确保每次的测试覆盖率。
• Better bug reporting and documentation for defect reproduction.更好的错误报告和缺陷再现文档。
• EAT provides enough evidence and documentation for a stakeholder to see the progress.EAT为利益相关者提供了足够的证据和文件，以了解进展情况。

Types of Exploratory Testing探索性测试的类型

Given below are few types of ET(以下是几种类型的ET):

1) Freestyle ET(自由式ET):

Exploration of application in ad-hoc style.在ad-hoc测试风格中的应用探索。

In this type of ET, there are no rules, no account for coverage, etc. However, this type of testing is good when you need to familiarize with the application quickly, when you want to verify the work of the other testers, and when you want to investigate a defect or want to do a quick smoke test.

在这种类型的ET中，没有规则，没有覆盖范围等。但是，当您需要快速熟悉应用程序、要验证其他测试人员的工作时，以及当您想调查缺陷或想要进行快速烟雾测试时，此类测试很有用。

2) Scenario-based ET(基于场景的ET):

As the name itself suggests, testing done is scenario based. It starts with real user’s scenarios, end-to-end scenarios or test scenarios. After initial testing, testers can inject variation as per their learning and observation.

顾名思义，测试完成是基于场景的。 它开始于真实用户的场景，端到端场景或测试场景。 经过初步测试，测试人员可以根据他们的学习和观察注入变化项。

Scenarios are like a generic guide for what to do during ET. Testers are encouraged to explore multiple possible paths while executing a scenario to ensure all possible path to a feature work. Testers should also ensure to gather as many scenarios as possible from different categories.

场景就像是在ET期间做事情的通用指南。 鼓励测试人员在执行场景时探索多种可能的路径，以确保所有可能的路径都能工作。 测试人员还应确保从不同类别中收集尽可能多的场景。

3) Strategy based ET(基于策略的ET): 

Known testing techniques such as Boundary value analysis, equivalence technique, and risk-based technique that are combined with exploratory testing. An experienced tester or a tester who is familiar with the application is appointed for this type of testing.

已知的测试技术，如边界值分析，等效技术和与探索性测试相结合的基于风险的技术。 经验丰富的测试人员，或熟悉该应用程序的测试人员被指定进行此类测试。

Agile Exploratory Testing敏捷探索性测试

Even if you have not worked in an agile environment, I am sure you must have read or heard about it because of its growing popularity. Agile methodology has short sprints and tight deadlines which gives a team couple of weeks to finish planning, estimation, development, coding, testing, and release.

即使您没有在敏捷环境中工作，我相信您一定读过相关内容或听说过，因为它越来越受欢迎。 敏捷方法有短暂的冲刺和紧迫的截止日期，这使得团队可以在几周内完成规划，评估，开发，编码，测试和发布。

Exploratory testing becomes handy in such tight deadlines because in this testing approach emphasis is on the quick and useful result. Once you have understood the requirement, you can start testing based on your experience and knowledge.

在如此紧迫的期限内，进行探索性测试变得非常方便，因为在这种测试方法中，重点放到了快速且有用的结果上。 一旦了解了需求，就可以根据自己的经验和知识开始测试。

Once you are familiarized with the application features and behavior, you can design more test cases to validate the application functionality and detect unplanned bugs. As it’s a freestyle testing approach, you do need to document everything. However, you need to maintain notes and a brief report on what you have tested, bugs and issues found etc.

一旦熟悉应用程序功能和行为后，您可以设计更多测试用例以验证应用程序功能并检测计划外的缺陷。 由于这是一种自由式测试方法，您不需要将所有内容文档化(ps:个人认为这里少了一个 not )。 但是，您需要维护笔记并简要报告您测试的内容，发现的错误和问题等。

Merits of Exploratory in Agile(敏捷探索的优点)

• Proving feedback to the developers as soon as possible.尽快向开发人员提供反馈意见。
• A broader variety of defects are uncovered.暴露了更多种类的缺陷。
• A diverse group of a resource such as a developer, tester, BA, designers can perform ET as there are no scripted test cases and each brings a different perspective.由开发人员，测试人员，BA，设计人员组成的多样化资源组可以执行ET，因为没有脚本化的测试用例，每种角色人员能带来了不同的视角。
• Scouting done in ET helps in exploring new territories and exposing critical bugs.在ET中进行的侦察有助于探索新领域并揭露关键错误。
• In case of Iterative coding of an application, ET can focus on testing new features while automation does regression and backward compatibility testing.在对应用程序进行迭代编码的情况下，ET可以专注于测试新功能，而自动化则可以进行回归和向后兼容性测试。
• In case of unstable requirement, ET can help in testing new requirement within a limited time.在需求不稳定的情况下，ET可以在有限的时间内帮助测试新的需求。

Points to Remember(要记住的点):

1. Requires different skills: The testers performing ET need to have good listening, reading, thinking and reporting skills. Domain experience is required as there are no scripts and test cases.需要不同的技能：执行ET的测试人员需要具备良好的倾听，阅读，思考和报告技能。 由于没有脚本和测试用例，因此需要领域经验。

2. Sometimes it’s difficult to report a bug: While in an ET flow, we may encounter a defect but we may not be able to reproduce it. This is because we are not tracking the testing steps and we may forget the exact steps to reproduce that issue.有时报告错误很困难：在ET流程中，我们可能会遇到缺陷，但我们可能无法重现它。 这是因为我们没有跟踪测试步骤，我们可能会忘记重现该问题的确切步骤。

3. Can be done as recreation activity: I personally do ET when I want a break from my regular test execution cycle. But many teams have ET as a separate phase of their testing cycle.可以作为娱乐活动完成：当我想要从常规测试执行周期中休息时，我个人会做ET。 但许多团队将ET作为其测试周期的一个独立阶段。

4. It can be done for all testing phases: We can implement ET before the beginning of any testing phase. You can perform ET even before functional testing phase.它可以在所有测试阶段完成：我们可以在任何测试阶段开始之前实施ET。 您甚至可以在功能测试阶段之前执行ET。

5. Rapid feedback: ET requires rapid feedback on the issues and any anomalies encountered.快速反馈：ET需要快速反馈问题和遇到的任何异常情况。

6. Critical Thinking and diverse ideas: This testing requires critical thinking. Testers should be able to reproduce, review and express their ideas in a logical way. A tester can implement her experience in the various technologies and domains they worked on.批判性思维和不同的想法：这种测试需要批判性思维。 测试人员应该能够以合理的方式复制，审查和表达他们的想法。 测试人员可以在他们所从事的各种技术和领域中实施自己的经验。

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是一个自适应过程而不是预测过程，在探索性和脚本式或常规测试之间保持健康的平衡至关重要。