如果你像我一样,找到有价值的探索性方法,那么问题出现了:你什么时候开始做? 它与软件生命周期有何关系?


If you, like me, find the exploratory approach to testing valuable (see my recent column “What Is Exploratory Testing?”), then the questions arise: When do you do it? How does it relate to the software lifecycle? StickyMinds Review Team member Yogita Sahoo sent me an insightful list of questions and comments about exploratory testing (ET). I’ll be responding to some of them in future columns. For instance, she writes, “In my personal experience, if I start exploring things when I’m supposed to carry on with my allotted tests, the whole thing gets jumbled up. I can neither concentrate fully on ET nor on my regular test cases. That results in less productivity.” Let me address that.

如果你像我一样,找到有价值的探索性方法(参见我最近的专栏“什么是探索性测试?”),那么问题出现了:你什么时候开始做? 它与软件生命周期有何关系? StickyMinds Review团队成员Yogita Sahoo向我发送了一份有关探索性测试(ET)的深刻见解和评论。 我将在以后的专栏中回答其中的一些问题。 例如,她写道,“根据我的个人经验,如果我开始探索我已经进行分配测试的事情,整个过程就会混乱。我既不能完全专注于ET,也不能专注于常规测试用例 。这导致效率下降。“ 让我解决这个问题。

A simple way to think of ET is concurrent test design and test execution. To help Yogita better, I want to use a more specific definition: Any testing is exploratory to the extent that the tester actively controls the design of the tests as those tests are performed and uses information gained while testing to design new and better tests.

说起ET,一种简单的理解是并发进行测试设计和测试执行。 为了更好地帮助Yogita,我想使用更具体的定义:任何测试都是探索性的,只要测试人员在执行测试时主动控制测试的设计,并使用测试时获得的信息来设计新的和更好的测试。

This definition includes pure exploratory testing, where you explore the product and design a test strategy and specific tests based on your understanding of your mission as a tester, but without any specific guidance. It includes chartered exploratory testing, where you have a specific assignment for what to test and what techniques to use, but no designated procedures. It also includes improvisational testing, where you elaborate on a test procedure or use it to inspire a set f related tests. It includes test procedure creation, too, inasmuch as you perform tests while documenting them.

该定义包括纯粹的探索性测试,作为测试人员,但没有任何具体指导下,您可以根据自己的理解来探索产品并设计测试策略和特定测试, 它包括探索性测试,您可以在其中具体指定测试内容和使用的技术,但没有指定的程序。 它还包括即兴测试,这里您可以在其中详细说明测试程序或使用它来激发相关的测试。 它还包括测试过程创建,因为您在文档化时执行测试。

It’s more about how to do ET well, than when to do it(它更多的是关于如何做好ET,而不是什么时候做)

All testing done by humans is exploratory to some degree, because humans are not robots. That means the question is not when do you do exploratory testing, but rather how exploratory is the testing that you do, and how well do you do it. When I consult about test process, I don’t suggest that my clients perform exploratory testing. Instead, I help them become aware of all the ET that they already do, which is probably mixed up with some form of scripted testing (or pseudo-scripted testing, where testers say they follow the procedures, but don’t). Once I can get their exploratory testing to “come out of the closet,” I can help them improve their skills and overall test strategy so that they do ET, and any other testing, better.

人类进行的所有测试在某种程度上都是探索性的,因为人不是机器。 这意味着问题不在于何时进行探索性测试,而在于您所做的测试具有的探索性程度如何,以及您的表现如何。 当我咨询测试过程时,我不建议我的客户进行探索性测试。 相反,我帮助他们了解他们已经做过的所有ET,它可能与某种形式的脚本测试(或伪脚本测试,测试人员说他们遵循程序,但没有)混在一起。 一旦我能够让他们进行的探索性测试“暴露真相”,我可以帮助他们提高他们的技能和整体测试策略,以便他们更好地做ET,以及任何其他测试。

Exploratory testing is all you have at the beginning…(探索性测试是你在开始时所拥有的……)

ET fits at the beginning of the test project because test procedures don’t yet exist for the new technology being developed. Even if they do exist, you have to learn the product (that requires exploring and questioning it), and the procedures would have to be reviewed and upgraded. The process of writing test procedures is exploratory. Watch anyone, or yourself, writing a test script, and you’ll see those thought processes at work.

ET适用于测试项目的早期,因为正在开发的新技术尚不存在测试程序。 即使它们确实存在,您也必须学习该产品(需要对其进行探索和质疑),并且必须审查和升级这些程序。 编写测试程序的过程是探索性的。 观察任何人或您自己编写的测试脚本,您将看到这些思维在起作用。

…and it’s how you create diversity in tests later on.(……你在稍后的测试中如何创造多样性)

ET fits into the middle of a test project, even when you have lots of scripted tests. Be exploratory in the sense that a tourist on a tour bus is exploratory. Let your allotted tests take you to visit different parts of the product, then improvise on the theme of those tests, briefly. Spend a few minutes working through variations of the tests, then get back on the tour bus and do the next scripted test.

ET适合测试项目的中期,即使您有大量的脚本测试。 探索性在某种意义上可以理解成在旅游巴士上的游客是探索性的。 让您的分配测试带您访问产品的不同部分,然后简要地对这些测试的主题进行即兴创作。 花几分钟时间完成各种测试,然后回到旅游巴士上并进行接下来的脚本测试。

It’s also how you assure that there is enough variation and creativity in the test cycle.它也是关于你如何确保测试周期中有足够的变化和创造性。

Also, throughout the project, I would suggest that you question the value of the tests allotted to you, since no test process provides complete coverage. To improve the breadth and depth of your testing, consider allotting some time, maybe 20 percent or maybe 80 percent (there’s no universal “right” amount of time, other than what fulfills the mission of testing) per test cycle to pure exploratory testing. Pick one or more risk areas in the product and design and execute tests for that, seeking to find important problems fast and collecting information that will help the project evaluate the state of the product.

此外,在整个项目中,我建议您质疑分配给您的测试的价值,因为没有测试过程提供完整的覆盖。 为了提高测试的广度和深度,考虑分配一些时间,可能是20%或者80%(除了完成测试任务之外没有通用的“合适”时间),在每个测试周期中,进行纯粹的探索性测试。 选择产品中的一个或多个风险区域并设计并执行测试,来快速发现重要问题并收集有助于产品状态的项目评估的信息。

Another way to fit ET into a project is to dedicate a particular tester or test to continuous duty doing pure exploratory testing. I ran a team like that once, and I also interviewed a fellow who ran such a team at Nortel. These teams are well trained, and work like a reconnaissance unit, scouring the product and following up on rumors and risk areas.

将ET融入项目的另一种方法是将特定的测试人员或测试专用于进行纯粹探索性测试。 我经营过这样一个团队,我还采访了一位在北电管理这样一个团队的人。 这些团队训练有素,像侦察部队一样工作,搜索产品并跟踪“rumors”和风险区域。

Doing exploratory testing well requires skill, no matter when you do it.无论何时进行探索性测试都需要技巧。

Before I made it my goal to master the art of simultaneous test design and test execution, I felt confused and bewildered by the process, too. I eventually developed certain heuristics, notetaking protocols, and skill in modeling, reasoning, communication, and self-management that allow me to be productive under almost any circumstances. The process is creative, but it’s a learnable discipline that fits anywhere testers are expected to use their minds.

在我把掌握同步测试设计和测试执行艺术作为目标之前,我也对这个过程感到困惑和不知所措。 我最终使用了一些启发,记录协议,以及建模,推理,沟通和自我管理方面的技能,使我能够在几乎任何情况下都能高效。 这个过程是创造性的,但它是一个需要学习的学科,适合任何领域的测试人员使用他们的思想。

* 注:本文来自网络投稿,不代表本站立场,如若侵犯版权,请及时知会删除