需求的沟通
开发方与业务方之间最常见的沟通是关于需求的。业务方描述他们认为自己需要的东西,程序员按照自己理解的业务方表达的需求来开发。
在现实里,关于需求的沟通是极其困难的,其中会出现各种问题。
过早精细化
做业务的人和写程序的人都容易陷入一个陷阱,即过早进行精细化。
1、不确定原则
每次向业务方展示一项功能,他们就获得了比之前更多的信息,这些新信息反过来又会影响他们对整个系统的看法,这种现象也叫观察者效应。
2、预估焦虑
开发人员会掉进精确化的陷阱。他们知道必须评估整个系统,而且通常认为需要精确评估。
评估可以而且必须基于不那么精确的需求,这些评估只是评估而已。开发人员通常会在评估中使用误差棒,这样业务方就能理解不确定性。
迟来的模糊性
避免过早精细化的办法是尽可能地推迟精细化。但是,这可能造成另一个问题:迟来的模糊性。
在具体的语境中看来,意思可能是非常清楚的,但是对阅读文档的程序员来说,意思可能截然不同。
验收测试
业务方与开发方合作编写的测试,其目的在于确定需求已经完成。
“完成”的定义
完成意味着所有的代码都写完了,所有的测试都通过了,QA和需求方已经认可。这才是完成。
沟通
验收测试的目的是沟通、澄清、精确化。
自动化
验收测试都应当自动进行。原因很简单:要考虑成本。
额外工作
验收测试是为了确定系统的各项指标符合要求。确定系统的指标;程序员才能确知“完成”;业务方才能确认开发的系统确定满足了需求;做到自动化测试。
验收测试什么时候写,由谁来写
在理想状态下,业务方和QA会协作编写验收测试,程序员来检查测试之间是否有冲突或矛盾。
但实际上,业务方通常没有时间,或者有时间也难以达到所需要的细致程序,所以他们通常会把测试交给业务分析员、QA甚至是开发人员。
业务分析员测试“正确路径”,以证明功能的业务价值。
QA测试“错误路径”、边界条件、异常、例外情况,因为QA的职责是考虑哪些部分可能出问题。
开发人员的角色
实现某项功能的代码,应该在对应的验收测试完成后开始。
测试的协商与被动推进
专业开发人员,与编写测试的人协商并改进测试是你的职责。每个人都需要关心错误和疏忽,并协力改正。
验收测试和单元测试
单元测试是程序员写给程序员的,是正式的设计文档,描述了底层结构及代码的行为。关心单元测试结果的是程序员而不是业务人员。
验收测试是业务方写给业务方的(可能会由开发者来写),是正式的需求文档,描述了业务方认为系统应该如何运行。关心验收测试结果的是业务方和程序员。
图形界面及其他复杂因素
测试系统功能时,应当调用真实的API, 而不是GUI。
持续集成
务必确保在持续集成系统中,单元测试和验收测试每天都能运行好几次。
在持续集成系统里,失败的集成应该视为紧急情况,也就是“立刻中止”型事件。