2016 Unicode Conference拾遗（一）

在刚结束的2016Unicode Conference上，来自Google的Kat Momoi先生分享了他的topic——Releasecriteria and mobile i18n testing toolbox。其中不少战术打法与作者思路惊人暗合，看来是同道中人哦！遇到了一样信奉“控球”的战术控，感触着实良多，特发文略作点评一二。

 

作为StaffTest Engineer and I18n Consultant，Kat先生最近几年一直致力于研究如何更高效的在手机端进行国际化测试。（注意！是I18n，不是L10n），尤其是在实施敏捷模型的开发过程中，如何更快捷的多语言（70+）支持的产品进行国际化测试。

 

开篇Kat先生就列举了目前他面临的挑战。（其实我们又何尝不是呢？）

·        如何清晰的将i18n和l10n剥离开来？

这就是我常说的“二化分离”，上帝的归上帝，凯撒的归凯撒！

·        如何尽早的发现所有i18n问题？

用我的话就是怎样进行“高位逼抢”？尽可能的不让战火燃烧到我方半场，在devdeliver第一个函数，甚至第一行代码时，“逼抢”其实已经可以开始了。

·        只关注localizability的问题，而不是localization本身

该问题本质上还是要处理好“二化分离”，翻译质量相关问题交给LQA，而不是国际化测试人员。归根结底，他们是技术人员，而不是翻译专家。但与代码相关的所有国际化问题，就责无旁贷了，都应该统一进行“高位逼抢”，在开发阶段即进行测试并指出问题根源所在。

 

他给出的解决方案如下。

·        提供i18n测试检查点列表 + 最优测试方案，同时让dev team review并提供他们的意见建议

我一直宣扬的“人盯人+贴身防守”就是这个意思，只有跟dev team不断的交流，融合甚至绑定，才能真的提出所谓“最优方案”。否则面对一个巨大的黑盒，鬼才信你能做出任何优化。

·        方案+列表一旦生成，就需要在测试过程中严格执行

·        利用或开发测试工具来提高效率，节省测试时间

这点非常重要，调侃时我常说“会使用工具，是人跟其他动物的本质区别！”。当然，如果在抽烟过程中，这句话就要换成“会使用火”……

 

Kat先生也在slides中提供了一些自己团队开发的开源国际化测试工具、框架以及使用场景，未来我会单独写一篇文章来专门介绍。

·        Dev team负责并保证基本i18n test coverage

这跟业内某些团队宣称的dev own i18n quality基本是一个意思，然而笔者不敢苟同。站在dev的角度，i18n确实是产品中的边边角角，这是毋庸置疑的。在主要功能都无法保证完成或者无法保证质量的情况下，还要求dev负责i18n的test coverage，这岂非强人所难？另外，站在国际化测试团队的角度看，本就不富余的一亩三分地还要划出一片，拱手将这大好河山送与他人，失去了本可建功立业，腾挪跌宕的空间，意欲何为呢？当然，笔者可能有些狭隘了！没关系，我已经把这些想法mail给了Kat先生，也很想听听他的想法，那时候再分享给大家。

 

“理想”的工作流

1.      开发团队负责i18n代码审查+校验，国际化团队不需要参与其中

关于这点笔者并不认同，原因如上所述。

2.      提供翻译服务（注意，这已不是engineer team的分内之事）

一般的软件公司都不具备，也没有必要准备这样抑制常规军，外包给专业的语言服务公司或利用自身的技术优势，采用machinetranslation即可。

3.      可能的话，完全自动化整个翻译的流水线

在这里我想补充的一点是，在action 1之后应添加如下内容。因为尽管我们都大力倡导“高位逼抢”，但这并不意味着传统的防守方式将被彻底放弃。

1.1  利用自动化脚本（最好是API级别，而非UI）进行回归测试

1.2  黑盒业务测试人员对new feature部分进行探索性测试

 

（未完待续……）