- 讨论过后要有结论，让大家对结论达成共识，避免无效的沟通讨论
- 针对某个问题进行讨论时，难免有人发言偏离主题，要把人拉回主题，提高会议效率
- 技术方案优化：别人是怎么做的？有什么缺点？我是怎么做的？有什么优点？
- 讲话语速放慢，给自己和他人留有思考的时间，让别人听清楚、听明白才是讲话的重点
- 发邮件要仔细检查错别字，发企业微信前先检查一遍有么有语病和错别字，不要等信息发出去了，才发现有问题，然后撤回，给别人的印象不好
- 能说很重要，会倾听也很重要，不要总是打断别人的讲话，着急接别人的话，等别人说完了，说清楚了再接话
- 带着“测试什么，测试测，预期是什么”的思路去听需求，写用例，目标要明确很多
- 漏测换种说法“未做到100%覆盖”
- 找准客户，找到业务sponsor：这个事情不是由你单一决策，需要找到能够为你提供支持的人。
- 10.做正确的事VS 正确的做事
- 好玩比好用重要，不要自我限制，我在当前规则下只能做什么，被迫做什么，在工作中绽放，不在工作中枯萎
- 求之于势不责于人，这个事情是可以做的，但是还不到做这个事情的时候（形势）
- 明确目标、清晰策略、充分资源、过程管理
- 核心优势：别人没有的，你有；他人有的，你更细致、更专业、能力更综合（更广） 。
- 不要总是埋头做事，做事之前想清楚，为什么要做这件事，这件事可以解决什么问题，明白背景和目的之后，再去想怎么做才能达到预期目标，以及如何优化（源于4.8日leader扔给我的一个前端构建迁移任务，接到任务之后，当时光顾着去想做完这件事，但并没有去分析背景和目的，以至于完成任务的时候很抗拒，直到事情做完了，才知道前端构建迁移是为了解决晚上十点之后才能上线的痛点问题，早知道是解决这个问题，那做的时候肯定是十分开心和期待的啊）
- 页面应该展示的东西没有如期展示，十有八九就是前端缓存搞的鬼，这个时候先多刷几次浏览器缓存说不定就有了,如果不是缓存的问题，回溯到项目部署上，去检查代码是否部署成功，是否本地代码是否合到远端分支上
- 测试思维：想办法验证你看到的东西是对的（例如搜索功能），想办法找出应该展示而没有展示的（流程类）
- 当文字很难解释清楚或不好理解时，可以通过画图的方式来解决
- 要宽容，要大度，要有向下兼容的胸襟，不要忘记曾经懵懂无知的你是如何被温柔以待
- 当一个线上缺陷需要测试的时候，思路：测试的对象是什么，当期情况是什么样的，为什么会导致这样的问题发生，要改成什么样子，为什么要这样改，这样改可以解决当前问题吗，我们要怎么测试，预期结果是什么
- 线上问题&事故的避免方法思考角度：1、QA能做什么：补充用例，完善流程；2、开发们以及开发的领导可以做什么；例如防抖功能，前端研发负责人需要针对此类场景严格技术要求进行防抖，QA针对提交场景从前端页面进行防抖测试，将防抖测试加入到测试用例模板中
- 针对倒排期的解决方法积累：
1、方式一：特殊项目：QA评估风险，周知PM、PMO、RD，业务方，达成一致可上线
2、方式二：分级处理，调整资源分配
a. 应用分级，根据优先级分配测试资源，优先测试A级别的应用（前后端都需要分级）；
b. 项目分级，QA只投入优先级高的项目；
c. case分级，QA 只执行优先级高的cas
- 会议一定要提前有topic，让大家提前想一想
- 过程卡点，过程度量
- 规划 执行 落地
- 提前2小时，可以提升多少效率，获取多大收益，而耗费的成本有多大
- 如果中途接到项目，开始执行测试之前，先明确测试的范围，预期结果，对接的人，项目的意义在哪里，如我们一个同事快要测试完了，还不知道BUG应该具体提给谁，都提给了一个人，实际是三个人负责，就导致BUG全部集中到一个人身上，解决不及时
- 临时接到线上BUG前，先了解缺陷的前因后果，然后和产品，开发，共同商讨，定级，是够及时修复，修复方式是否合理，不然单方面听从一方的意见
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
