What should a QA Engineer do?
测试应该做什么：
理解需求>>>按需求编写测试用例>>>按用例执行测试过程,并找bug、提bug>>>开发解完bug后再进行验收
好的测试应该做什么：
1.把需求按自己的理解剖析清楚，并按自己的理解和产品碰头，不合理的地方提出见解
2.编写更详尽的测试用例，尽可能覆盖多的场景
3.发现问题能清楚的定位问题，越明确越好，尽可能找出更深层次的原因，提出自己的考虑及想法
4.解bug的方法会不会影响到其他功能，对影响模块进行重测（包括已实现、未实现）
产品需要创造力，毋庸置疑
开发需要创造力，我理解在代码逻辑、代码复用程度…
那...测试需不需要创造力？？？
普遍的研发体系，阶级固化地（潜意识地）认为测试不需要，反映为一个功能模块如何测试，开发认为产品需求给出了目标导向，至于过程和方法就按我说的做，结果按我想的实现就ok，不ok提bug拉log...这也是为什么研发体系QA地位不如开发的体现
我不否认对于过程和方法很有必要和开发沟通确认，毕竟某一个模块实现逻辑在那儿，想要知道怎么测就得理清原理，但是对于方法和结果，就应该是测试创造力的体现，结果其实就是案例，案例的丰富也就是创造力的体现，就像1+1=2，okay！我从开发那儿知道了1+1为什么等于2，检验了1+1也等于2，但是还没有完事儿，测试用例应该包括1+1等于0、等于3、等于字符串、等于10…测试应该有自己的一杆尺（权利），从而来评判这个结果接不接受
那么既然测试的工作不是开发来安排，而是自我创造性的，工作内容就应该得到区分！哪些该测试来做，哪些该开发做，毕竟测试并不只是提供bug、提供log的机器人。开发在提交一个功能完善的模块之前，应该是自测ok的；当然，测试收到这个ok的模块的测试请求，首先会验收它是否如开发描述的结果，然后！按自己的理解去做更多的测试工作，按自己的尺度去衡量是否通过。
那如果一个功能模块开发没有时间、精力、场景去测试，我也希望能有一个规范的流程来解决，例如想测什么、实现逻辑、预期收到的反馈（不是结果），能以提测流程的形式来解决，这样才算是协同工作，而不是听候差遣。
不希望一个 bug一而再再而三复现，因为同一个原因复现
也不希望一个测试案例一而再再而三地执行
测试的工作应该是高效地、创造性地，而不是打下手、重复性的
对于工作体验的重复性，我是深恶痛绝的
测试是第一用户，而不是需求的检测员
