一个不会测试的产品不是好开发
在初创公司,大部分都没有专门的QA(质量保证)人员,此时测试的活儿基本上就是产品做了。
实际上这活儿也挺适合产品做的,毕竟没有谁能比写PRD的那个人更了解产品细节了。
这半个月经历了两次较大的网站架构更新。时间紧,资源少,没时间系统的搞沙盘测试,依然像往常一样,全员大帮哄,做了一夜黑盒就完事儿了。
结果上线之后各种Bug,用户反馈压爆客服。还好技术团队比较牛掰,严重的缺陷当天基本都解决掉,才没造成过大的损失。
之前一直没系统的去思考过测试方面的事情,亲身经历才感觉到后果的严重性。
先聊聊项目管理:
从项目管理的角度,测试严格来说属于项目质量管理中的质量计划,质量保证,质量控制三个环节中的最后一环,是验收整个项目质量的关键环节。
所以传统的项目管理理论中大部分是不适用于初创阶段的,这时候就得结合自身情况,用合适的方法具体分析了。
最常见的三种是:
黑盒测试——不考虑程序的内部结构,直接在程序接口上进行测试。通俗的讲就是把产品拿过来直接用找Bug。
白盒测试——把测试的对象看成一个透明的盒子,对程序的所有逻辑路径进行测试。常用的有语句覆盖,条件覆盖,判断覆盖,条件组合覆盖,路径覆盖这几种。(这个都是开发的活儿,产品们了解下就好
沙盘测试——模拟用户在实际环境中的测试,也就是把一个个用户场景都走通一遍。这样就把粒度较大,也十分重要的逻辑漏洞过滤掉了。
而实际操作中,测试要如何规划呢?
下面分别再从8个维度重新归纳一下。
首先,测试人员的核心能力在于提出具有价值的问题。这需要结合技术和产品的角度来思考。
了解已有信息
测试开始之前,我们要先知道从哪开始测试:
目前已经有哪些可供参考的信息:产品规格?需求文档?用户文档?已有的Bug记录等等。(理想情况下,测试人员应该掌握产品应有的所有细节资料。然而事实上这些文档很有限,多问多积累吧…)
产品支持在什么系统、平台和设备上运行?
产品都处理哪些数据类型?(如聊天信息,消费信息等)
产品有接入外部产品吗?(如其它API或数据)
多少时间用来测试?
测试的优先级如何排列?
测试的风险如何判断?
发布和更新的流程如何?
基本上,了解好上面的信息就可以开始制定相应的测试计划了。在时间允许的情况下,一定要记得:(这次就是没写吃了大亏)
写测试用例!
写测试用例!
写测试用例!
从用户场景测试:
自己做的产品,我们一定有自己的理解,而用户实际上是如何使用的?在什么样的情景下使用?都是我们需要慢慢的通过与用户的交流,产品的数据积累,用户研究得来的,测试的时候当然也不能漏掉。
用户的使用经验:
毫无经验
有些经验
很有经验
技术狂
竞争对手
黑客
……
当然,角色要多少有多少,具体看我们产品有什么需要了。
用户的操作行为:
在不该返回的时候返回
不耐心多次点击按钮
输入错误数据
不理解如何使用
没按照产品规则进行设置
随便乱点
……
意料之外的Bug常常就会在这里出现,不过一般都是小Bug,但更深入的想想,其实会有更多产品本身的问题。