产品测试过程之酸与甜

lsekfe

传统测试任务，小伙伴们想必都知道，我们只要清楚测试项目的目标、范围、需求等，去准备测试设计案例，定义完备的测试用例，根据业务场景去定义测试脚本。无脑地按部就班执行测试用例，运行测试脚本即可，最终记录缺陷并反馈问题。测试人员有较大说话权，只要挑出开发的bug，理直气壮地要求开发人员修改掉那些程序错误，能获得一定成就感。
然而，产品测试似乎没有项目测试那么容易。今天笔者想从产品测试角度分享一些经验，若您正在参与产品测试任务，需要避免哪些坑？希望能给您带来一些启发，在产品测试过程中得到更多成长。
辛酸的产品测试
为什么称产品测试过程很辛酸？
我们知道，搞产品比搞项目更加复杂。我们可以把产品定义为一个持续迭代实现的多维度的项目。从产品生命周期、需求变更频次，到开发测试颗粒度、运维质保等，都是极端要求严格、且精细密集的。产品测试需要在产品上线发布后，及时收集用户反馈，通过与客户支持人员、运营支持人员的频繁沟通，来掌握产品运行生态圈的各种万千变化。
产品测试人员是辛苦的。我们不能简单拿个需求模块就一股脑儿冲进去写用例、执行脚本等。因为产品测试需要了解整个产品在市场上的定位，包括目标人群、设计理念、运营策略等。如果割裂去测试产品模块或者执行测试场景，其实是片面的。
举个例子，产品测试UI设计时，如何能判断这个设计是合适的？其实，我们不能像测试项目一样，拿着原型图去简单比对布局layout，或者元素字体大小色彩。我们其实更应该去关注这套UI是否能让用户视觉上过目不忘、操作上流畅顺滑、使用上简单方便。这个需要不断与UI设计人员陪同最终用户，进行市场调研，通过多轮采样对比验证，最终得出用户意见。可见，没有一定重复又枯燥的样本数据，没有对市场持续跟踪反馈的调研改进，我们无法交付一款受欢迎的产品。
产品测试人员是心酸的。似乎我们都在担当产品经理助理的角色。但测试人员职责就是要验证是否符合各种预期，不是嘛？

由于篇幅因素，本文不展开讲困难的产品测试过程。

甘甜的产品测试
相比辛酸史，我们需要积极看到产品测试的优势，主要包括以下几个部分。
一， 通常具备产品测试能力的小伙伴，更容易代入用户视角，高效与最终用户沟通，获得信任；
二， 对产品实际效果的认知程度，能够给产品完整性、实效性进行评估，避免项目交付场景片面化；
三， 理解新老产品版本的升级改进，对比分析产品与竞品的差异，“知己知彼”，体现产品商业价值；
四， 产品测试人员职业发展，相对于项目测试的发展路线更加全面广泛。除了测试专家或项目管理外，还能拓宽到产品负责人，商务合伙人，或者转为售前咨询、产品运营、客户支持等。
还是拿上文例子——产品测试UI来介绍，我们知道测试结果都是较主观的体验反馈。那我们通过多轮样本版本发布，去收集市场上用户反馈，聆听真实好坏声音，也侧面增加用户粘合度，不就是提升产品影响，为后续更有价值推广运营做铺垫嘛？如果可以的话，准备多套UI风格，让用户按照自己喜好灵活替换，好比开放了自定义改装“皮肤”的效果，何乐而不为？
所以，我们可以从产品测试学到的，远比项目测试来得更多、更广、更深、更全。
个人认为，产品测试更加能产生成就感！你会为曾经在产品建设中作出绵薄贡献而自豪！
大家认为呢？

lsekfe

后续会添加新的内容

jingzizx

产品具备平台性能