这是一个创建于 1700 天前的主题，其中的信息可能已经有所发展或是发生改变。
我先来：
- 某个页面是很多脚本的功能，被要求在点击浏览器返回页面后，所有功能必须正常。
- 所有的 Tab 都要求保留状态，就是选了第二个 Tab，刷新后也一定要在第 2 个 Tab 。
- 根本没有宽度和适配的概念，原型设计出来的横排内容就必须完全照着排。
然后就直接提出 Bug，根本不给你商量....
来，大家开开眼界，我深刻认为我这不是最惨的，算是非常普通的遭遇。
 |
1
Lin0936 2020-04-28 10:57:40 +08:00
Android app, 弹出来的键盘跟原型设计上的长得不一样.
|
 |
3
shunfa52000 2020-04-28 11:19:27 +08:00
兼容 ie8：doge
|
 |
4
rrfeng 2020-04-28 11:22:52 +08:00
1 2 很正常啊，现在的前端不都很简单做到么？
3 说明设计图不完善，你可以找 UI |
 |
5
OmO OP @rrfeng 是可以做，不难，只是我个人觉得没必要针对 1)和 2)，但他们觉得很重要。因为一边会有很多业务上的需求，这项目又是我一个人负责全栈。新的需求一直在来。但他们遇到的这些“小问题”有一些很耽误时间，要改又会影响整体进程。有时候觉得有点头疼。
|
 |
6
wdhwg001 2020-04-28 11:30:50 +08:00 via iPhone
从 ux 的角度上看 1 和 2 确实很重要啊。
|
|
7
OmO OP @wdhwg001 确实从用户体验角度上是很重要，因为本来是小公司。项目人手不多（就我一人，前端偶尔能支援下），我现在就觉得上班时间要这样这些覆盖方方面面，快不够分配了。（一般到点就溜了）
|
 |
8
imn1 2020-04-28 12:32:44 +08:00
如果只有一个人全栈在做，却有 QA 岗位，这公司确实奇怪
|
 |
9
jptx 2020-04-28 13:01:15 +08:00
每个 bug 都要分清优先级，一般按 bug 严重性从最高开始往下解决，按我的话，前两个 bug 被打标为“优化建议”，并且设为低优先级，第三个 bug 要求发起讨论。这样就能避免花费大量的时间解决这种意义不大的问题了。如果老大问你这些 bug 为什么一直不解决，你就把 bug 列表打开给他看，让他知道当前有更高优先级的 bug 等待解决。如果老大要求提高这些 bug 的优先级，就得让他承担“需求延期”、“重要问题得不到及时修复”等后果
|
 |
10
otakustay 2020-04-28 13:14:19 +08:00
1. 这应该是 PM 的职责，为何流程会流转到 QA 来提，这值得好好搞清楚
2. 我不认为第二点有什么问题，QA 站在用户的角度提出来完全合理的 3. 楼主看起来是 FE，那最好意识到 FE 的工作不仅仅是做出页面，同样要去教育其它的工种，建立不同角色之间的共识，才有可能把事情做成 |
 |
11
yhxx 2020-04-28 13:17:04 +08:00
前几天看到一个：
测试把配置文件里的一行删掉了，然后服务挂了，一个严重影响流程的重大 BUG 诞生了 |
 |
12
dallaslu 2020-04-28 13:49:48 +08:00
很久以前，因为 IE 状态栏一直有一个三角叹号，每个页面都被记录了一个 bug 。
后来使用 window.onerror = function(){ return false } 全部解决了。这样就算真的有 bug，至少能收到某个按钮不工作的程度的具体反馈了。 |
 |
13
xiaoliu926 2020-04-28 14:21:40 +08:00
测试在测试过程中，删除数据库中登录用户，导致一些列 bug 。。。然后就提了 bug
|
 |
14
lingll 2020-04-28 14:41:54 +08:00 via Android
找产品来定夺
|
|
15
OmO OP @xiaoliu926 哈哈，我也遇到过类似情况。。。还说万一某种特殊情况导致这条数据被删除了呢怎么办，还是得改对吧 ...
|
 |
16
isRealLeven 2020-04-28 15:35:46 +08:00
刚遇到提的 bug：弱网情况下，视频无法加载。
|
 |
17
yhyh 2020-04-28 16:18:12 +08:00
有时候 产品流程 和 交互细节 一开始原型上并没有说的很明白。就会导致很多 测试提的产品交互的"bug"过来，这个倒还好，关键就是几个测试，每个人意见不一样，看到不合适就提个 bug 这时候 其实就要产品出动， 然后产品呢，自己的想法 要不不坚定 要不没想到， 这就会出现 测试提什么 他就让做什么 = = 。到这一步，四五个人的想法 揉在一起，有时候 简单的需求 就搞的很复杂 这中间 bug 列表 已经飞了
有一年，6 个测试测我。80% 的 bug 就是交互这种的。加上项目时间紧，老板要一个月上线，留给我们前端的开发时间 已经不多了 前期开发 老板还说 没事，bug 不算绩效，尽量保证项目上线 年底 我的 bug 是组里最多的。 ：我还是太年轻，没明白老板的良苦用心 之后遇到问题，哪怕耽搁上线 也要一个一个说清楚 毕竟 xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx |
 |
18
Pichai 2020-04-28 16:21:58 +08:00
@isRealLeven 弱网下多长时间要给用户有响应的提示。
|
|
19
OmO OP @yhyh 对，一定要说清楚，不然最后算绩效什么的，亏的是自己。我就吃过一次亏，前端支援我们这个项目的一个页面。里边的一个背景颜色和设计图不一致，还有些小的交互问题，我看前端忙就说唉算我头上吧先，后面我看情况来分给前端，或者直接自己改了。（那时没有说 Bug 要影响绩效）后面做复盘，我就被清出来，说哪里哪里有好多 Bug，累在一起，完全没法解释清楚了。。。后面就每个 Bug，只要不是我的，一定怼回去让改成优化或者直接让分给别人。免得一时好心，变成傻逼...
|
 |
20
allenpzx 2020-04-28 16:40:00 +08:00
1. 这种优化一直提的话无底洞
2. 应该找产品确定需要做成什么样，补文档说明 3. 子页面和子 tab 概念不太一样吧，还是要看具体业务场景来划分，楼上说“我作为 xxx 觉得需要”，那是不是也有人可以说“我作为 xxx 觉得不需要”，觉得需要最好直接拿出依据，那样才有讨论的必要，要不然你问了那就是需要... |
 |
21
fancy111 2020-04-28 16:46:02 +08:00
123 都没问题
|
Select Language