A同学现在有个测试任务正做着，突然来了一个PM，说有需求要宣讲，二话不说跟着去了，需求刚宣讲完，屁股没坐热乎，另一个PM发邮件说线上有个bug帮确认复现一下，接着又搞这个了，不知不觉，时间过去2个多小时了，测试任务还未有实质性的进展，突然QQ亮了，哎呀是暗恋的一个大学MM，荷尔蒙急剧升高，聊会儿吧。。。有人叫一起吃饭去了，一看时间，午饭时间快到了。午饭归来，浏览下网页，看看微薄，接着干活，测着测着，哎妈呀好不容易发现个bug，但是自个儿还不敢报，怕自己对业务不熟悉提了个NOTABUG的bug，找了下他师傅B同学确认了下，B同学说是bug，兴致勃勃的提交上去感觉很有成就感。不一会儿开发来了，我看看是不是你环境有问题配置有问题啊，一屁股坐在A同学位置上了，啪啦啪啦开始找问题，开发人员终于还是承认了自己的失误，灰溜溜回去解bug了。A同学一看，哇塞，都三点多了，一看用例才执行了10多条，还有好几十条，今晚要发布这可如何是好，必须得加快测试了，执行到一半的样子，发现一个大bug，而且这个bug不修复的话严重影响后面很多case的执行，赶紧报上去。然后自己接着测试，到了5,6点多了，用例跑完了，终于松一口气，胸有成竹的告诉了B说自己用例跑完一遍了，B结果一看bug一个都没解呢。等到开发修复完，时针指向了7点钟方向。回归测试完毕达到上线标准时已经10点钟了，又是一个苦逼的日子…
以上故事应该在很多新人头上都发生过，依照以上案例，我个人觉得主要有以下几个问题导致的。
问题一：事情优先级和紧急度处理不当
这是初入职场的人一定会犯的错误，在大家的意识中，事情是一件一件做的。只要有超过3，4件事情的时候可能就手忙脚乱，而且感觉压力巨大，自己手头的事儿还没完，怎么又有这么多活儿，啥时候才是个头啊…我相信很多人都这么抱怨过，口头上或心理这么觉得。的确在工作中会有很多事情，这也是我们存在的价值所在，如果理清事情的优先级和紧急程度，就迎刃而解，按照四象限来划分，优先做第一象限的事情，从第一象限到第四象限，依次类推。
1）、“重要且紧急”：立即去做
2）、“重要不紧急”：有计划的去做，不要等到变成重要且紧急的时候才去做
3）、“不重要但紧急”：优先考虑了重要的事情之后再来考虑紧急的事情，此类事情拖一拖也无关大局
4）、“不重要也不紧急”：尽量别去做，更不要花时间沉溺于此
那体现在这个案例中，第一个错误之处就是未排好事情的优先级，事情都是one by one的去做。第二个就是用例优先级，同样可以把每一条用例当成一件任务，他们的优先级设立同样重要，按照优先级来执行用例，尽早发现bug，及早发现严重的bug，也就可以避免顽固的bug拖累项目进度。
问题二：工作方法不当
我们很多时候在忙碌中已经忘记了去思考，去总结，一件事情丢过来的时候，噼里啪啦可能就按照以往的思路去做了，也许以前就是未总结过的，所以一错再错，比如在测试过程中的测试方法总结，测试流程的梳理。任何人都知道需求评审重要性，需求变更带来的坏处，不管是科班出生还是转行做测试的，但是对于需求评审可能都未到位，到测试快结束的时候发现一个需求漏洞，多方确认再次改代码甚至架构，带来的项目压力可想而知。
同样，在这个案例中，A同学对于bug的跟踪处理不当，导致开发人员可能在忙活别的项目无暇顾及bug，导致修复进度缓慢。如果可以在发现严重bug的同时及时告知开发人员，叫他们优先处理高优先级的bug同时及时修复其他的bug，也许可以节省很多时间。
问题三：工作目标不明确
工作目标说简单点就是哪件事情在什么时候要完成到什么程度，新人可能并不特别明白，但是你的同事或上司可能未必每次都说的这么清楚，那在接受一件任务的时候，就有必要搞清楚，可以直接问下给你任务的人，至少要搞明白以下几点：
具体是什么任务；
任务是否在你可完成的范围之内，如果需要其他人的协助也可以尽早提出；
具体什么时候开始做；
什么时候做完，或什么时候做到什么程度。
结合这个案例，至少PM的需求宣讲以及线上bug确认2件事可以搞明白其工作目标后再做优先级的排序，可能就无需立即去做。
问题四：不懂拒绝
这是很多人都容易犯的毛病，别人找你帮忙你不懂拒绝，就会导致顾此失彼。A同学在配合PM和开发人员的工作时就是因为不懂拒绝导致时间花费了很多。其实他完全可以在确立目标之后拒绝PM的低优先级要求，可以拒绝开发人员占用自己电脑，完全可以让他回自己电脑上调试，并行工作互不影响。