如果是一个简单的软件系统,没有太多用户使用,也没有较为复杂的业务逻辑,那架构设计几乎是不需要的。为什么呢?
一般来说用户少意味着操作场景较少,没有高并发场景,也没有复杂的业务逻辑,只要功能正确实现可以正常使用即可。但在我们实际的工作场景中,我们面对的工作对象,常常具备这两个特点:
需求的复杂和不确定性大家都很熟悉,特别是做互联网To C业务的企业,需求的复杂和不确定性就更高。而技术的复杂性,主要来源于下面几点因素:
因为技术的复杂性,会导致软件研发的过程变得很复杂,而软件工程本身就是为了摆脱软件质量危机,以软件开发为核心,对开发过程组织+对方法的运用+对工具的使用,
来让软件系统达到稳定,而架构设计正好可以解决这些复杂性带来的问题。架构设计的有点如下:
看完了上面关于架构设计的优势,其实可以快速推导出测试架构要做的事情。
研发角度的架构设计要做的是:用最小人力成本满足需求开发和响应变更,用最合适的技术架构来保障软件的平稳运行。
简单来说就是:组织人力高效协作+合理设计技术框架+保障线上服务稳定运行。
从测试的角度出发,测试的本质是质量保障和推动研发效能提升。那么测试架构要做的事情是:
大多数企业的组织架构是横向的,而测试团队在其中的定位既可能是横向的大团队,也可以是纵向跟着项目走的小团队。而测试架构师的角色,在我看来其实需要具备两点特质:
结合测试架构要做的事情以及在团队中的角色定位,我认为测试架构应该具备如下几点基础能力:
与其说测试架构师是一个岗位和title,不如说他是具备某些复合能力的可以解决问题的人。
当然并不是说所有测试同学都需要变成测试架构师,这种测试架构能力在日常工作和学习中是可以培养的。
对于普通的测试工程师,想要培养测试架构能力,我建议可以先从如下几点入手:
你看,上面四点是不是和产品设计中提倡的mvp方案有类似的思路。
我在前面的文章中也提到过一个质量保障体系的总结,即:风险可识别+问题可追踪+结果可验证+数据可量化。
按照上面的几点坚持去做,迟早我们都会具备架构能力。