一段曲折的工作经历

最新推荐文章于 2024-08-10 00:01:54 发布

sophy_sun

最新推荐文章于 2024-08-10 00:01:54 发布

阅读量364

点赞数

文章标签：节日

本文链接：https://blog.csdn.net/fang_fang_2008/article/details/123824484

版权

写在前面，首先说明写这篇文章，目的不是吐槽我的前东家，也没有针对任何人，而是想让自己能在这段经历中悟出一点东西，让成长来的更猛烈些吧。

我是一名测试人。

入职新公司

2021-2022这一年，看似平淡，实则不然。

三月份我换了一份新的工作，满心的期待与欢喜，希望能在新的岗位上能成长更多。

进入新的领域，新的平台，期待自己不管是工作能力的提升还是经验的积累，我都很期待。但是，现实总是不仅如心意……

工作日常

当刚入职的那段时间里，工作任务很多，开发加班加点，我一边学习新的业务知识，一边与同事交接工作并尽快上手。就这样，一晃三个月过去了，对新公司的业务和测试工作有了更深的了解。这时候团队项目很多，很充实，成长的也很快。

有一天，负责另一块业务的一个同事提了离职，而公司也不打算加人，而我理所当然的接手了这块业务的测试。说实话，能接触到新的业务，我是高兴的，虽然又是新的业务，但是对于一个多年的测试人来讲，重新开始新的业务，难在开端，要熟悉新的业务过程，业务熟悉了，其他的工作中的测试的理论与方法都是通用的。就这样又接触到了一块新的业务，我变得更忙了…

特别的流程

公司有个流程，是每当发现线上问题后，就会有一个后评估的会议，参会人有开发，测试，产品，项目经理，有时还会有部门老大。这个会议很有意义，可以深入讨论问题根因，提出有效的解决方法，并能从技术和业务的角度提出优化建议，避免类似问题的产生。但是，有时候，美好的事物，会由于过度追求而变质。测试是质量保证的最后防线，出了问题，开发会问测试：“怎么没有测试到这个场景”？项目经理问开发：“当时是怎么想的”？“难道不知道有这个业务场景吗”？老大们会说：“代码拿出来评审下”？“测试用例拿出来评估下”？这使得我测试每一个项目，都万分谨慎，恐怕出事情；开发们也很谨慎。

另一个事情是关于工时。每个项目产品宣讲后，都会要测试开发工时，这个工时是详细的每一项工作的。例如，开发熟悉代码，写代码，自测，联测等，测试熟悉业务，设计用例，用例执行，缺陷验证等每项的工时都要写清楚（有的会精确到0.1pd）。这些其实没什么，但让人难以接收的是，当一个项目上花费的时间多于评估的时间时，会有一个工时超时评审，回顾一下多于的时间都干了什么？为啥当时评估的不准确？有时还会算一个超时率出来。我想，难道不明白项目工时是当项目处于理想状态时的工作量吗？谁能保证一个项目都是在理想状态下推进呢？难道看不到开发测试为了完成项目加班加点，他们付出的时间早已远远大于当初给出的工时了，（当然，为了避免不必要的工期超时评估，我已不敢记录多出来的工作时间）。

每天工时最好记录八小时，超了也会有人找人谈话。

在这种工作氛围下，我过的小心翼翼。