作为IC, 可以对不喜欢的task说不么？

楼主现在在一家中型公司做infra, 2年经验。公司结构扁平，engineer级别不多，所以一直也没有考虑升职的事。组里一个大项目，已经做了差不多一年了，但是离上线还很远，楼主从项目prototype就开始做，算是知道项目的所有细节吧。项目现在一共4个人，除了楼主，其余3人均为senior,2个senior和楼主一样从项目开始一直做，另一个senior半路来的，对项目了解不多。
以上为背景。现在问题是，项目负责人说，第一季度的主要任务是上线前的测试，然后让楼主去写e2e测试。因为整个项目涉及到好几个组，其他组的dependency没有clear,所以要写很多mock service,产生数据，然后才能测试。虽然说的是第一季度都做测试，可是其他3人现在其实都在做开发，只有楼主一人写测试。整个组的测试环境是现成的，但是针对我们项目的要求要很多enhancement,搭起来非常费时，也不稳定。我的感觉是现在这个阶段不适合做端到端测试，因为很多feature还没有搭好。要测试也是要先做针对各个module的单元测试，而不是直接就e2e.另一个就是我测试出来的问题，即使是他们的code,也需要我给他们debug出来。这样就相当于楼主给他们cover up，真心累。项目负责人特别喜欢抢功劳，对上面报告时从来不提底下人，但是我们用scrum,所以楼主想的是如果楼主做开发，还是可以有一些visiblity的，做test就基本没有了。我猜项目负责人想的是，后来的senior知道的不如他多，另一个senior是元老级人物他惹不起，只有楼主和他对项目的了解差不多，又是junior,好欺负，所以他不给楼主安排重要的任务。楼主的manager手下好几个项目，所以不能时时跟进。

所以想请教一下在现在这种情况下，楼主可以对这个test说不么？或者至少这种test大家轮流写，谁的feature谁负责test.楼主也在反思是不是自己太挑剔，所以想听听前辈们和小伙伴们的意见。楼主是愿意加班愿意多干活的，只要能学到东西或者对将来有帮助。但是现在感觉很迷茫，也从内心里不喜欢这种被逼着做一些任务的感觉。另外补充的是，现在另3个人做的任务，楼主平时都有考虑过，也有implemention plan,只是没有被安排，所以没有拿出来讨论。
如果有小伙伴认出楼主了，还请不要说出来，毕竟，楼主还得在现在的公司混几个月。
谢谢大家！

本文被提升为今日话题：凡是在置顶有效期内参与讨论，提供言之有物、切中主题的高质量回复，最低奖励20大米，干货越多奖励越多。

也请大家踊跃参与，看到好回答，请加分、请顶上去。对认真码字、热心分享的同学表示感谢，今后大家也会看到更多精彩分享。

说明：给别人加分不会扣除你的积分。


提示：今日另外一个话题：https://www.1point3acres.com/bbs/thread-475242-1-1.html

拒绝，同时话要说的漂亮，诸如“新的framework每个人都应该尝试一下，这对team和个人都是有好处的，楼主不想把那么好的机会一个人独占。”

Most of the replied/comments are too simple, sometimes naive :).  You all heard this: wherever there are people, there are rives and lakes.  Every company/team has politics.  Simply tranfering to another team/company won't help you avoid politics.
How to take the negative things positively?  You should treat them as challenges.  For this specific case: when to start e2e (end-to-end) tests?  If you are not able to handle it, you won't be able to survive in any company.  I am sure every engineer wants to become a tech lead/architect even if you don't want to be a people manager. Handling conflicts, selling your ideas, and convincing others are all important for tech lead/architect role.  Conflict doesn't mean personal conflct.  It refers that you and others have different ideas or different point of views.

Let's discuss the original question now: Should you say no to e2e tests?  In short, never say no before you fully understand the context.  

You know it is very costly to fix bug on production environments.  That's why we want QA early involvements: start testing as early as possible and catch bugs before production deployment.   If you just say I don't want to test, you put yourself on a very unfavorable position.  You need to communicate why you don't want to do e2e NOW (not you don't want to do e2e).  In a scrum team, the ultimate goal is every team member is interchangeable, which means it doesn't really differentiate developers from QA.  The team's goal is to get the job done so if QAs need help, and develoeprs are available, developers should help test.  Basically, you should put the team's benefit before youself.  Someone said testing doesn't help your resume since you are a developer.  I will discuss it later.

From what you said, you don't think it is the right time to start e2e since other components are not ready.  It will take much more efforts to generate mock data.  Did you communicate your concerns with the tech lead?  Do you know why the tech lead wanted to start e2e now?  Your tech lead definitely is more experienced than you.  Another thought is he definitely want this project to succeed since he is leading it.  He might have some valid reasons you may not know.  Communication surely plays its role here.  

Schedule a 1-on-1 with your tech lead ASAP.  In the meeting, ask questions, and try to understand his reason.  You also need to prepare your points.  You may take some notes and bring them to the meeting to help you convince him. For example, it will take extra X numbers of weeks to prepare mock data for e2e now vs. if other components are ready.  You can propose to start component test now if you team hasn't done it.  It will greatly reduce the workload.  You also need to emphasize the importance of testing, and agree e2e is necssary.  It is just timing and priority.  If you team already finish MVP (minimum viable product), I agree with your team lead to start e2e now.  Otherwise, you can suggest focusing feature development to finish MVP first.  You can say something like: even we have a bug free component, but we don't have all the required features, the proejct still fails to deliver.  The key point is to let him know you support him and you all want this project to succeed.  

Next post I will discuss what if you as a developer need to do some QA work. Click here to read Part 2

zli_test 发表于 2019-1-31 12:36
Most of the replied/comments are too simple, sometimes naive :).  You all heard this: wherever there ...

Thank you very much for your long reply. I really appreciate it. I tried to communicate with my TL and he did not give me the reason for doing e2e test now. He just told me he planned to do it but all other programmers in the team are still doing development. I totally agree that developers should do the tests by themselves and that is the reason why I was doing this when I was first assigned to the task. Things went off track after that. My TL seemed to bind me to the test work while I was thinking to rotate back to development for some time. He created a bunch of tasks and assigned to me. So I will be working for testing in the next few weeks or months depends on how it goes. From his point of view, I may be more familiar with the test set up but I am also familiar with the development (I did my own research and made the implementation plan for quite a lot of features which I did the POC by myself. So I think I am the right person to turn those POC to production code). In contrast, my TL de-prioritized those features (those are very basic features like fail over or error handling). That is the reason why I think it is not a good time to do the e2e test now. For the mock data, we have a work around so it is ok for now. The time we really need it is when we deploy the code in beta at least and we would like to put the A/B test as automated regression. I think at that time, we will have more support to generate those data for sure. The last thing I was worried about is the timing. As I said, I estimated the task (generating mock data) will take at least a month while my TL thinks it is only two weeks. We discussed it in today's meeting and other team member also agreed with me. But that was towards the end of the meeting so my TL did not give the conclusion. I planned to talk to him tomorrow and I would like to know if the reason above is solid.
Thanks again for your input. I really like the way you analyzed. It really helps me to prepare my talk with my TL.

lz你好，我在现在的公司也是负责开发、测试、部署，我只说说我自己对于测试这方面的想法。我的工作流程是：先做好单元测试， 并用travis ci自动编译部署， 这样以后每次新的commit一来如果不通过test的话那就会fail， 等到单元测试做好了， 再做集成测试。我是这么做的：如果是repo A需要和repo B communicate， 那么在自动部署repo A的时候， 把repo B的内容拉下来并运行。 因为travis ci实际上每次是启动一个新的虚拟环境，类似于python中的virtual environment， 在repo A的travis ci文件中先pip install repo B的url， 然后run repo B service。 B的service起来之后，你就可以对A进行测试了。
进行到项目后期如果有很多个repo需要一起测试， 那么这时候最好的工具的就是docker 以及docker compose了， docker用起来非常方便，你不用担心每次配置各种环境， dockerfile写好之后基本就是一劳永逸。 启动所有的服务后， 你就可以用postman发送请求并看看是否返回预期的结果了。 关键是有错误一定要早发现，不然服务一多发现起来非常麻烦。
我现在的项目大概有12个repo， 每新加一个就执行相同的workflow， 目前来说执行的还算顺利， 希望对你有帮助。

楼主，我肯定没有你有经验，但是我觉得人在职场的前期，做多一点可以写在resume上面的东西是对自己有大大的好处的，因为你的resume会更加丰富，你也做了更多你本来可能不会去做的事情。等你跳槽找工作的时候，说不定哪一个task就抓住了对方hm的眼球。

你跟我处境差不多，我是碰到了个好老板，老板直接在1：1问我是不是对现在的task不满意，我直接说不喜欢，老板就说不喜欢直接在planning上说出来就行，他觉得有道理的话会帮我争取

回到你的问题上，我觉得你可以直接问你老板，tech lead 也是要听老板的，不要太怕得罪tech lead

楼主什么是IC？

woshilindan 发表于 2019-1-30 12:52
. check 1point3acres for more.楼主什么是IC？

就是individual contributor。技术岗写代码的，不管人

大馒头 发表于 2019-1-30 11:49
楼主，我肯定没有你有经验，但是我觉得人在职场的前期，做多一点可以写在resume上面的东西是对自己有大大的 ...

test可能都写不到resume上
而且还背锅 test到问题了是你的责任 test不出来是你有问题 test出来没找到或者找的慢是你能力太低 learning curve太长

你不写全 tech lead还可以到你的老板面前说你什么都没干 没有任何output 做个test都做不出来 看repo里你开发的commit几乎没有 废物一个 blabla

I was there....patpat但我也不知道怎么解决。。 求抱团

我在工作上也有类似的情况。如果只让你做测试的话，基本上就是甩锅。 因为一旦有bug,首先就是测试没做好。team lead 分任务的时候优先考虑跟他熟的人。分到你就是别人不想做或者做不来的。测试这活耗时间又没大功劳。如果遇到不喜欢的task：1 能拖就拖。2 提意见-开会的时候强推你的意见，说每个开发人员都应该自己写测试。意思就是你要想一个办法把这个不喜欢的task分摊出去。3 找manager。你直接说不，就等于你不敬业。4 长期都受到这种待遇的话，就准备plan B. 你懂的。官大一级压死人。有些工作文化很难改变。 随机应变吧。哈哈。

大馒头 发表于 2019-1-30 11:49
楼主，我肯定没有你有经验，但是我觉得人在职场的前期，做多一点可以写在resume上面的东西是对自己有大大的 ...

谢谢回复，写test前期是能学到一些东西，到我现在的程度，基本上就是苦力了，没有什么提高的空间

今天刷题了吗 发表于 2019-1-30 12:08
你跟我处境差不多，我是碰到了个好老板，老板直接在1：1问我是不是对现在的task不满意，我直接说不喜欢，老 ...

谢谢经验啊 ，我也试着在1：1时和老板说一说。我老板肯定不如你老板给力，不过对我还是挺好的。他只是太忙了，所以不经常参加我们的planning.
我忽然想到昨天的meeting,安排一个debug的任务时，组里其他的senior就对老板说因为他上个月干过了，所以这次不想干了，貌似老板也没说啥。不过那个人在老板心里肯定比我重要倒是。。

2011051305 发表于 2019-1-30 13:14
test可能都写不到resume上
而且还背锅 test到问题了是你的责任 test不出来是你有问题 test出来没找到或 ...

对的，这完全和我的感觉一样。尤其是test出bug时，竟然还得我给找到问题，说是不知道是我test的问题还是code的问题。呵呵，test能有啥问题。最后我气不过，直接把证据甩出来才承认。所以说是给全组cover up的
tech lead的口头禅就是this has to work, you have to figure out blabla