项目上线前病倒了（第一个失控的项目）
项目上线前病倒了（第一个失控的项目）背景：------------迭代一---------------2. 合作商meng之前未参与过展会系统的标品开发，这块是项目的主要风险点。标品原先主要有合作商jing参与，而本次项目未有合作商jing的资源投入。项目原计划：分成2个版本，每个版本的测试时间只给了1周时间。我这边职责：跟进项目测试进度、识别风险与性能测试。
-----------------项目概况------------
项目内容：项目所在地在杭州，项目为一大型展会系统，实现在线上宣传、展示展会内容，录播回放展会视频，售票和线下的验票，为展会提供全方位的技术支撑。展会系统是基于标品的定制化开发。
主要合作商：
1. 主要有两个，合作商guan，公司在郑州，负责小程序开发，对应2~3位测试；合作商meng，公司在杭州，负责服务端，后管，PC端产品开发，最初计划只有2位测试。系统涉及到对接的第三方的有发票模块，售票和线下的票检。
2. 合作商meng之前未参与过展会系统的标品开发，这块是项目的主要风险点。标品原先主要有合作商jing参与，而本次项目未有合作商jing的资源投入。
项目原计划：分成2个版本，每个版本的测试时间只给了1周时间。
我这边职责：跟进项目测试进度、识别风险与性能测试。
------------迭代一---------------
背景：
也许是出于项目成本的考虑，据说刚开始没考虑投入我这样的QA人力。经XX云的导师申请，才申请到不多的工时。所以后面3月初已经买了机票计划去其他项目，结果因bug多退了票又回该项目救火。
展会系统原先一直是公司jing在开发，据说公司jing的报价比较高，所以客户这次打算换其他报价较低的公司看下效果。从测试人数也大体能感受到报价低带来的影响，20位开发只配了2位测试。
第一次周会
大概2021年1月底开始投入项目，每个星期一开项目周会，刚进项目的第一天被我赶上了。项目关键时间点已经确定，周会上只是宣讲同步下。分2个版本提测，每个版本只有5左右天的测试时间。不知道这时间怎么定出来的，初步了解了两方ISV的测试人力，表达了对测试方面的风险。因其他展会系统7/8位测试很平常的事，共公司meng只安排了2位测试。且他们是新的合作方，之前未参与过展会项目，不熟悉展会系统。
回头想应该是合作商meng太自信了。周会上我提出测试人力不够，项目经理让我后面以邮件的形式提出对测试资源的要求。
第二次周会
在会前跟公司meng的pm提出过几次关于增加测试人力的问题，得到的答复是不可能再增加人力了。在会上我再次提了测试人力的风险，XX云的pm说让我先跟ISV的pm对齐，意思是meng公司觉得目前人力无风险。思考的角度不同，是很难对齐了，后续只能以邮件的形式阐述我认为的风险和解决思路。主要是增加meng的测试人力和公司jing协作投入测试人力支持。
公司meng：
合作商meng是拉了开发测试到客户现场办公。大概20位开发，2位测试。因之前参与过类似的展会项目，深知2位测试同学要在这么短时间完成测试不可能，在周会后发邮件说明的风险与申请增加测试人力: 1. 根据合理的开发测试比，合作商meng的测试投入需5~6位；2. 因展会系统原业务逻辑较复杂，需投入2位原项目的集成测试人员。
公司meng的项目经理是一位年轻的妹子，应该没工作几年，态度倒是挺强硬。私下跟他强调多次风险，回复是不大可能再投入测试资源。在后续的会上说当着大家的面说他们会保证质量，客户侧项目经理也就同意目前的人力投入了。我心想，那好吧，到时看看迭代一的情况再来反驳你所谓的保证。
集成测试人力也没争取到，因集成测试人员是属于合作商jing的，这次项目被公司B替代，没有收入自然不同意，客户侧也不愿出资金投入新的测试预算。
原计划2021年2月5号~8号是第一版本测试，8号当天就得发布，真正测试时间也就差不多只有3天。因时间紧急，提测前跟合作商meng的测试叮嘱过，4号下午开发完提测后，测试这边需要冒烟测试，确保没有阻塞问题，这样后面几天才能顺利有效地测试。结果4号晚上测试人员都参与公司团建去了… 一切的不顺这才刚开始，我替他们做了下冒烟测试，提了十几个bug。
如下是迭代一期间bug的新增情况：
前2行是公司B的测试人员每天提交的bug，第3行是我提交的bug。我作为一位局外人（相对于作为承包方公司meng，它负责开发测试与交付产品），他们整个测试团队发现的bug还没我多。实际到8号只完成了第一轮测试，还有开始bug验证和测试回归待执行。比较气人的是他们竟然一点紧迫感都没，给人的感觉是他们把用例执行完，用例对应的bug修复完验证完就算完成了，不验证回归相关联的功能模块（即非定开内容，但与定开内容业务、功能上有关联），完全不顾实际的质量情况。用例执行只是个最基本的内容，特别是他们对展会系统完全陌生，只是根据需求文档写的用例考虑得很有限，却在测试过程中不会主动去完善用例，与探索性测试。
在2月8号~25号之间，即在迭代二提测前的这些时间间隙，一直在催促公司meng的测试要针对版本1回归测试，因根据我的测试走查还有不少bug。真是皇帝不急太监急，他们一直没进行回归测试，期间问怎么测试没新增1个bug，原来安排测试去了其他项目用了几天。我也真是无语了，我几乎每天邮件日报都在报风险，而公司B测试团队一直低投入与低产出。
公司guan
公司guan负责小程序的开发，对接的接口有公司meng提供。公司guan一直在抱怨meng公司不怎么配合，有些开发联调需要meng公司配合经常得不到响应。公司guan的开发提测进度也落后于计划，但相对来说这块的风险我倒不是很担心，他们测试安排了3位测试，相对工作量来说这样的投入质量风险还好，且他们团队之前就参加过展会系统的小程序开发与测试。
-----------------迭代二------
2月25号迭代二开始提测，就这样迭代一质量未稳定情况下开始了迭代二的测试。因鉴于之前公司meng测试糟糕表现，终于申请到了一位集成测试同学（来自合作商jing，虽然申请2位实际只到了1位）。
原计划迭代二在3月1号结束，实际到3月11号才发布 。
期间公司meng的测试团队基本只有2人，再三催促下才同意再加1人。实际的效果并不好，一是现场办公的测试只有1位，另外两位的实际投入情况值得怀疑，因从提交的bug数上很少。二是答应26号左右投入测试，实际到位延后了几天。回顾了下之前的日报31号时公司meng竟然没投入测试工作，而集成测试同学仍每天发现一堆bug。
从迭代一开始我就处于焦虑状态，项目质量失控风险较大。因我自己功能走查时每次都有一堆问题，但公司B的测试发现的bug少，还没有紧迫感。在3月1号的前2~3天在钉钉群里跟公司meng的项目经理互怼了起来，我这边的观点是从迭代一开始他们就说会保证质量。可到迭代二质量还这么差，还不增加测试人力，结果快到发版时间了每天新增bug一直未收敛。她观点大概意思是他们已经做了该做的，测试进度符合预期。她说的测试进度我理解只是用例执行，如用例执行完成100%就是完成任务了，完全不看实际的质量。他的用例只覆盖关于定开的功能，但实际结果是定开引起了很多其他模块的功能bug。怼完了心情稍微好些，我的性格不大愿意怼人，能友好合作何尝不是更好的选择。可友善的提醒和敦促换来的是石沉大海杳无音信，累的是自己。自我安慰的想法是：这只是一份工作而已，该怼的怼，事后的生活是自己的，不要把心情带到生活中。（在几个月以后的其他项目，一位XX云的开发TM也累的感慨了句“这只是一份工作而已”）。
迭代二过程中UI同学也都加入了测试，他们不是公司meng的人员，可以理解成客户侧提供的资源。本来是计划负责UI样式的走查，结果bug实在太多实际当功能测试投入了。UI同学时不时跟我抱怨这公司meng怎么测试的…，基本这项目的各方都对公司meng有较大意见。
根据当时的情况，我罗列了些他们的“罪状”：
1. 投入测试人力少，他们提的bug数占总数比例很小
2. 迭代1没听我劝，未进行完整的回归，很多迭代1的bug到后期才发现。
3. Bug修复时间长
4. 接口提供缓慢：在里程碑接口输出时，接口只有三分之一
5. 接口质量差：没有按前端UED出接口，导致逻辑不清晰，且接口经常报错、不稳定
6. 各合作方对公司meng总体印象：责任心和担当不强，不大从整体交付角度考虑。
功能回归
除了定开内容，主要需待回归的内容有票务系统和展会系统的非定开部分。当这部分叮嘱公司meng的pm需回归测试时，说让客户侧开发经理跟她说。看来之前一直催他加测试人力，到这个时候不大愿意理我了。当然结果都是一样，这些回归当然是他们交付内容的一部分。
展会系统原功能公司meng的测试同学不熟悉，经讨论由我这边协调去向合作商jing要回归用例。要到回归用例后，执行起来效果不好，一是用例有些不够详细，或有些未及时更新，在目前的版本已不适用；二是看文档的效率不高。所以我去协调合作商jing的集成测试同学，看是否有时间帮我们讲解下系统。合作商jing的QA和集成测试同学都是熟人，集成测试同学爽快的答应了，没想到卡在了QA这边，她应该是不好意思拒绝，说让我去找开发经理。开发经理也都是在同一个办公室，跟他说了后也爽快得同意了。QA听到后又起来说集成测试同学这边没空，还有XXX的什么活要做。我问集成测试同学是否能抽取3个小时，他回答可以后，QA又可以各种理由危险他，说是XXX如果出问题你能负担的起吗，还不去测试……。
自从项目开始以来几乎天天加班，上线时间一直延后，bug不断，ISV（公司meng）不配合已让我身心疲惫。现在搞的自己人还这么坑人，我实在压抑不住了，嘲她吼了几声离开了。
过了会钉钉上发消息说，让我们项目经理发申请给他们项目经理走流程。我把这情况截图转到我们项目群里，让项目经理协助。XX云的项目经理也火大了，都是同个公司的，自己人还搞的这么卷，让XX云的QA去搞定。最后的结果是集成测试同学在晚上下班后花3个小时帮我们讲解展会系统，不用再走所谓的什么申请流程。
票务系统也是引起迭代二延期的一个重要原因。一是没有需求文档；二是公司meng在项目开始时就没考虑这块回归的工作量。票务系统是由客户侧提供的标品，我们展会系统跟它做对接实现购票功能。
票务系统是客户侧提供的标品，没有需求文档也没操作说明等相关文档资料。客户比较强势，要资料未能达成。从开发、测试问了一圈就没人对票务系统原功能了解的。后面客户侧安排了位UI同学跟我们对接，不清楚的功能请教她，同时她也在协助功能走查与测试。实际她也不是很熟悉该系统，只是她之前的项目有参与过稍知道些基本功能。这个项目UI同学对需求、功能测试付出了不少工作，真是有点难为他们了。
性能测试(3月7号~12号)
性能测试本来也应该是公司meng的工作内容，在整个迭代2期间功能bug不少，要他们配合性能测试比较难推进。期间XX云的开发TM去协调几次，期望公司meng投入人力参与性能测试，都是空手而回，根据他的语气，对公司meng也是比较大的意见，太难协调与合作了。
最后只能我这边参与性能测试，从3月7号开始介入，XX云的开发TM和另一位jing公司的TM配合定位性能问题。大概搞了4个晚上，每次在凌晨3/4点左右结束。白天我们3位都有原先的活，晚上又得加班做性能测试。以至于这几天都没回家了，在公司附近找了酒店入住。
性能测试的结果不是很理想，有些接口的性能很低，印象中上线前1/2天还在性能测试，时间上和人力上已来不及优化性能，最后讨论在生产环境上做限流。
----------上线&售票（3月16号）---------
印象中是12号系统上线先预热，16号开始抢票。整个项目过程中的磕磕绊绊，让我对线上的质量始终不大有信心。在16号之前已经买了16号飞广州的机票，已安排好了其他的项目工作。结果16号开始抢票后，还真出问题了，售票数量超过了可售票数。上司联系我让退了机票，回项目去继续支持。
在紧急打车回项目的路上，接到了XX云QA大佬的电话。说是pm已跟他说不会怪我们QA，不是我们的锅，让我们重要的是把后面的事做好。除了我又协调了位XX云原厂QA来支持。原先是想协调另一位QA，即之前不同意集成测试同学帮他们培训的那位。XX云QA说了一堆需要她支持的理由，她同样也说了一堆不能去的理由，如原项目XXX原因等不能离开什么的。
他们的对话我一直听着，我是第一次知道原来拒绝工作可以这么操作的。因我的个性我会比较考虑整体厉害关系，不大会只考虑自己小的得失。如这次她失去的只是说这项目忙因而累些，就差不多赤裸裸的拒绝不去这个项目。
等我到了项目办公点已是下午5点左右。一些客户围着2/3位开发，表情凝重，更忙更累的还在后面…(待续)
