敏捷团队里的测试人员扮演着很重要的角色，兼顾着BA，PM，QA的身份。一个优秀的测试人员是最掌握需求的，是最了解拥抱变化的思想的。从项目开始就介入需求分析，需求分析是个很关键的部分，我会另写个文章来表达我的见解。把需求通过story，测试用例，mock up的方式表现出来，让自己清晰的同时，告诉团队中的开发人员他们要做的是什么。
在项目开发过程中，实际上，很大可能地，需求的变更是由team lead和开发人员告诉QA的。基本上是修改好了，做了变更才告诉QA做某方面的测试来验证改动，是否影响了其他功能。QA处于信息流通的下游。
对于一个庞大的系统，QA如何管理好需求，这是个很重要的课题。我之前项目的做法是管理测试用例，bug。一旦需求有了变更，就更新测试用例，报bug来跟踪。对于客户报的bug，要更新相应的测试用例。这是个琐碎的过程。
QA要监控和管理项目的进程，在给客户demo，发布版本之前的什么时候要拿到可测试的build，做多长时间的测试是必需的，掌握好了几个时间点就掌握了版本的质量。实际项目中，QA希望下午三点前拿到一个build，开发人员总是会抛出各种理由来延误交付时间点，比如功能没实现完，这个功能点是必需要交付的，有了新的改动，merge导致代码遗失等。很可能到了下午六点下班时间才拿到一个可测试的版本。
在之前的项目中，在开发提交代码之前，开发会叫QA到工位，show case。开发会演示修改好的bug，新开发的story，QA根据对需求更确切的了解，提出不同的测试用例，演示过后没有问题才算通过。然后开发可能还需要找另一名开发人员review代码，如果代码需要较大改动，改动后，还需要show case，确保功能没有被破坏。在我的工作经验中，产生的第二次show case，大多数都是功能没实现完全导致的，很少有需要较大代码改动产生的。
快速交付，及早的发现问题，反应问题。速度快。