Page Tracking tools

Background

There are 5 common tracking tools in the market:

  • Google Analytics
  • Krux
  • Omniture
  • Sizmek
  • Nielsen

1. GA (Google Analytics)

What is it?

  • Free
  • Analysis the behavior of the internet users and helps the business make wise decision.

How to test it?

  1. Use GA real time feature to verify the page view and events.

    GA

  2. Download Omnibug extension for Chrome

    Omnibug

  3. Download Google Analytics Debugger and check the GA tracking in the javascript console in the browser

    Google Analytics Debugger

2. krux

What is it?

Krux helps the clients to collect the non-PII( IP host address, pages viewed, browser type, Internet browsing and usage habits, Internet Service Provider, domain name, the time/date of a visit to a website, the referring URL and a computer or device’s operating system information to analysis:

  • who are the consumer
  • where are they come from?
  • why do they like me?
  • where do they go?
  • what is the right strategy to engage them?

Please checkout http://www.krux.com/privacy/ for more details

How to test it?

Download Omnibug extension for Chrome

3. Omniture

What is it?

  • Non-free
  • A set of Analysis tools

How to test it?

Download Omnibug extension for Chrome;

4. Sizmek

What is it?

Sizmek is the world’s largest independent third-party ad server. And also you can use Sizmek tracking measure the effectiveness of the market campaign, e.g. how may clicks are coming from the advertisement.

How to test it?

Browse to , and turn the “testing” mode as “On”(Do remember to "Save"), then when going to the page with Sizemek tracking, there will be a new page shown for all the info sent to the mediamind server.

Sizmek

5. Nielsen

What is it?

Nielsen study consumers in more than 100 countries to give you the most complete view of trends and habits worldwide.

How to test it?

Use Chrome extension - Observepoint to verify the neilsen tracking for applications pages.

我的出差1、2、3

看着一大波的出差贴,也勾起了我对这几年出差的回忆(虽然我现在还在出差)。尽管文笔不佳也想来叨叨下我的出差故事。。。

一个人的时光

一个人,关键字:TWU,印度

2010年以毕业生身份入职TW,第一次坐飞机,第一次出国,第一次穿纱丽,第一次和外国人做朋友,第一次safari,第一次hiking, 第一次做tatoo,第一次坐auto,第一次踩牛屎,啊呀,太多的第一次都发生在印度班加罗尔TWU那六周了,回想那段日子,有焦虑有担心但更多的是好奇惊喜和不断的震撼。

TWU的课程出乎我的想象,当时我们前2周在酒店上大课,后4周在班加罗尔办公室参与mini project。课程内容与学校课程有很大不同,让我印象最深刻的是乐高游戏,结对session。当然,上课形式也很多样,大家可以横躺竖卧地倒在地上听讲参与讨论,可以找个酒店花园凉亭上小课,也可以去户外做游戏体会合作精神,等等

印度TWU

记得某次课后有幸参与到了班加罗尔办公室的一次hanna tattoo这项传统艺术,看着那些用神奇草指甲花叶子磨成的膏画出来的图,真的很震撼,话说,我人生中第一次tatoo陪了我几乎2周的时光。

纹身

TWU有过一次hiking活动,大家坐大巴加步行到一个小湖边扎帐篷做游戏,其中一个游戏是大家分小组用竹竿和绳索做皮筏过河。没想到我们组划到湖中央的时候天空下起了暴雨,大家被迫上岸光脚冒着大雨跑回大本营,路上草地上到处都是混着雨水的牛便便,踩着的时候那个酥软啊。大家回去帐篷的时候大家都淋成了落汤鸡,永远难以忘记大家围住火堆聊天吃点心,火光闪烁在每个人的眼睛里的情景。

Hiking

TWU课程快结束时候在我们在酒吧举行了一个聚会,感觉像是参加成人礼,第一次喝洋酒,没把握住有点芒,后来几次被同学录像“嘲笑”呢。

喝酒

还是一个人,关键字:客户现场,悉尼

从TWU回来机缘巧合(一个不长不短的故事)去了悉尼客户现场做项目,这次是在悉尼半年。英语不好,内向怕生,项目经验不丰富也阻挡不了“初生牛犊不怕虎”的气概,去之前因为错过了周内中国银行兑换澳元的时机,只能带着从另一位同事手里临时换来的100澳元毅然前往悉尼,现在想想真是胆大啊。

在客户现场一切都是新鲜陌生富有挑战的,那是我真正意义的第一个项目。别提怎么去影响客户了,能听得懂日常沟通对我来说都是最大的挑战。但是那时候一直记得在郑大晔校时候资深同事说的“珍惜自己当菜鸟的时光”那句话,硬着头皮“不懂就问”,频繁地“确认”成为了那时候我的良方。

那半年,除了在项目上的战战兢兢,还有值得一提的是我参加了墨尔本《specific by example》的培训,更系统地地接触到了测试设计,自动化测试等知识,那次体验对我受益良多。当然,我还有幸地参加了一次澳洲办公室的away day,session已然忘记,但是那时“work hard, play hard”的情景一直记忆深刻,因为那时的主题是夏威夷风,我还记得平时甚是严肃的程序员都换成女装妖娆的样子。

NBN

蓝山

TW Couple 两个人,关键字:成都,悉尼

也是源于出差,我在西安也收获了自己的爱情。2012年7月到2013.3,我们一起去成都出差,那时候第一次和同事去悉尼客户现场接项目,我的内心是很忐忑的,短短六周把肚子里能掏出来的都倒出来了,各种会议各种协调,感觉特别没谱,好在当时有熊节每天和我们catchup,硬着头皮把项目接回来了。

客户现场

在成都第一次参加了公司的P3项目-立人图书馆。对于这个饱含着理想和情怀的项目,当看到QQ邮件里关于立人被迫停止经营的时候,还是忍不住唏嘘不已。

立人图书馆

平生第一次公开跳舞献给了TW成都2012年会的舞台,同时也见识到了酷炫的cosplay。

年会

一直记得离别时没来得及吃的那块蛋糕,还有同事朋友们的每一句祝福,现在每每看到这张照片,想到当时的场景,心里都是暖暖的。谢谢成都的各位兄弟姐妹。

成都

TW Family 三个人,关键字:西安,我的第二故乡

2014年12月,产假还没修完,但是我已经又在出差的路上了,不同的是,生活中我换了一个身份,身边多了一个小家伙,这次,我是真正拖家带口在出差了。

遇到一个自己喜欢的项目,遇到一个发挥自己价值的团队让我小小的产后抑郁也渐渐消退,充实的工作,如饥似渴的学习让我每天上班的时间成就感满满。这次出差让我有了很多锻炼自己的机会,比如测试技术的积累,影响客户和coach新人的机会等等。同时也让我对于各种事件有了更深入的认识和思考,也促使自己不断的积累和总结。说实话,在一个平均年龄超过30的“Senior”不进步都难啊!:P

团队

这段时间里在我的监督和校对的辅助下,某人也完成自己的第一本书。这对我来说也算是个小小的成就吧。:)

公寓在公司附近大大缩短了通勤时间,再加上新妈妈每天一个小时哺乳假让我在小家伙最需要我的时候最大限度地陪伴她长大。这一年让我遇到这么棒的团队,周末我们去过很多地方,摘草莓,户外烧烤,袁家村吃好吃的,壕鹏家聚餐等等都让出差多了许多温情的色彩。出差的路上也让我又机会结识不同文化的人, 比如我们组之前的南非同事,他真的解释了我很多疑问,比如南非宝宝是不是一出生就是黑皮肤,比如他们一撮撮的头发真不是自己编的吗,比如南非总统有几个老婆几个孩子,等等。总之,出差路上遇到了很多人,遇到了很多惊喜,

团队活动

这段出差的旅程还会继续,我依旧期待之后会有什么样的惊喜。

最后,借用许生生同学文章的一句话作为结尾,因为这也是我心里最大的感触:

“这几年的差旅,给予我最多的不是分分钟收拾好行李出发的技能,不是淡定面对所有离奇突发情况的强大心理,而是一种更棒的视角,让我能微笑着面对每一次项目结束的告别,面对每一次愉快聚会的散去,面对离家时候缱绻愁思,潇洒地一合掌:“各位,江湖再见!” 因为,我深深知道,所有告别的人,所有离开的地方,一定会江湖再会。到时候,会是更有趣的事情,更好的大家,全新的开始”

Bug Bash

什么是Bug Bash?

Bug Bash http://en.wikipedia.org/wiki/Bug_bash,也称为Bug大扫除,是软件测试的一个很重要的实践,是对日常测试的有效补充,它在很多互联网公司(比如微软,淘宝等)都是一项重要的测试实践。简单的说,Bug Bash就是对产品找茬;具体来说,就是在产品稳定的阶段,选取一个特定时间段邀请一组不同角色和背景的人员在会议室里对被测产品找Bug。一旦发现问题后可以请熟知产品的观察员确定是否是Bug,对发现最多或者最严重Bug的人员给予一些奖励。项目组成员在搜集好所有Bug和潜在Bug的清单之后,全员进行Bug分析,制定出解决的方案并实施。

为什么在测试中我们会引入Bug Bash呢?

由于参与Bug Bash的人员有着不同的角色和背景,甚至来自不同的项目和领域,所以每个人都会通过自己的观察,结合自己的经验,给我们的测试工作带来更多的视角,帮助我们发现那些被我们忽视了的问题。因此通过Bug Bash,我们可以:

  1. 发现尽可能多的问题。对于确定是Bug的问题,项目组成员可以通过分析Bug产生的原因,避免类似的Bug再次出现。而有些发现的问题不一定就是Bug,可能是一些潜在的需求,我们同样可以分析这些来优化我们的产品。

  2. 了解不在预期之内的用户行为。通过了解这些用户行为,我们能分析出哪些用户旅程User Journey是需要添加进我们的测试场景中,甚至需要加入自动化测试的。

  3. 对于并发的测试,尤其是多用户同时执行不同的场景。大部分时间我们在测试产品时都是单人在操作,即使我们有性能测试来覆盖这些场景,但是通过Bug Bash,我们可以更好地接近用户真实使用产品的并发场景。

  4. 进行更多的用户测试User Testing。一般来说我们在开发中会不断地进行用户测试,来验证产品是符合用户习惯,以及开发方向是正确的。鉴于产品可能需要保密,并且使用Bug Bash可以用更小的代价,进行更多的用户测试,所以我们会不时地进行Bug Bash。

Bug Bash除了给我们带来上述4点主要益处,还可以为我们带来一些附加的价值:

  1. 帮助QA更深入了解系统。在测试过程中QA进行测试,会不断加深对于产品的理解;不过由于在Bug Bash中QA需要向其他人员描述产品,并规划不同的测试场景和目标,所以会对自己已有的产品知识进行更深入的梳理,而且通过Bug Bash最后的分析阶段,加深对于产品远景、目标和原则更进一步的理解。不同的QA之间也可以相互进行学习和交流。

  2. 宣传项目。通过Bug Bash,我们可以邀请不同部门,不同角色,不同背景的人员参与,所以无形中就向更多受众宣传了自己,对于项目获得更多资源,以及通过受众进一步影响更多的人。

  3. 引发更多关于产品的思考。根据Bug Bash搜集的问题列表,项目组成员会对这些问题进行集中讨论,并详细解释如何处理以及为什么这么处理,让项目组所有成员对于产品都各抒己见,而且通过这些讨论,引发更多的思考。

既然有如此多的益处,那我们如何组织Bug Bash,还有哪些细节需要注意的呢?

1. 活动准备

  • 首先确保被测产品功能基本稳定。如果被测产品还处于不断出现Bug的开发早期或者中期,就不适合进行Bug Bash。因为如果进行Bug Bash,发现的大部分问题都是已知问题,并不能带来很大的价值。所以我们最好确保被测产品功能基本稳定,并且进行过性能测试和并发性的测试(至少可以支持并发操作)。

  • 其次准备对应的测试设备。例如对于Web和桌面产品进行Bug Bash,我们需要准备足够的显示器和键盘,甚至椅子,来保证Bug Bash可以顺利进行;自然,对于测试移动App,我们也需要准备不同型号和操作系统的移动设备。

  • 除此之外,我们需要准备产品的特性列表并且准备Bug Bash中参与人员需要完成的任务列表。这份任务列表一般会基于不同浏览器,不同平台,不同语言,不同功能模块,设计出针对每组参与人员需要完成的不同任务列表(具体实例见图1)。对于参与人员的分组,具体根据参与人数和特性列表来确定,可以一个人一个组,两个人结对,或者两个测试人员和组内一个QA结对(这么做是因为这样可以及时确定发现的Bug是否有效)。当然如果组内QA有限,可以让QA充当全场的观察员动态协调。
    图1 - 根据产品的特性列表制定的Bug Bash任务列表

    图1 - 根据产品的特性列表制定的Bug Bash任务列表

  • 同时,我们还需要准备好测试环境和测试账号(如果涉及角色权限等功能的任务),并把这些测试环境信息通过邮件告知参与人员,或者张贴在Bug Bash活动场地附近,以便Bug Bash中所有人可以随时获取这些信息。

  • 我们还需要设计一个Bug报告模版并告知参与人员。这么做的目的在于方便参与人员及时记录发现的Bug,也便于我们在Bug Bash后重现和分析bug。因此Bug报告模版格式尽量简单清晰,最好能有截图来帮助说明Bug。Bug报告可以是电子的也可以是纸质的,需要注意的是,尽量保证Bug Bash的参与人员可以方便地访问模版,从而进行Bug记录。

  • 重中之重的是确定参与Bug Bash的人员。这些成员既可以包括组内各种角色,比如开发人员,业务分析人员设计人员,项目经理,还可以包括产品经理,客户;当然,邀请一些对产品不太了解的人员也是很重要的,因为他们更能从一个新鲜的视角来测试产品,比如公司销售,前台或者其他组的开发和测试人员。在Bug Bash举办前,我们需要确保有足够数量的人员参加,尽可能地提高举办Bug Bash的投入产出比。

  • 我们还需要确定进行Bug Bash的时间和时长。在项目中后期,我们通常会以两周或者一个月的频率进行Bug Bash,比如利用午休时间进行1~1.5小时的Bug Bash。当然不同的项目Bug Bash时长和举行时间各自不同,但是原则上,选择尽量适合所有参与人员的时间段和时长。

  • 除此之外,确定举行Bug Bash的活动场地。我们可以选择会议室,来帮助参与人员专注于发现产品Bug,而且由于会议室远离常规工作的场所,有助于为参与人员提供一种新鲜的视角。当然,如果基于宣传的考虑,我们也可以选择公共区域作为活动场地。

  • 在确定了Bug Bash的参与人员,时间和地点之后,应尽早向所有参与人员发出邀请,确保参与人员都有时间参与。

  • 最后,在Bug Bash开始之前我们准备一些小奖励(比如酸奶,巧克力和小礼品),等Bug Bash后发放给每位参与者,以感谢他们对于活动的支持。

2. 活动中

  • 在Bug Bash正式开始前,我们首先要欢迎并感谢所有参与人员,说明本次测试目的、时间、流程、规范和奖励规则等,使所有人都明确Bug Bash会如何进行,以及他们在活动中需要如何测试和记录Bug。随后,我们向每个测试组分发需要测试的任务列表、测试环境和账号,以及纸质或者电子的Bug报告模版。

  • 当正式开始Bug Bash后,每个测试组中的两位参与人员需要共用一个显示器和键盘(或者移动设备)进行结对测试。对于确定的Bug,测试组需要记录其重现步骤,并且记录在Bug报告上。如果条件允许,还需要让测试组在测试报告中添加对应的截图。对于不确定的问题,作为观察员的QA可以适时参与确认,减少测试组在一个Bug上花费的时间。

  • 与此同时,QA作为观察员,除了在测试组中进行协助并帮助确认发现的Bug是否有效之外,还需要观察每个测试组的行为,必要时还需要了解他们这么做的原因。如果条件允许,我们还可以通过录制视频来记录每个测试组的操作过程,以便后续的Bug分析和用户测试分析。如果测试组在完成某项特定的任务时有不能解决的争议时,如果QA作为观察员也没有办法说服双方,那可以暂停并切换到别的任务。此时我们也需要记录任务切换的原因和相应的细节信息。

  • 最后,作为观察员的QA可以记录测试组完成特定任务所用的时间,以便在Bug Bash后对用户测试进行分析时,了解对应功能的可用性和易用性。

3. 活动总结

  • 准时结束Bug Bash,并对参与者赠送一些小礼物(比如酸奶,巧克力等)来感谢大家参与测试。我们还需要对发现最多Bug或者发现最严重Bug的参与人员给予特殊的物质奖励,例如具有团队Logo的徽章或者T恤等。

  • 当然作为组织者,我们还要负责搜集并整理所有发现的Bug。具体来说,首先合并重复的Bug,并且验证它们的重现步骤,尽可能附上对应的截图。最后,组织项目组所有成员就是否需要修复Bug,Bug优先级达成一致意见,这样便于尽早解决高优先级的Bug。

  • 对于那些需要解决的Bug,我们还要考虑是否需要把它们添加到手动测试用例集和自动化测试中。进而考虑是否需要把新添加的自动化测试用例/场景和已有的自动化测试用例/场景进行合并,以保证所有的测试都是分层的,而且是符合测试金字塔的。

  • 针对所有确定的Bug要分析其产生的原因,制定相应的计划以避免再次产生类似的Bug。

  • 在制定了对于Bug的解决方案和计划之后,我们可以通过邮件或者其他方式,如故事卡墙或者缺陷墙,告之所有参与人员。这样不仅可以让参与人员更有参与感,更重要的是使更多人监督我们执行这些计划。

  • 最后,我们还可以整理Bug Bash中收集到的数据(测试时长,录制的操作视频等),检查是否功能设计不合理,导致用户需要很长时间才能完成操作,从而做出产品改进。

千里之行,始于足下

也许你觉得在项目中实践Bug Bash很耗时间和精力,而且不一定会得到领导的支持。其实我们可以在更小的范围内,例如只是项目组的测试人员中开展Bug Bash,通过成果展示来一点一点地得到各方面的支持。

虽然以上是笔者在敏捷软件测试中总结的Bug Bash实践,但是Bug Bash的形式并不局限于特定的开发方式,所以我们可以在自己的项目中采用这个实践,来帮助我们促进产品日臻完善。

html/css学习笔记(二)

接上篇html/css 学习笔记(一),这段时间项目和个人事情明显加多,进度变慢了,但是得提醒自己不能懒惰,继续总结。。。

这段时间其实还在折腾Gmail template, 从页面来看,变化不大,最多的是是明白html代码架构,更熟练地应用各个属性等。有点痛苦的感觉,也逐渐明白什么叫做扣html。

以下仅仅是我学习到的几个知识点,具体内容和原理都没有详细表述。因为其实这些知识点google得到的结果更准确些:)

1. Gmail template继续重构,达到以下几个目标

1)css module

推荐阅读 http://smacss.com/book/type-module

1
2
3
4
5
6
7
8
9
10
11
12
13
14
new_message li {
text-align: left;
margin:0px;
padding:10px;
}
.new_message li.title{
background-color: black;
color: white;
}
.new_message li.recipients{
color: #848484;
border: 1px solid #848484;
height: 10px;
}

2)加入Common.css/ Reset.css

跨浏览器神马的最讨厌了,有木有?那就用reset吧

关心reset历史或者八卦的可以移步 http://ued.taobao.com/blog/2009/03/reset_css_a/
目前比较全的CSS重设(reset)方法总结 http://blog.bingo929.com/css-reset-collection.html

一段相同的css出现了n多次,代码很冗余,有木有? 那就把公用的部分抽出来放到common.css里吧

2. CSS Image Sprites

页面的每个图片都是一个http request,所以如何提高页面加载速度,我们需要把页面中的图片进行组合以较少请求,详情请参考阅读 http://css-tricks.com/css-sprites/

3. UI选颜色

如果你也遇到了每次想设置背景颜色,但是不知道具体值,只能写”white/black”的话,请参考阅读 http://html-color-codes.info/chinese/

另外,在做项目的时候,总结了2个知识点,分享给大家:

1. clear:both的妙用

如在DIV + CSS设计网页中,经常需要设置多个DIV并列排列,这个时候就需要使用float来实现,但问题出现了,当前面并列的多个 DIV总宽度不足100%,下面的的DIV就很可能向上提,和上一行的并列的DIV在同一行,这不是我们想要的结果。使用Clear属性正好可以解决这一问题。

2. @font-face

http://www.smashingmagazine.com/2011/03/02/the-font-face-rule-revisited-and-useful-tricks/

3. width, height如果可以少用就少用, float: left也要少用,涉及到调浏览器时候的痛苦。

4. 如何让链接a 没有下划线,text-decroation

5. 能去掉不必要的div就尽量去掉—-让代码更加清爽

6. Background—设置Button/page background

Homework: Gmail

html/css学习笔记(一)

之前也学过几天html/css,但是这2个星期里自我感觉进步最快,简单总结下。。。

一、循序渐进之html/css

  • ul/li ol/li dl/dt/dd
  • block inline元素
  • box model—padding margin
  • class VS id
  • clear
  • position
  • media queries

二、必杀技

  • clearfix 比如当父元素no float, 子元素float, 并且高度大于父元素时,这样父元素无法被撑开,可用该必杀技
  • position: relative 比如想解决radiobutton 图标和字不在一行的问题
  • margin: 0 auto 比如解决横向居中的问题
  • visibility:hidden 和 display:none的使用场景

三、推荐一个无敌网站

http://learnlayout.com/ 超级适合学前端开发的新手

四、我的作业:

Gmail

gmail.html Html代码

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
<!Doctype html>
<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
<link rel="stylesheet" href="gmail.css">
</head>
<body>
<div class="skin">
<div class="header">
<img class="logo" src="Gmail_logo.png"/>
<!-- <div class="input_wrapper"> -->
<input class="input"/>
<!-- </div> -->
<!-- <div class="search_button_wrapper"> -->
<input type="button" value="Search" class="search_button"/>
<!-- </div> -->
<p class="user">xmyang1221@gmail.com</p>
<!-- <div style="clear:both;">
</div> -->
</div>
<div class="left_pannel">
<input type="button" value="Compose" class="compose">
<div>
<ul class="ul">
<li>Inbox</li>
<li>Starred</li>
<li>Important</li>
<li>Sent Mail</li>
<li>Drafts</li>
<li>Backlog</li>
</ul>
</div>
<div>
<hr class="hr">
</hr>
</div>
<div>
<ul class="ul">
<li>xiaoli</li>
<li>xiaohong</li>
<li>xiaohe</li>
<li>xiaozhao</li>
<li>xiaoli</li>
<li>xiaoxiao</li>
</ul>
</div>
</div>
<div class="right_pannel">
<dl>
<dt> xiaoli</dt>
<dd class="subject"> welcome to TW</dd>
<dd class="time">Apr,8th,2013</dd>
</dl>
<dl>
<dt> Xiaoli</dt>
<dd class="subject"> TW policy</dd>
<dd class="time">Apr,8th,2013</dd>
</dl>
<dl>
<dt> Xiaoli</dt>
<dd class="subject"> TW policy</dd>
<dd class="time">Apr,8th,2013</dd>
</dl>
<dl>
<dt> Xiaoli</dt>
<dd class="subject"> TW policy</dd>
<dd class="time">Apr,8th,2013</dd>
</dl>
<dl>
<dt> Xiaoli</dt>
<dd class="subject"> TW policy</dd>
<dd class="time">Apr,8th,2013</dd>
</dl>
<dl>
<dt> Xiaoli</dt>
<dd class="subject"> TW policy</dd>
<dd class="time">Apr,8th,2013</dd>
</dl>
</div>
<div class="new_message">
<ul>
<li class="title">New Message</li>
<li class="recipients:">Recipients</li>
<li class="subject:">Subject</li>
<li class="body"></li>
<li class="submit">
<input type="button" value="Send">
</li>
</ul>
</div>
<div>
</body>
</html>

gmail.css Java代码

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
.skin{
/*max-width: 800px;
margin: 0 auto*/
}
.header{
height: 50px;
border:1px solid grey;
background: #D8D8D8
}
.logo{
display: block;
height: 50px;
width: 200px;
float: left;
}
.input{
display: block;
float: left;
padding: 10px 50px;
height: 20px;
width: 100px;
}
.search_button{
display:block;
float: left;
width: 60px;
height: 30px;
margin-top: 10px
}
.user{
display: block;
float: right;
height: 30px;
}
.left_pannel{
background: #D8D8D8;
width: 200px;
height: 600px;
float: left;
}
.compose{
display: block;
float: left;
width: 80px;
margin: 10px auto;
}
.left_pannel .ul{
display: block;
list-style: none;
width: 60px;
margin:0px;
padding:15px;
}
.hr{
width:200px;
size:1px;
color:#848484;
}
.right_pannel{
float:left;
position: absolute;
margin-left: 200px;
height: 600px;
}
dd.time{
float: right;
width: 100px;
border-bottom: 1px solid #D8D8D8;
}
dt{
float: left;
width: 80px;
border-bottom: 1px solid #D8D8D8;
padding-left: 5px;
}
dd.subject{
width: 300px;
float: left;
border-bottom: 1px solid #D8D8D8;
}
.new_message{
position: absolute;
right: 10px;
bottom: 10px;
border: 1px solid black;
height: 300px;
width: 300px;
background-color: white
}
.new_message ul {
list-style: none;
margin:0px;
padding:0px;
}
.new_message li {
text-align: left;
margin:0px;
padding:10px;
}
.new_message ul li.title{
background-color: black;
color: white;
border-bottom: 1px solid #848484;
}
.new_message ul li.recipients{
color: #848484;
border: 1px solid #848484;
height: 10px;
}
.new_message ul li.subject{
color: #848484;
border-bottom: 1px solid grey;
height: 10px
}
.new_message ul li.body{
color: #848484;
height: 120px
}
.new_message ul li.submit{
background-color: #D8D8D8;
}

五、心得

  1. 任务驱动,比如,模拟Gmail
  2. 针对同一个作业持续完善
  3. 网站关于前端开发很多资料,要针对开发过程中遇到的问题一点一点google解决
  4. 将html/css各种属性和具体场景关联记忆

QA and BA

去年7月初开始和某银行保险项目的合作,到我明天下项目,都9个月了。其中,经历了2个项目,其中一个项目由于客户那边的人力资源缺乏问题仅仅维持了3个月;另一个呢,则从开始到现在都6个月了,预计今年6月上线,也就是总周期预计9个月。

和之前不同,这次我在项目中挑战了BA/QA双重身份,简单小结下我理解的两者的工作内容:

(仅代表我个人项目的经历,不一定和敏捷中QA或者BA标准高度匹配,特此申明下)

QA(Quality Analyst)

开发前:

以Story为载体,通过和BA讨论,获得对需求的全面了解,并在开发人员开发之前,确定测试用例集;或者,根据项目需要,和开发人员结对进行功能性自动化测试。

开发中:

随时和开发人员和BA沟通,确保测试用例都实现,针对一些大家都不确定的需求,会找客户产品经理确认。

开发完成:

开始各种测试,侧重探索性测试,因为之前所生成的测试用例,团队默认在开发中这些已经被开发人员实现了,所以开发之后的测试更要侧重一些之前没有写下来的测试场景,侧重回归性测试等

BA(Business Analyst)

需求分析前:

尽量熟悉产品,分析产品用户群的操作习惯,分析产品的商业价值以及产品经理对产品的定位。

这些都作为在后续活动中的指导方针,比如,这个项目是个针对保险索赔用户的个人信息管理网站,那质量和用户友好性将是最重要的,在后续的开发和测试中,任何关乎用户体验和页面质量的问题我们都需要注意。

需求分析中:

将大块需求,拆分成大小合适,相互依赖较小,可测可估的story, 并且针对这些story,和客户的产品经理深度沟通讨论,把全部信息记录在story上,也就是AC(验收标准),这个是作为后续各种开发和测试活动的沟通载体存在的。

需求分析后:

story有着清晰详细的验收标准,并且测试人员,开发人员都对需求有个一致的理解,这才是分析任务结束的标准。这之后呢,需求分析人员就要随时根据测试或者开发中出现的预期之外的问题做出响应,比如,测试人员测试发现了一个Bug, 分析人员就要根据产品的定位做出相应的响应,比如这个是不是对产品产生致命影响的,是不是可以暂时降低优先级的,等等,如果还是无法确定,就需要和客户产品经理直接沟通了。

3年?3天?

这周是在成都出差的最后一周,项目上的事情大部分都交接完了,突然闲了下来,很是不习惯,但是,好好珍惜这3天,过几天我就要离开呆了大半年的成都了,开始在北京的新的项目了,新的一轮忙碌即将开始。

回顾下开始工作以来的这三年,像过电影似的,这3年的经历比我前二十多年的经历要丰富的多:)

  • 2010年2月开始实习生身份进入公司,开始怯生生的职场生活,那会办公室初建,小小的办公室,热火朝天的心态,大家一起努力着,动不动一个办公室的人出去聚餐,也不过十几个人。

  • 半年之后,研究生毕业了,也正式入职了,第一次坐飞机,第一次出国,第一次去成都,第一次和那么多老外一起学习生活,第一次攀岩,第一次露营,太多第一次了,那段培训生活充实,也教会了很多我从课堂和书本学不到的东西。

  • 接着,因缘际会,我到了悉尼,半年的客户现场工作,让我压力倍增,痘痘狂冒,体重飙升。但是,回过来了,记住的永远是甜蜜开心的日子,友好的客户,善良的同事,黄金海岸墨尔本的旅行趣事,接家人一起出国旅行的成就感,三五好友的深山烤肉,有澳洲那蓝天白云青山绿海,都让我心驰神往。

  • 从悉尼出来,在西安呆了整整一年,那一年发生了不少不愉快的事情,行李丢失,房屋漏水赔偿等等,我也剪短了我的发,只为重新开始。但是,这一年的工作确实是令人开心的,工作氛围轻松,同事集体拍写真,关系好的都是腻在一起吃饭学习k歌,日子就可以溜达到了2012年4月。

  • 我遇到了能够和陪伴我一生的人,从此阳光又温暖起来,风儿也轻柔起来,在那个美好的春天。

  • 接着,订婚,装修,件件事情接踵而至。 而我也来到了成都出差,这确实是一个美好的城市,美食,周边好玩的地方,以及和煦的空气。这半年不停地行走在路上,西藏,厦门,新疆,平遥,北京,西安,丽江,旅行让我时不时停下来回头看看自己的生活,让我珍惜眼前,心胸更加广阔。

  • 马上,就要去北京工作了,留恋成都,想念西安,但是,人生不就是有失有得嘛,尝试下在雾霾帝都生活下也没啥不好,可以让我更加清楚自己的方向嘛(自我安慰下:-/)。

13年步入了我职场生涯的第三年,也即将进入我人生的新阶段,希望这一年有所希冀,有所突破 both work and life:)

What lessons I learned as a Q-BA?

Q-BA here is referring new BA who acted as a QA before, just like me…

I acts as QA in the last two years, and although I tried to do some stuff related to business, however, it is slightly different when I acts as a full-time BA in the current project.

In one word, I think the difference is, as QA, I accept the fact that all the behaviors is well-considered and good enough, then the only think I need to check is if they are working well.

However, as BA, I think I should be more critical of the proposed option, and try to find if it is really suitable for the business needs.

Lesson1: Does sad path really matter?

From QA perspective, especially when most of happy path is guaranteed by kinds of tests, then finding evil scenarios to break the application is really important in my QA career.

So at the beginning of the BA career, I always tend to find out all sad paths for the scenario.

Example:

When I am working on the story elaboration of one story” save and send email”, which is about asking the user email, then send the product info to the user via email.

Then

From QA perspective,

I mainly focusing on handling the bad path, how about it is empty, how about if it is too long, how about if it is not well-formatted

From BA perspective,

First thing is to see if it makes sense to ask user to input it again, how about pre-populate it since it is asked before? …

Lesson2: Do not be pulled into details too much!

From QA perspective, I did many scenario testing(system capability for user to achieve specific goal) and story testing(provide/get fast feedback along the story development process).

So I prefer to go to details as per each scenario, and try to evolve more detailed scenario.

Then from BA perspective, the whole part is more important than focusing on the small part and detailed information.

Example:

Given we are working on the project in the initiate phase

When prototype comes passed from Business to us for reference

Then

From QA perspective,

I mainly find flaws as per each section, and to check the text field and buttons behaviors.

I mainly find if any spelling errors around all the wording and text…

From BA perspective,

[I need to think more like UX]

Do we need to schedule user testing or expert review of the prototype to see if the design makes sense?

[I need to think more like Dev]

What’s the integration points among the system with other systems?

If the wording and text need to be approved by legal team?…

Lesson3: Go directly to the business for any need

From QA perspective, sometimes I will firstly go to BA if some puzzles happen.And then go to business if necessary.

Then from BA perspective, if any puzzle happen, go to the people you need to ask for answers. Don’t Wait!

Lesson4: Facilitation skills matter a lot

As a BA, the facilitation skill is important to gather the clarification and solution.

There are many scenarios you need to facilitate the meeting at the inception phase of the project, or during daily business discussion, IPM and meetings.

I just realized the importance, and I think the book is really cool, thanks kangkang’s recommendation.

Some thoughts about my job during recent months

Today is my 4th month in OZ, and everything seems work well now. And the recent 2 months I was so busy with my job. And I felt better.

However, during the phase of fitting into the pretty new working env, I endured a lot, and it can be tell from my previous posts. Here I want to share some experiences with the people who is experiencing or will experience the similar situation. The advices are really simple and obvious, however, it is also really helpful.

1. Get help from others

Pair with more experienced co-workers, and also ask for help from others who already has experienced the same things as you.

When paring, try to find what’s the difference between your behavior and others, analyse the distances, and try to be better in the next time. e.g. In the project I am on now, I work with someone has more working experience, and I learn a lot. I will compare our behaviors towards the same issue, and then I found the distance, I began to ask myself, why I did this way rather than that way, which is better? After analysis, you surely can do better next time.

Another example is I find some people had similar experience with me, and I asked for help from them for the experience-sharing. And I find that people always like to be helpful to others. So, ask them, it is not a shame.

2. Ask for feedback on your own initiative

That is to say, sometimes, you feel stressful, it may not because you are not doing well, it may due to the distance between your expect ion towards yourself and others.Maybe you are expecting too high or too much.

Stress sometimes acts as a motivation. But I like to work happily. I need the encouragement and suggestion from others. Thus, for the people in the similar situation, if the uncertain and in-confidence you have will make you stressful and not happy, try not to be shy or lazy. Just have some conversations with co-workers, either by free talk or email. People always be afraid of the unknown things. And then, you may have much more context about the situation where you are. you will be encouraged by the feedback about what you do well, and also you can have directions about the future improvement towards the feedback what you did less well. Make the unknown to known. Sometimes, it will go out of your imagination.

3. And most important, find some people you can complain to

Of course, you will have some complaint from the start. So you should complain, either to your family members or your close friends, but try to find somebody who can bear you. Of course you can find other ways to release the stress.

4. Always to be nice

From my point of view, disregards the ability, I like to work with the kind people. Especially act as my role, I always have to have conversations with different people, Devs, BAs, UXs and so on. However, always to be nice is not equal to give up your baseline.You should speak up if something goes wrong, you can do this in a acceptable tone or method.

5. Do your job well try your best

This is what you can control. so try to do best. Be positive and be hard-working. You need have correct attitude towards your job.

The above is what I can summarized as the good aspects, and also I know what I did not so well, I will continue to improve on that, hope I can share some later.

读书笔记2--克服拖延的一些tips

不同的人,拖延的诱因不同,比如,有的是害怕失败,有的是害怕成功,还有的是害怕被掌控的感觉,等等。每个发现有拖延毛病的人都可以在书里找到症状,然后感同身受。

最近读书比较慢,但是一直在继续,当我确定了自己的“症状”后,便开始寻求方法来“治疗”,所以先略过了书中一些内容,找到了一些简单的小贴士来慢慢“缓解”症状,以下tips是结合自己理解的读书笔记:

  1. 确定一个切实可行,明确的,小并能达到的目标,而不是一个模棱两可,泛泛的,不切实际的目标。

    比如,就拖延这个问题,你与其说,我从今以后再也不拖延了,还不如说,从现在起,我每天要花一个小时来读《拖延心理学》,并做必要的笔记。 另外,针对那些比较庞大的目标,比如减肥,你与其说,我一个星期要减5斤,还不如说,我每天要吃8成饱,并且一周至少跑步3次,先坚持一星期什么什么的。

  2. 在时间分配上要从实际考虑,不要太理想化。

    问问自己,要完成这件事需要多久,你目前有多少空闲时间?具体说来,就是不要想当然,与其觉得自己总有很多时间来做这件事,还不如,具体翻开日程表,确定自己哪段时间确实有空,并能做这件事。

  3. 立即开始做

    俗话说:千里之行,始于足下。对于一件你要完成的任务,要尽快开始。

  4. 使用那15分钟

    比如,你想读书,你一般12点睡觉,所以如果某天到了11:45,你躺在床上,与其说, 就剩15分钟了,能干什么呢,不如停止犹豫,就利用这15分钟,能看多少就看多少呗!

  5. 要对挫折失败早有预期,这样才不会太有挫败感

  6. 吝惜你的时间

    要懂得说“NO”, 不要什么都要抓,要抓一些对自己来说最重要的事。

  7. 不要总找借口,把借口当作拖延的理由。

    比如,与其说,我太累了,以后再做吧。 不如说,我是很累,那就只花15分钟看会书,看完就睡。

  8. 一直要鼓励自己,注重付出的努力,不要太看中结果。

    不要陷入0或者100的思维模式,要记得,任何一小步都是进步。所以,与其说,除非我一周减掉5斤我才会觉得成功。不如这样想,恩,我已经开始跑步了,并且我在努力,我很开心,今天可以奖励自己看电影

  9. 要单纯地把拖延看成一个信号,而不是意味自己彻底的失败

    不要总是觉得,我又在拖延了,我讨厌自己。还不如这样想,我又拖延了,为什么呢,是不是我的目标还是太大,我是不是要调整下呢?

总之,要记住:继续拖延,还是立即行动呢,这就在一念之差。