来到悉尼2个月了，貌似一切进入了正轨，之前总是对自己不太满意。但是，最近在看《拖延心理学》，其中有一段大概意思是，人们对自己总是有高要求，但是，有些高标准是可以激励进步的，可是不切实际的空想，或者对自己要求“过”高，高要求没达到的挫败感通常会制约进步，所以，我决定，不要“挫败的感觉”！这次呢，就用比较积极的心态总结，之前有些标准太高了，毕竟是要根据自己的实际能力来定目标的。所以，调整一下说法，这2个月，我觉得不错！
下面的总结是某个周五，自己对自己的retro,今天先整理项目方面的总结：
Well
1 目前我所在的项目是一个客户网站其中的一个小部分，项目组成是2对dev,一个BA,一个PM，一个UX（PM和UX是几个项目公共的），还有就是我，a dedicated QA, 这个项目给了我很多很多空间时间思考，这是之前twu的模拟项目以及参与的西安office的第一大项目欠缺的。之前，我总是有依赖的思想，总会犯“光干活，不思考”的错误，但是这个项目，逼迫着我思考，因为太多不确定，太多空余时间，什么都需要我自己去问，去想，所以，如果不思考，彻底不知道自己还能干嘛了。所以，思考了很多，比如，这个业务需求为什么会这样？项目的测试策略该怎么确定？对于这个功能，主要能从哪几个方面测试呢？这样测试够了吗？出现了这个现象，是bug吗？这个bug是让dev立马修呢，还是先记成bug卡呢，这个从用户角度，合适吗？这样安全吗？别人怎么测的？用的什么工具？哪个自动化框架好些？为什么现在用这个？等等。。希望之后自己能系统总结下。。
先补一下这边的主要工作过程：
迭代0－1我主要关注项目背景和项目需求，熟悉项目环境，测试环境，熟悉同事，熟悉项目组大家的“口音”，其中业务知识主要参考mingle，向BA了解，参与日常小组story讨论以及关注该客户公司的业务领域等，也就是，让自己有足够的“上下文”。
后面的迭代呢，当没有“ready for QA”的卡时候，需要对整个迭代的故事有清晰的了解，准备一些测试数据，一些高质量的测试用例，不明白的需求和BA/UX讨论，还有很多时候是探索性测试，还有自动化测试以及读代码，读书读博客找寻答案，提高技能；有“ready for QA”的卡时，story testing，find bug, analyse bug, discuss bug with Dev/BA/UX, test bug, 这部分还有一些感悟，稍候总结。。
2 coffee is important,成功的项目是一个团队协力合作的结果。工作的时候我一般都是在“找茬”，又由于语言和文化问题，项目之外的其他交流也不多。所以每天的coffee time以及偶尔下班后的pub time，很重要，其实这也是china office的team building吧，这些，对于团队建设，团队合作很有帮助。对于我来说，虽然每次私下的交流，很多时候我还是没办法听懂，但是每次都会或多或少有一些变化，我相信的原则很简单，有比没有强。事实证明，还是很不错的。
3 目前项目进展顺利，每次 showcase客户也很满意，项目规模小，氛围很好，上班时候发现bug,学习到的东西让我有成就感。至于交流方式，一开始，我听不懂的时候，我会交流之前先稍微想想词儿，并且大概问题写到纸上，带着笔和纸去交流，或者直接带电脑去交流；后来，慢慢地不那么紧张，也更加熟悉业务领域，熟悉大家口音，所以就可以直接过去交流了，要是没听懂的，当时人多没好意思打断问的，就私下里再一对一交流，效果还不错，反正，能解决问题就行，不管是什么方式。
Less Well
1 语言还是一个问题，以及文化，对于每周和客户的showcase, 目前多由dev或者ba负责，我很矛盾，一方面很想参与，一方面不够自信，怕影响showcase效果，目前,showcase主要是show一周迭代完成的功能，一般都是happy path, 所以综合考虑，貌似BA比较合适
2 自动化测试，我参与的比较少，原因1：目前项目采取的测试框架比较简单，dev一般在开发story的时候就实现了；原因2：我的代码功底还是不够，之前写的一些测试，代码质量不太高，后面也被重构掉了。。
关于自动化测试，想说一下，自动化测试不能一概而论，需要根据不同的项目需求背景和项目人员情况，采取不同的自动化测试，其中自动化程度不同，采用的框架也不同。针对于本项目，主要是2个表单A,B，整体业务流程比较简单，但是现存的代码中有有2套自动化测试框架，一个比较完善全面，有page object,各种配置文件，是已经release的表单A采用的测试框架；现在表单B采用的测试框架，比较简单易懂，之前和dev讨论过，他们的意见是，之前的过于复杂，对于目前的项目需求来说后者的测试框架更合适，目前有时间的时候我在研究这2种框架，希望之后能有所总结。。
3 目前项目一周一迭代，dev主要着重开发story,对于 defect wall上的卡关注比较少，这个绝对是个问题，好几次我都提出过了，但是还是重视不够，之后还要重申，怎么才能有点影响力呢？至于重视bug的原因呢，简单说来就是，大部分bug遵循2：8定律，也就是，出现bug的地方也是最容易找到其他bug的地方，所以需要prioritise bug－－－>fix bug---->regression testing, and find more bug, 补充说明，貌似这周迭代形式有所好转，
4 测试有时候也需要pair,一方面，测试过程中可以brainstorm， 可以产生更多的测试场景；另一方面：工作氛围更好，更有团队合作的感觉（起码对我而言是这样的）；第三：可以pair 写一些自动化测试代码，
Suggestion :
工作上更自信，更主动些，这些都不是口号，不是一朝一夕就能改变的，主要可以通过2个方面改善：
1 学习永无止境，项目过程中，多思考，多学习代码，多动手，让自己在技术上有所长进
2 对于一些工作或者生活上困扰的问题，多读书，看相关博客，请教别人，让自己少走一些弯路，早点找到答案
3 定一些切实可行的标准，不要好高骛远，克服拖延。。
早下班了，走人。。。