开发流程¶
仕様¶
- 式样Review时尽可能的提出自己的想法，发现式样有问题时要及时提出
- 做程序的过程中发现式样有问题时，也要及时提出QA
- 写测试式样书时发现式样有问题要及时提出QA
- 测试时发现 式样书 或 测试式样书 有问题要及时提出QA
QA¶
- QA尽量写的详细(尽量把疑问点的部分都截图说明)
- QA结果与式样不一样时，要告知写测试式样书人员及时改正
- 不管是式样Review时，还是开发中，还是写测试式样书，做测试时，有疑问就要提出，大家一起讨论是否要问QA
- QA谁发现谁写(日文写不出来时，可以中文)，不要总让别人代写。
- QA的写法，可以参考样板。
开发¶
- 开发中遇到的问题要及时提出，大家一起讨论是否要问QA
- 开发时尽可能为代码多写一些注释
- 对既有代码的修正，一定要考虑到条件分支的可能性。提醒测试式样书的作成者，以及测试时一定要覆盖测试
- 开发完成后要根据测试式样书认真测试，保证自己的产品质量，测试式样书中有问题的地方也要及时沟通
- 改变思想意识：测试也是开发的分内工作（30%左右）。
- 在代码提交给品保人员的时候，就和纳品的概念一致。
- 在开发工数足够的情况下，要求完成逻辑代码的Junit测试代码覆盖（边界值）
测试¶
- 开发人员完成一回目的测试后开始。
- 测试式样书尽量写的详细，多一些测试用例。
- 测试式样书给日本确认前，要全组一起再Review一次，开发人员可以提出疑问。
- 测试时 切记 不要与开发人员交流，发现和理解式样书、测试式样书上的结果不一样时要及时提出，确认是哪一方的问题（测试式样书？机能？）
- 开发人员也要自己测试，保证自己的产品质量
- 单个功能和整体功能都要进行。要避免只做其中的一部分。
- 如有必要，可以第三轮测试，测试途中要换人，尽可能发现一些隐藏的问题点
- 多轮的测试结果和问题点，报告书都作为最终纳品物提交。
沟通交流¶
以上所有流程中的问题提出，Review结果都要有书面记录：
- 可以是Excel整理好的。
- 尽可能的把问题说的详细，如哪些场景，可能出现的情况等。
- 方便起见，可以在git的issue里相关议题的下面记录并At相关人员
- 开发者(测试者)->Leader->Manager->[顾客确认]
共勉¶
コーディングしたらテストすること。
現代ではコーディングとテストは同義です。
「テストはテスターがやる」という考えは100%誤りです。James WhittakerというエンジニアがGoogle勤務の時代に書いた記事があります。
at Google it's the product teams that own quality, not testers. Every developer is expected to do their own testing.
The job of the tester is to make sure they have the automation infrastructure and enabling processes that support this self reliance. Testers enable developers to test.