悉尼行-工作retro

来到悉尼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, 这部分还有一些感悟,稍候总结。。

  1. coffee is important,成功的项目是一个团队协力合作的结果。工作的时候我一般都是在“找茬”,又由于语言和文化问题,项目之外的其他交流也不多。所以每天的coffee time以及偶尔下班后的pub time,很重要,其实这也是china office的team building吧,这些,对于团队建设,团队合作很有帮助。对于我来说,虽然每次私下的交流,很多时候我还是没办法听懂,但是每次都会或多或少有一些变化,我相信的原则很简单,有比没有强。事实证明,还是很不错的。

  2. 目前项目进展顺利,每次 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种框架,希望之后能有所总结。。

  1. 目前项目一周一迭代,dev主要着重开发story,对于 defect wall上的卡关注比较少,这个绝对是个问题,好几次我都提出过了,但是还是重视不够,之后还要重申,怎么才能有点影响力呢?至于重视bug的原因呢,简单说来就是,大部分bug遵循2:8定律,也就是,出现bug的地方也是最容易找到其他bug的地方,所以需要prioritise bug--->fix bug—->regression testing, and find more bug, 补充说明,貌似这周迭代形式有所好转,

  2. 测试有时候也需要pair,一方面,测试过程中可以brainstorm, 可以产生更多的测试场景;另一方面:工作氛围更好,更有团队合作的感觉(起码对我而言是这样的);第三:可以pair 写一些自动化测试代码,

Suggestion

工作上更自信,更主动些,这些都不是口号,不是一朝一夕就能改变的,主要可以通过2个方面改善:

  1. 学习永无止境,项目过程中,多思考,多学习代码,多动手,让自己在技术上有所长进

  2. 对于一些工作或者生活上困扰的问题,多读书,看相关博客,请教别人,让自己少走一些弯路,早点找到答案

  3. 定一些切实可行的标准,不要好高骛远,克服拖延。。