2

black_tulip

原帖由 herah 于 2009-10-28 19:08 发表
18楼说的在理阿
曾经第一家公司就是这样的小公司，开始我还劲头十足的想要搞这个搞那个呢，后来发现没用，公司看中的是要满足客户的时间要求，东西只要没有大的问题就可以了。觉得自己在测试过程等方面根本毫无提高 ...

确实，用最短的时间，最有效的方式，满足客户的需求。客户都满足了，你还有什么不满足的吗？你需要提高的是对工作的把握。

wuyuzimu

大部分公司不规范

gnian

啊呀   看了这个帖子  怎么感觉自己已经很幸福了  我在软通做测试半年多了  有自己的team 一切都是很标准 文档、数据、测试库 什么的  都有  原来这就是传说中的专业啊  有点小感动  虽说工资也就够交个房租  还不够交个女朋友

洪建伟

软通不是做外包的吗？

Jackc

原帖由 black_tulip 于 2009-10-29 11:24 发表

确实，用最短的时间，最有效的方式，满足客户的需求。客户都满足了，你还有什么不满足的吗？你需要提高的是对工作的把握。

兄弟，你说的很对，但是苦口婆心没有用。

人，总要自己亲身经历了，才能体会到其中的道理。

PS：忘记补充一个
“亲身经历”不是“明白道理”的充分必要条件。人不同，理解自然不一样，呵呵

[ 本帖最后由 Jackc 于 2009-11-2 11:40 编辑 ]

zte_boy

很多公司确实存在这样的现状，短时间内很难改变
与其抱怨不如想其他办法解决，比如：
1、阅读程序代码了解前端处理
2、阅读存储过程、函数等了解后台处理逻辑
这样不仅可以了解整个系统的处理机制，对测试人员本身来说也是一种提升

black_tulip

原帖由 Jackc 于 2009-11-2 11:37 发表


兄弟，你说的很对，但是苦口婆心没有用。

人，总要自己亲身经历了，才能体会到其中的道理。

PS：忘记补充一个
“亲身经历”不是“明白道理”的充分必要条件。人不同，理解自然不一样，呵呵

为啥你的最佳PK手勋章是个小红帽？

Jackc

谁知道啊，这个得问51的美术了。

如果是偶自己设计的话，那就是：黑色的底色，红亮的"KO"。最好还放点小鞭炮的烟花，加点繁星的闪烁，再来点……
估计一会51的美术就把偶拉出切分尸老~

yolander

很喜欢这个话题，同时表示一下，对black-tulip的支持，顺便声明，我不是愤青
只是我认为，在工作中，很多时候都不会尽如人意，开发过程中的文档缺少，内容不完整，更新不及时，变更时缺少跟踪管理，这样一系列的问题，可不仅仅是在小公司里会遇到，大公司也一样存在，那么遇到这样的问题应该如何处理——
是抓住开发的“小辫子”不放，拼命向上级领导投诉到底？
或者干脆破罐子破摔，也跟着糊涂了事？
我想这都不是解决问题的最佳方式……
如果LZ只是想来这里发帖抱怨一下，我想确实可以找到很多共鸣，也会有很多人表示对你的同情和理解，但如果是想来寻求问题的解决方案，就建议LZ能够冷静一下，看看black的回复
比如他说——“关键的，一个测试人员对所测试的产品不了解，如何能测试好，如何能将测试用例的覆盖率提高，”
// 为什么你还对所测试的产品不了解呢？这个要从自己身上找原因。
这话可能听起来不像表达同情的帖子那么入耳，但绝对是在帮助LZ解决问题的，难道测试人员就只有开发文档这样一条通路去了解产品吗？那么又如何去保证开发人员编写的文档就没有问题了呢？对开发文档的检查同样也是一种静态测试啊
所以，在这里，我倒是想给LZ一点点建议：
1、作为测试人员来说，日常工作中，多注重对所测试产品行业知识的积累，多了解和学习相关的业务，尝试做系统结构的分析，使用恰当的测试技术和方法，再结合自己的测试经验同样可以开发出好的测试用例。
2、在用例开发过程中，要注重复用性，也就是说，尽量减少与UI相关用例的开发，尽量与业务结合，这样再将来开发新产品时，只要业务变化不大，就还可以重复使用，会减少很多测试设计的工作量。
3、在测试过程中，注重成果物的积累，比如测试用例、测试场景、测试报告等相关文档，并尽可能的规范化和标准化，当这些文档在测试过程中收到一定成效后，再将其向你的高层领导展示，就更能说明开发过程中文档的重要性了
当然，我说的这些都还是建立在公司的领导有意愿将产品质量提高的基础上，如果说他就只注重交付时间，其他的一概不管，那么在这样一家公司工作确实也就没多大意思了，而且我相信，秉承这样的一种态度，不要说个人，整个公司都不会有太大的发展了
但是LZ跳槽到别的公司后，可能也会遇到这样或那样的问题，我更希望的是，遇到问题后，能够看到LZ不仅仅是抱怨，而是在积极的想办法改进，或者至少先从个人做起，做一点努力的尝试，相信在一家质量体系健全的公司里，是绝对不会埋没人才的

[ 本帖最后由 yolander 于 2009-11-2 14:03 编辑 ]

parater

如果需求不经常变更，
如果局点很少，
如果解决方案就那么一种，
如果产品不经常升级，
如果处理逻辑，实现方式都比较稳定
…………

这个文档就没什么存在的意义！

但是，
当你面临的是一个HI大的系统，
几百个表，几十个局点，需求经常
有变更，产品经常有升级，
没有文档我不知道怎么干活！
短期内可以通过头脑或者笔记
记一下，如果要查1年或者2年
前的处理逻辑，

怎么办？

问开发？

他不是神！！！

etheltim

对于楼主的贴子，看后很有同感。以前我也遇到过。没文档就问人，只要人家肯说就学习。自己多上测试系统，熟悉业务。当有一定的了解后，不是象刚进来那来随便被人忽悠，在那种“开发就是神”的环境中生存就是要跳出来，勇于表达自己的看法，虽然多数是被忽略。贵在坚持，软件产品就是生产出来被人找错的，说白了就是被人找砸。开发不可能一次次的被原谅。一步步来，现在大多公司还不知道测试能够为其带来什么效益，只是学样招聘测试人员。作为一份职业，你只要在工作中学到知识，自我累积，作为下次工作挑战的筹码，或者跳槽。

majun915

深有同感，不过我不是做测试的，我只是监理，乙方没有文档，我逼他们写 哈哈

lubruth

测试是一个十分重要，但是也是一个没有增加价值的部门，导致很多领导说是重视测试，但是实际行动就是没有。
以开发为重点并没有错，但是忽略测试将是一个不可取的行为。
同样的感受！

whn2009goodluck

同意楼主的想法，但是小公司，努力做，壮大后自己就成为领导了。这样环境下培养的人，遇到问题都会容易解决的。

charleswhite

原帖由 lubruth 于 2010-1-22 13:57 发表
测试是一个十分重要，但是也是一个没有增加价值的部门，导致很多领导说是重视测试，但是实际行动就是没有。
以开发为重点并没有错，但是忽略测试将是一个不可取的行为。
同样的感受！

同意~！ 没有增加价值的部门或岗位，就是这样。
可是，岗位又不是咱雇员制定的。除非你有能力改变这个岗位性质。
要不也别太在意，反正都是这样。
择业的时候要注意选择创造价值的岗位。

huilin.gao

一句老话：“路漫漫其修远兮，吾将上下而求索”

旗杆

不然就成大公司了！

眼·M·小四

原来都是这样啊，做测试半年多了，见到的文档十分有限，很多需求甚至业务流程都是在测试中才问才搞通的，不过也没办法，看到开发的天天在加班，要文档已经是个很不现实的问题了，只能靠自己了，不了解，不清楚的抓着问，估计开发的也被问烦了吧
好在公司还算重视测试的，渐渐的也开始规范化了
加油