开发人员在提交测试人员测试时，须具备哪些要点？

wfq80825

如题，
在平时工作中，开发人员会把做好的东西提交测试人员来做，但是他们往往出了提交的东西外，什么也不多说，拿到东西，我们有时候都看不懂这是干什么的？因此我想退出一条规则，用来约束开发人员提交给测试人员东西时，能按照这些约束来进行，这样合作会更顺畅一些，大家觉得的？
在线等~~

janezhang815

你好，我也遇到同样的问题。现在我这边暂时规定，开发提交测试代码的同时，说明已经可以测试的功能

qrz2000

嗯,一般是这样的,
送测的时候,需要填写一个送测表,里面包括本次送测的功能点.
布署环境的要求等等...

billrub

测试接收标准 >> 建立测试接收规程

标准依实际情况自定，如：
主功能失败
需求文档接收失败（文档接收标准自定，如：不全占>10%，歧义需求>20%等拒收）
详细设计文档接收失败（同需求文档接收过程）
接收程序内容不全（缺失部分组件、插件）
系统级错误（退回重设计）

等等。。。

Feiyang

你希望他们说什么？说出来，跟他们协商。要正式提出来，列举出你们的苦恼，和现在一直这样做的后果，不做到这个说服能力，就别想办成。
你要和上边的领导及开发领导沟通，有些简单的测试约定，稍微强势一些，不写提交说明就不给测试。

fanli2000_0

Release Note：这个是个很关键咚咚噢。
如果没有Release Note, 但有点程序经验的话，应该拿到这个软件就知道哪些功能没有完成，哪些功能是已经完成的但出现了bug。
我目前的做法是这样的，没有Release Note， 你可以先给开发沟通一下， 是否可在下个版本完成此项功能，或给出确定完成的期限， 要是过了这个期限，还没有完成的话，你完全有理由当bug来提交。这恐怕也是一种避免责任的问题sdlkfj5 ，要是上头问下来，开发会说测试没有测出来， 一旦提了...

archonwang

2。必须的文档必须完整，如需求、用例甚至是设计
3。代码完整，预期的完成目标已可以使用。满足通过smoke test。

hshg0784

建立电子申请表单机制
表单中必须包含
1.  测试需求提出人的一些信息
2.  测试软件
3.  release note (包含解决的bug,未解决的bug等）
4.  产品spec
5.  测试需求（例如：功能性，稳定性）
6.  预计测试完成时间

chengcai

的确有必要，在测试管理规范中就需要约定这块，开发人员开完程序提交程序，不能说提交就提交，要先提交测试申请单，单元测试报告，以及详细设计和实现的功能需求，通过测试主管的审查认为可以进行提交测试，才可以提交给开发人员进行后面的测试．否则可以不予接受．针对上面的文档基本上就可以测试他们所提交的程序了．

chbhaha

还没遇这种情况，先学着点再说

wfq80825

大家说的很有道理，但是由于公司管理上的混乱，往往实施上没有一星期，就又“偷懒”了。
并且要测试人员反复的多次叮咛，这样又给测试人员增加了压力，而公司其它管理者又不上心，去管理，因此这样往往会造成，开发人员觉得测试人员太烦了，所以之间摩擦或误会也会增加。
公司往往推出一些治标不治本的管理做法，且实施力度太浅，导致现在软件管理流程的极度混乱。无奈中。

lieryang

如果管理实在不规范，可以将过程中出现的问题以书面的方式反馈给你的上一级领导，请他去沟通。如果你提出的规范可行的话，可以考虑请他们同时提供：
1、环境配置文档
2、修改或新增功能说明
3、测试需求（系统测试或只是部分测试、重点测试什么）
4、考虑版本变更

smilesun666

测试需要的环境里的数据是否齐全...
最好是开始测试的时候就准备好,否则,会挺麻烦的.而且影响测试和开发效率;

violet10

学习。

bzcyer

最近写的测试任务申请单
详细的看里面了

tianhuachuan

感谢分享！

liangjz

我们内部实施当不符合条件时的 测试退回机制.且得到了技术副总支持
包含:

代码
文档
人力
时间
单元测试需求
功能文档
性能需求(可选)
安全需求(可选)
。。。

wzts1985

谢谢

madskill

谢谢

zhangj8826

谢谢分享