Showing posts with label qa. Show all posts
Showing posts with label qa. Show all posts
0
Posted on
Saturday, February 18, 2012
by
醉·醉·鱼
and labeled under
qa
这一篇旧文，原文写于2011/11/8，记录在evernote里面，直到今天才翻出来。翻出来的时候，还是感觉诸多不爽：对自己语文不好的不爽；对测试现状的不爽。现在努力去发现一条能够很明了看清楚整个项目进度，状态的方法。 51testing和淘宝测试团队一起，在软件测试行业里面都很出名。前者以BBS为平台，分享、讨论测试信息；后者是淘宝测试团队的官方博客，显得比较专业、务实。
吐槽开始:
- 我现在所在的测试团队还算不错的。
以前我一直以为自己所在的团队比较糟糕，但是没有想到还有比我们还糟糕的团队，所以，我还是算庆幸的了。当我自己发现别个还在纠结的问题，我们已经做到并且在考虑其他问题的时候，一种莫名的优越感油然而生（好吧，我都被自己给恶心死了。。。）
比如，当我听说别个还在纠结"0缺陷"的时候，我自己只能够表示同情加吐槽一番。对于一个还在纠结"0缺陷"的公司、测试经理来说，我都比较万分的恐惧。犹如我们不可能进行100%的测试一样，我们也不可能很肯定地说这里没有bug。即使说，我们真的把所有的bug找出来了，由于时间，人员，资金等等问题，迫使你不可能将所有的bug修掉。"0缺陷"，是个梦，现实还是残酷的。
当然，我们自己还是有不好的地方，比如说，现在大家都还在纠结测试用例，尤其在用了TestLink之后。 - 对于0缺陷的"老大"，我心存敬畏。
这样的完美主义会毁掉一家公司的！处理bug泄漏率还是有很多办法的，不是不可泄露，但是不能泄露严重的bug出去。在对测试团队的评估上，有一个硬性度量叫"缺陷泄漏率"。但，这个不是简单的将泄露的bug数量统计出来，而是将这个值进行加权以后拿出来衡量的。比如，我泄露了4个不严重的bug出去，加权以后数值为1(4*0.25)。而如果我泄露一个很严重的bug出去，加权以后数值为4(1*4)，那么，测试团队需要在这次泄露以后做分析了。 - 没有需求分析员居然成为理所当然。
在这样的氛围下，"借鉴"别人的成为了理所当然！为什么中国团队在不停的抄袭，未曾超越。将需求分析员独立出去，而不是拉入测试或者开发团队。且需求分析员先于测试和开发编写文档，以保证需求文档的及时性。
无论是国内的单独某家公司还是国内的整体情况，都是如此。比如，腾讯游戏，抄袭可谓无所不及了。（好吧，魔兽世界他还是没有办法抄袭的！）又比如，国内的各种微博，SNS，视频网站，在国外都能够找到鼻祖。没有看到中国特色且自己喜欢的网站，除了豆瓣。但是豆瓣网站还是处在如此纠结的地方，开发出来的新产品，却一点都不考虑用户的体验，好几个产品弄得一塌糊涂，�惶得很。 - 关于招聘。
对于招聘的时候，NB的人要价很高。本来就是，物以稀为贵。此外，能够帮你解决一堆问题的人，你为何要吝啬你那几个钱？而且，按照Joel的理论，一个优秀的程序员能够顶替3个一般的程序员，已经不再是所谓的"三个臭皮匠，顶个诸葛亮"的世界了。按照这样的计算，3倍工资也不为过。而且，3个程序员带来的价值并不是简单1+1+1=3，而是小于3的。 - 英语很重要，沟通很重要。
邀请外援过来培训，效果不是很理想，结果不怪自己不行，在吐槽如何如何听不懂。无论你描述的多么凄惨，多么可笑，无法掩饰你自己能力不行的事实。 - 测试的跨度很大
测试的跨度很大，有相通之处，却很难从IT瞬间转移到IC行业。可能说，管理上面，有些类似之处，但是底层/前线人员，却是很难很难。会上测试人员分布从软件到硬件，从敏捷模式到V模式，都有，显得很杂、很乱。 - 变更管理和监测是很重要的。
基于变更的测试才是快，狠，准的。基于自动化工具，快速定位regression测试范围，即基于变更进行相应的测试。
吐槽完毕。
0
--醉醉鱼
Posted on
Thursday, August 04, 2011
by
醉·醉·鱼
and labeled under
qa
自从Mary和Neo离开公司以后，和Paul的聊天总是带着那么一点点的悲伤。我不知道为什么会这样，没有过多的过问。但是，隐隐约约，还是感觉到对工作的那种无力。这种感觉传到我的身上，渐渐扩散开去。
常常，我总是拖着自己疲惫的身体走下楼，然后按下电梯按钮，慢悠悠的晃回去。我知道，如果路上有人撞我一下的话，我很有可能就躺下睡去，不再爬起来了。无论窑主如何怎么给我画饼，我还是没有能够接受到她的精髓所在，依旧感觉事情好多，好杂。无论Chris告诉我，"你还没有到瓶颈！你又迷茫了！"但是，我却想说，我累了。无论目标多么的明确，无论志向多么之远大，无论你今天的日程安排得多么之华丽，打断，琐碎，几乎将你废掉。这不是所谓的能者多劳，这不是所谓的团队合作，这不是所谓的高效的communication。。。我所希望看到的团队是每个人都各有所长，且合作起来总是愉快的，大家的沟通的有效的，更为重要的，要和你志同道合的人干着那么几件令人兴奋的事情。
没有看到，没有看到，真的没有看到。每每想要去做一件事，总是感觉到无力，低效。想要写一个工具出来，以前用rescue time跟踪，每周还有4个多小时用在eclipse上面。现在呢，一周连notepad++都很少打开。想找人讨论，抬头一望，一个人都没有，憋屈的自己一个人在角落里面抓破头皮，心里就像歇斯底里一样的嘶吼。这个是我想要的么？为啥Endurance没有这样的一种人？
公司Hackathon了，我思量了一下，自己还是算了。就这样，每个月写不到200行代码的人，情何以堪啊~ 看着Camps那么多人去参加hackathon，感觉他们牛人好多，回头一看Endurance，原来的3个manager早就跑得远远的，丢下一副烂摊子给新来的manager，弄得新来的manager时不时说："我怎么感觉今天没有做啥事呢？我怎么还在这里呢？" 几个有能力的开发也没有去参加Hackathon，到底又是怎么了的？QA还是那样，忙得不亦乐乎，Chris还有着将QA匀点出去的意思。即使前提说道，等Endurance足够smooth，我总觉得这句话不是那么的可信，新的产品，总是会需要人的。一副忙碌却缺乏活力，激情，想法的team。
有人会选择微博去絮絮叨叨，我还是习惯了这样的日记体。牢骚发完了，睡觉去了。哭。。。
0
Posted on
Tuesday, June 07, 2011
by
醉·醉·鱼
and labeled under
qa
- 其实，我不是QA，只是一个测试人员而已。
- 其实，严格来说，我的不是burndown chart，应该是burnup chart。
- 其实，我不是想装逼，但是，还是习惯了散装英语了。
公司在运行敏捷模式，其实有一个很有趣的图，就叫燃尽图（burndown chart）。在每个开发周期之前，dev/qa团队都需要对自己的任务进行预估。预估的时候，要考虑到风险的存在和自己团队的能力来预估。每天，每个人在下班之前都需要对自己任务记录时间，这样，就可以通过这个图表来判断你做了多少了，还需要多久能够完成。期间如果发现不够的地方，可以进行及时调整。到产品开发周期完成的时候，自己的任务应该是归零了的。
再看看自己的图吧！
我的确看见自己在log time了，如图中蓝色的线那样。但是作为QA，每个周期总有那么几天没有东西可测，于是你可能看见中途蓝色有一段时间是平的。总体来说，我在log time了。
再来看黄线，表示预估时间。开发周期已经开始了22天以后，QA才开始进行时间的预估。嗯，问题是，太迟了，PM那边完全不知道你到底能够做多少，进度怎么样。此外，自己的预估还不准确，此后还不停调整拨高，最后到达51个小时。（此后为回归测试时间，不考虑入内。）好吧，我总得来说，预估时间和实际时间比率为4:5(39:51)。
最后，再来看看绿线和红线。红线和黄线的起点是一样的。但是这次由于预估得太迟了，导致红线和X轴几乎持平。绿线表示自己还剩下的task有多少。一般，正常来说，红线为斜率为负数的线段，而绿线则围绕红线周围逐渐下降，直到最后归零。
这次，最失败的地方，就是黄线的预估和实际偏差太大了。
- 测试用例设计预估时间的时候，忘记了阅读需求时间的预估，此外还有邮件来回讨论等buffer的考虑。
- 测试用例执行预估时间的时候，忘记了对测试用例步骤复杂度的考虑。有些用例虽然只有一步，但是可能前面准备就需要很多个步骤，所以每个case花费的时间将近两倍，甚至三倍。此外，报bug的时间，和验证bug的时间，都没有考虑在这里面，仅仅考虑用例设计的时间。
0
琢磨估计高兴过头了，最近接二连三得犯错了，自己松懈了。错，自己还是挺害怕的，毕竟，自己的错，被别人发现，自己还是很不爽。此外，问题还有就是，怕自己的错又忘记了。
- 有一个bug，是关于sql。都知道sql里面column header需要unique，否则会报错。dev在修的时候，假设了column header都是unique的，我也就这么接受了这个fix，还报了两个limitation fix的ticket去跟踪。问题就是，这里所谓的limitation实际上是不可接受的，在之前就应该refuse的。
不要接受不可接受的fix。 - 这样的问题，要想得更远。
上次报了一个问题，是ui上面不应该显示这样的日期。后来，我们发现，这里的日期有问题，开始日期比结束日期还迟。继续查到数据库，发现在DB里面就存错了。继续就在代码上找到了error。此外，后续的影响也应该要注意，特别是对客户的。比如这个问题可能就是没有办法注册了。
0
Posted on
Sunday, May 30, 2010
by
醉·醉·鱼
and labeled under
qa
抄书抄书。Test Plan.
Test Strategy.The test plan is the set of ideas that guide or represent the test process. Often those ideas are only partially documented, spread across multiple documents, and subject or change as the project evolves.
The test strategy specifies the relationship between the test project and the test mission. the strategy deals with what will be tested and how. Test strategy is distinct from the logistics of implementing the strategy.
Test Cycle.
- Receive the product.
- Configure your test system. (Not included in my testing process.)
- Verify testability. (This is what automation guys do? Smoke testing?)
- Determine what is new or changed. (Improve needed.)
- Determine what bugs have been fixed. (Improve needed.)
- Verify fixes.
- Test new or changed areas.
- Test other areas.(remember, higher risk stuff first.)
- Report results.
0
Posted on
Tuesday, January 19, 2010
by
醉·醉·鱼
and labeled under
automation
,
qa
Hi guys,
Do you want to make a new registration record when you want to verify a bug on Reg View? Do you want to a lot of registration records to help your test? (真像搞传销的。。。ORL) Here is tool to save your time: You can just record the actions on the browser, save the script and run it next time. It's simple.
For IE:
http://www.iopus.com/download/
For Firefox:
https://addons.mozilla.org/en-US/firefox/addon/3863
For Chrome:
https://chrome.google.com/extensions/detail/cplklnmnlbnpmjogncfgfijoopmnlemp
Notes:
- It's not available on Flex, so don't use it on AUI. J
- You can modify the script as you wish, such as "TAB OPEN" means create a new tab.
- For more demo or details, please see http://www.iopus.com/imacros/support/
