有三个方面的验证。作为一个产业,我们如何平衡这些方面导致质量危机,裹着一个调试循环,在约束的随机测试。是时候再平衡。
再平衡的新动机来找我在交谈中我已经在几周前敏捷联盟技术会议。我有机会比较与Lisa Crispin的日常职责。丽莎是一个软件测试专家认为在这是很好敏捷开发社区。把她当成一个哈利福斯特/ Janick Bergeron类型;有人人寻找指导。在与丽莎聊天,我意识到,虽然验证工程师和软件测试人员填写类似的角色在各自的团队,我们根据我们如何设定预期效果参差不齐。
我喜欢考虑预期的我——一个验证工程师验证意图,实现和验证角落探索;这些是我们的三个方面的验证。验证意图通常发生在第一部分功能的一生,开始回到分析和定义阶段。探索性测试接近时将边界发生的功能将被释放,之后彻底测试,但之前装船。中间是详尽的验证实现,确保RTL我们写我们打算做什么。硬件验证往往为了解决这些方面虽然好团队不断关注所有三个。
丽莎,一个软件测试人员,她的大部分时间与意图和探索。她与开发人员工作在编码开始之前他们充实功能细节。她在使用模型提供输入,定义和验收标准。她也有观察孔的使用模型像丢失的特性或客户可能合理预期的交互。探索,丽莎写道,进行探索性的宪章,是有点像一组假设实验,设计目标问题或潜在的问题区域。
奇怪的是,验证实现是一个遥远的第三丽莎的列表。我说这是奇怪因为验证实现往往主宰我的待办事项清单!我认为重点鲜明的差异归结为如何设定预期。当谈到实现质量在丽莎的团队,举证责任属于开发人员。简单地说,当一个人写的代码工作。这是根本相反的期望我们在硬件开发。作为一个产业,举证责任落在验证团队的肩膀上。车实现期望(我们用马车testbenches然后验证)。
在丽莎的团队,会议预期意味着使用开发实践,生产高质量的代码。两个值得注意的实践测试驱动的开发(TDD)和结对编程。TDD和编写代码成对就是节省了丽莎从实现细节的泥潭,让她关注测试的高价值运动意图和探索性测试。
实际上,丽莎的团队已经确认内外相对于我们所做的。虽然她倾向使她的团队的产品更好,我们的大部分时间是被错误打猎。
你会思考TDD和配对;但看着虫子利率产生很难认为他们不是有效的。虽然他们还没有硬件开发的常态,我很高兴地说,硬件设计和验证工程师越来越多地尝试。对我来说这是一个有价值的第一步,把我们的内部验证方法,更好。
现在,如果你不舒服硬件/软件的类比或也许你不购买TDD或配对,随便想一个不同的方向。但不要忽略我们创造了典范,它产生什么!最终,我们如何花费我们的时间和金钱是由谁决定的假定代码质量的负担。今天,我们推卸责任。这是错误的…它阻碍了我们前进的步伐。
|
|
|
|
|
|
|
|
|
|
留下一个回复