学习、施用敏捷开发一年多，也写了一些笔记，想结识朋友一块交流

学习、应用敏捷开发一年多，也写了一些笔记，想结识朋友一块交流，
我把自己的在学习和应用中的一些心得写到博客里了，希望感兴趣的朋友看看我写的东西，向我开炮，评论下，交流下。我的博客是：http://blog.csdn.net/jianfengqu


我现在学习没有人一块交流，好可怜啊！
------解决方案--------------------
勤写读书笔记是个好习惯，
------解决方案--------------------
以前在学校看过uncle bob的那本经典敏捷书籍. 
写过一篇关于敏捷的文章, LZ给点评价
http://blog.csdn.net/pony_maggie/archive/2010/01/29/5270506.aspx
------解决方案--------------------
大家一起交流好，建议LZ抛出一个或几个问题，在帖子里讨论才有针对性。
否则帖子变成了博客广告了
------解决方案--------------------
好呀，共同学习了，呵呵
------解决方案--------------------
一直沒有機會實踐，不過頂下
------解决方案--------------------
共同学习，我们现在的项目就是采用敏捷开发模式，如敏捷下的测试如何开展，大家有没有什么好的建议？
------解决方案--------------------
测试用例太详细确实太费时间，这个要把握一个度。但这个度却要视团队的开发水平而定。
其实敏捷开发非常依赖程序员的个人素质，如果团队的素质不高，敏捷开发最终比瀑布模型更混乱。
------解决方案--------------------

引用:

  我们团队中有专门的测试人员，在敏捷开发过程，我建议他们不要写太详细的测试用例。可以只根据系统功能写基本的测试条目（主要是正常流程），而其他细节，包括异常的测试只需要根据测试人员的经验测试就行了（需求上有特殊要求时另当别论），把测试出的问题记录在td上，或直接告诉开发人员，或写清楚重现步骤通知开发人员去修改。因为我知道，就光一个登录窗口的测试用例要写全了，就得写上几十条，这太浪费时间了，里面很多东西其实测试人员根据经验一测就可以了，完全没有必要写成文档。举例：用户名输入框测试，可以写很多条用例：1、为空时系统的反应是什么 2、中文时系统的反应是什么 3、长度大于100时胸膛那个的反应是什么 4、有特殊字符时系统的反应是什么 5、输入正常的字符，如admin时系统的反应是什么。你看，这有必要写出来吗（我见过详细的用例这些内容都会包含），但像前面4个，有经验的测试人员都知道要测，就不需要写出来了。

  如果在迭代开发过程中就把使用说明书写完了，那么该文档就可以作为测试人员测试的依据。如果使用说明书没有写，也没有详细的需求（敏捷不建议写详细的需求文档），那么，要求测试人员和需求人员经常沟通，明白需求。
    要注意一点：一个迭代里所开发的任务必需在迭代过程中测试完毕，也就是测试人员的工作在迭代中一直进行着，这样的好处是：开发人员刚编写完的程序现在很熟悉，改起来快，尽量不要放在后面的迭代中去。

  开发人员自己的单元测试要做，但是，也必需有专门的测试人员来测试，因为人们总是认为自己做的东西没有问题。

公司没有积累之前的测试用例吗？

积累的部分当然不用重新写啊

而且有些公共的问题可以通过checklist来解决

个人认为实现敏捷的关键就是自动化的测试，这样才能拥抱变化，变更一个内容立刻全部的测试用例都跑一边，看这个变化有没有影响到其他的部分，这个是用手动测试不太可能实现的
当然这需要一个过程

先做手动的测试，编写测试用例很有必要（避免重复劳动），不过要有向自动化测试方面发展的意识


------解决方案--------------------
学习中..............
------解决方案--------------------
看来是要做一些分享了啊.
------解决方案--------------------
学习一下，工程实践啊~