有网友给我发邮件询问：测试架构师的工作职责只适合大公司。如果是一个只有10个测试人员或更少的测试人员的小公司，可没资源来做这些测试活动了。那么应该开展哪些测试活动才是最适合小公司的。
其实我工作的第一家公司，虽然测试人员也有大几十号人，但是运作上其实还是一个小公司，资源缺乏，人力不足，产品时间紧。因此，对于小公司测试活动的认识，我也是走了弯路后，最近才反思合理的测试策略应该是什么。
先说说小公司的特点：公司失败的风险很大，产品失败的风险也大，并且用于研发的时间和人力都少。
那么小公司的特点说明什么？说明小公司的测试必须是快速开展，快速见效，有可能测试的不全面，但是只要保住了可以保命的质量，规避了保命的风险就可以满足老板的需求。这里就谈到，小公司的自动化测试什么时候搞合适？我的建议是：产品第一版的测试就不要投一点力量搞自动化了，谁知道下个月还做不做这个产品。只有产品销量成功，公司立志2－3年都要继续完善该产品时，才有必要投入自动化测试。毕竟自动化测试的成本是很贵的，你投一个人搞自动化测试，你就少了一个保障关键特性质量的测试人员。今天，我终于理解和原谅了04年让我中止搞自动化测试的那位测试经理。我当时一味心思认为只有自动化测试才是测试活动中最有技术含量的工作，并没有站在公司的角度，从大局思考投入产出。
那么小公司不搞自动化测试了，是否就意味着小公司的测试就可以进行monkey testing。错！小公司可以把时间放在基于风险测试的研究和掌握中，基于风险的测试就是解决资源和时间都不够情况下，我们如何把产品质量引起的失败风险降低到最低的一种最佳投入产出测试准则。
同时，小公司更需要测试人员参与到项目的需求讨论，架构讨论活动中，发挥小公司灵活言论自由的优势，把需求和架构的问题尽早消灭，根据统计50％的bug都是在需求和架构设计阶段就埋入了的，而这些bug要在系统测试阶段发现，不但难度大，而且非常耗时。
另外，小公司测试人员要尽可能使用测试工具进行代码自动测试，只要能自动进行代码相关测试的工具就尽可能拿来用，虽然会遗漏代码编写的缺陷，但也比在后期完全依靠系统测试来发现，省人省时多了。
最后，小公司测试可以在功能测试上少花一些人和时间，只做verification, 不做testing，当然前提是：已做好了基于风险的测试分析，并进行了充分的early testing。但是在性能测试和压力测试方面，还是要依赖工具尽可能去测试，暴露产品在少数极端情况下和长时间正常情况下的bug。
总结小公司测试策略的建议：
i. 不要过早投入开展自动化测试；
ii. 一定要掌握基于风险的测试方法；
iii. 尽可能使用自动测试工具进行代码级测试；
iv. 功能测试侧重verification, 少做testing
v. 重视性能和压力测试。（以上言论仅代表作者的个人观点，不代表51Testing观点）
版权声明：本文出自架构师Jack的51Testing软件测试博客：http://www.51testing.com/?293557
原创作品，转载时请务必以超链接形式标明本文原始出处、作者信息和本声明，否则将追究法律责任。
