Thoughts and Practice on Quality Standardization

定義

1 品質標準化

品質標準化とは何か？不適切な例えになるかもしれませんが、工場のライン作業を想像してください。各工程の担当者や機械が何をすべきかは事前に規定・定義されており、ライン上の製品は原材料から完成品まで同じプロセスを経ます。一連のプロセスが標準化されているため、完成品の品質に大きなばらつきは生じません。研究開発プロセスにもライン作業と共通する部分があります。各ビジネスラインの研究開発プロセスを標準化することで、優れたビジネスラインを標準モデルとして一連の標準化されたプロセスを確立し、他のビジネスラインにも適用することで、すべてのビジネスラインが高水準の研究開発を実施できるようにします。品質を届けます。

2 品質の作り込み

研究開発チームの中には、品質はテスト担当者が守ってくれるものと考え、製品の品質問題はテスト担当者の責任だと考える人が少なくありません。これはテスト業務と品質保証に対する狭い理解です。テスト担当者は品質の守護者ですが、品質を最終段階のテスト担当者だけで決定することはできません。ユーザーに高品質なプロダクトと体験を届けるには、研究開発プロセスのあらゆる側面で品質基準を遵守する必要があります。要件レビュー、設計、開発、セルフテストの各段階で、プロダクト・開発・テストの各担当者が品質意識を持ち、品質規範を厳格に実行すること。これが品質の作り込みです。

3 デリバリー品質

デリバリー品質は 2 つの部分から成り立ちます。システム品質とプロダクト体験です。システム品質とは、機能の完全性、安定性、およびシステムの堅牢性を指します。プロダクト体験とは、顧客がそのプロダクトを使用する際にシームレスな体験を得られるかどうかを指します。

2 つの合意事項

研究開発プロセスの各ロールが統一された一連の基準と規範を実践するためには、各ロールの思想的統一が不可欠です。チームの考え方が一致して初めて、基準と規範を推進・実行できます。ICBU の越境資金・国際決済チームの標準化建設を推進する過程で、私たちのチームはまず以下の観点について上下で高度な統一を図りました。

1 品質は測定だけでは測れない

Zhihu で「品質は設計されるものか、テストされるものか」という議論を見ました。とても良く書けていると思います。この命題を様々な角度から分析しました。「品質」の起源に関する議論を抽出したところ、非常に活発に行われていました。代表的な意見をいくつか抜粋します。

A さん：品質は設計されるものだと思っています。設計時に考慮されるあらゆる非機能品質データはコードに実装されます。設計の最適化はシステム品質の最適化を継続的に推進します。

B さん：品質はテストから生まれると思います。設計で既知の問題を回避できますが、実際のテストプロセスでは、互換性の問題など、考慮されていなかった他の問題が発見されます。事前に設計で防止できるでしょうか？したがって、テストが問題を見つけ、問題が品質改善を推進します。

C さん：B さんの話を聞いて、品質は設計によって作られると確信しました。常にバグに追われながら、パッチを当てたシステムの品質は良くなるでしょうか？パッチ当ては緊急対応であり、体系的な設計、リファクタリング、アップグレードが品質改善の要点です。では...

D さん：プロダクトレベルに立った場合、プロダクトをどう定義するでしょうか？プロダクトの良し悪しを定義する品質モデルには、ソフトウェア開発に関連する非機能品質属性（ISO9126）が含まれる可能性があり、プロダクトの評判や競合プロダクトの比較から明らかになる項目も含まれるかもしれません。例えば、コンテンツレコメンデーションプロダクトの品質を定義する際、「コンテンツの重複がない」「多様性」といった次元に加え、「共有をサポートするか」「いいねをサポートするか」も品質判断の基準になります。新機能がリリースされニーズが満たされると、ユーザーはプロダクトが良いと考えます。私たちの認識は継続的にアップグレードされ、「良い」の基準もより高い要求を持つようになります。ユーザーは使用し、テストし、フィードバックし続けることで、品質が継続的に改善されます。

2 いずれも正しく、かつ必要

上記 4 人の学生の視点は、異なる品質概念と追求を表しています。

行動前の視点：要件の曖昧さ分析であれ、設計時の UML 図のプロセス分析、タイミング分析、状態分析であれ、無駄を省きコストを削減することを目的としています。A さんは正しいです。

テスト探索の視点：設計をコードに変換する過程での 100% 完了の保証であれ、テストプロセスでより多くのロジックコードを書くインスピレーションであれ、見たものが得られることを目指しています。他の人が考えなかったことを考える。B さんは正しいです。

技術的負債の視点：最近のパッチコードのリファクタリングであれ、システムアーキテクチャのアップグレード、あるいはインフラ機能の最適化であれ、しっかりと基盤を築き、より遠くにより安定して進むことを目指しています。C さんは信頼できます。

継続的改善の視点：競合プロダクト分析、評判分析、オンライン活性検出、モニタリング、プロダクト品質モデルなどであれ、既存の認識と未認識の問題や不足を見つけることを目指しています。D さんは視野が広いです。

全員が正しく、優れた品質概念を表しているなら、トレードオフする必要はありません。必要であり、必須であり、不可欠で、必要なことです。

したがって、最終的な結論は次のようになります。

「品質は設計されるだけでなく、テストされ、あるいは強制されるもの」ですが、品質は測定だけでは測れず、品質保証はテストという 1 つのロールの責任だけでなく、研究開発プロセス全体を通じたすべてのロールの共通責任です。

3 欠陥は早く見つけるほどコストが低い

疑いなく、欠陥は早く見つけるほど修正コストは低くなります。不合理な要件は要件レビュー段階で発見され、技術方案の問題は技術設計段階で発見され、システムバグとプロダクトバグはテスト検証段階で発見されます。これらのリンクで発見された問題を修正するコストは徐々に増加しますが、顧客に接触された後に問題が発見された場合、修正コストは膨大になります。顧客体験と満足度に影響を与える可能性があり、資金損失を引き起こし、さらには会社の評判に損害を与える可能性もあります。

4 テスト戦略は本質的に品質コストと品質リスクのバランスを取る方法

プログラムの実行シナリオとそれに関わるデータ入力は尽くせないことを知っています。したがって、テストも尽くせません。そのため、テスト計画を設計する必要があります。ブラックボックステストケース設計の同値クラスと境界値法、ホワイトボックステストケース設計の条件カバレッジ法とパスカバレッジ法を使用することで、無限のテストデータから効果的なテストデータを選択できます。限られたテスト時間内で効果的なテストを行うためのテストデータです。

5 セルフテストの開発は基本要求であり基本的なリテラシー

私たちは常に開発のセルフテストを強調しています。テストの有無に関わらず、開発は自覚的にセルフテストを完了する必要があります。優れた開発者としては、提供するコードに対して十分な品質保証を持つ必要があります。これは、チームの上下で実装されるべき考え方と合意事項です。

3 つの実践

ICBU の越境資金・国際決済チームは、ICBU の品質標準化実践のモデルルームです。私たちのチームは研究開発プロセスのあらゆる側面で厳格な品質仕様を持っています。国際決済チームは多くの複雑な業務を担当しており、特に資金のデリバリーに関わるため、非常に慎重です。国際決済チームでは、提案からリリースまでの重要な要件について、テスト引き取りカテゴリは以下のステップを経る必要があります。

要件レビュー→リソース投入評価→技術方案设计レビュー→開発・結合テスト・セルフテスト→テスト方案レビュー→機能プレビュー→テスト→リリース計画レビュー→グレーリリース→全量

セルフテスト要件については、以下のリンクを経る必要があります。

要件レビュー→リソース投入評価→技術方案设计レビュー→開発・結合テスト→セルフテスト→グレーリリース→全量
以下では、これらのリンクの規範と、各リンクが適切に行われているかどうかを測定する指標について説明します。

1 要件段階

要件段階で頻繁に直面する問題は、プロジェクト開発過程で評価されていない要件ポイントが発見されることです。これらの未評価の要件ポイントを実現する場合、プロジェクトが遅延する可能性があり、間違いなくプロジェクトチームの負担とメンバーのプレッシャーを増加させます。これに対処するため、以下の対応メカニズムと規範を提案します。

1. プロジェクト開発過程で評価されていない要件ポイントが発見された場合、メインプロセスに影響を与えない場合は、変更で解決できます。

担当者：

変更の識別：モジュールオーナーまたはモジュール開発
変更の運用：PM および PD

2. 大規模プロジェクトが開発に入る前に、詳細な PRD を再レビューする必要があります。UED 変更がある場合は、PRD レビューを組織する前に設計稿を準備する必要があります。

担当者：PD（組織）、PM（監督・調整）

2 リソース投入の評価

要件レビュー終了後、開発とテストの担当者は投入される開発リソースとテストリソースを評価する必要があります。要件 PM が各当事者を調整してスケジュールを設定します。主に結合テスト時間、テスト時間、リリース時間を含みます。各ノードの時間が決定されると、PM と TPM はこのタイムポイントに厳格に従って推進し、一般的にデリバリーの遅延は許可されません。特別な理由（他の緊急要件の一時的な挿入など）がない限りです。

リソース投入の評価では、スケジュール設定に加え、テストは要件が開発セルフテストかテスト介入かを評価します。評価メカニズムのセットがあります。国際決済チームでは、開発とテストの比率は 9:1 です。つまり、テストがすべての要件を引き受けることは不可能です。資金リスクがなく、顧客に適切ではないと見積もられる一部のページ要件については、開発とセルフテストが要求されます。

一般的に、このリンクで最も重要な規範は次のとおりです。

1. 各当事者のリソースをまとめ、スケジュールを調整する
担当者：PM

2. 結合テスト時間、テスト時間、リリースと公開時間を決定し、PM と TPM がこれら 3 つのノードに厳格に従ってプロジェクトを推進する
担当者：PM および TPM

3. テストが引き取りテストが必要かどうかを確認する
担当者：QA

このリンクが適切かどうかを測定する指標は次のとおりです。

オンタイム率の向上
テスト合格率
リリースの定時性

3 設計段階

開発に入る前に不可欠なリンクは、技術方案の設計とレビューです。チームマスターとアーキテクトが技術方案レビューに参加することを要求し、技術方案设计テンプレートのセットがあります。このリンクが適切に行われれば、後続のリンクで半分の労力で 2 倍の成果を得ることができます。

一般的に、技術方案设计では開発が以下の側面を考慮することを要求します。

* 目標とコンテキスト
* 機能ポイントと開発者日
* システム間およびシステム内のインタラクションシーケンス図
* データベース設計
* インターフェース設計（フロントエンドに提供するインターフェースとビジネスのアップストリーム・ダウンストリームに提供するインターフェースを含む）
* タイミングタスク設計
* インターフェースパフォーマンス評価
* 互換性評価（旧機能との互換性）
* グレーリリース方案
* システムモニタリング
* チェック計画
* 資金セキュリティチェックリスト

上記の側面の設計が技術方案に明確に記載されていない場合、技術レビュー中に却下され、修正完了後に再度技術方案レビューが組織されます。合格後にのみ開発に入ります。この方法により、技術方案设计に問題がある実装をブロックし、テスト後にシステム設計問題が発見されるまで制御不能になる状況を回避できます。

4 テスト段階

疑いなく、詳細なテスト計画とテストケースレビューは、まずテスト担当者にこの要件の変更とリスクを理解させ、次に開発が機能ポイントと影響範囲を整理するのに役立ち、そして正式に 3 者（テスト、開発、プロダクト）のこのデリバリーの機能ポイントに関する合意に接続します。これら 3 つの目標を達成するために、テスト計画設計のテンプレートと規範を整理し、チーム内のテスト担当者に以下を要求しました。

1. 2 日以上のテストプロジェクトを引き受ける場合、テスト計画とテストケースのレビューリンクが必要です

2. テスト計画のレビューは、開発技術方案のレビュー完了後 5 日以内に完了する必要があります

一般的に、テストシナリオ設計ではテストが以下を考慮することを要求します。

* 開発に提供する必要があるスモークテストケース
* この要件の機能ポイントとそれに対応するカバレッジテストケース
* この要件の変更ポイントによって影響を受ける可能性のある旧機能とリグレッションテストケース
* アップストリーム・ダウンストリーム結合テスト方案とタイムポイント
* 構築とチェックが必要な資金損失ポイントとシナリオの分析
* インターフェースパフォーマンス分析
* グレーリリース方案分析
* メインユースケースライブラリの維持と更新

5 開発・結合テスト・セルフテスト段階

比較的大規模なプロジェクト、例えば xx プロジェクトでは、13 人の開発学生が研究開発に参加し、研究開発期間は 1 か月間続きました。そして品質は管理不能になる可能性があります。xx プロジェクトはこの罠を踏みました。重要なノードでプロジェクトチーム内の毎日の研究開発進捗を同期せず、問題が発生しました（プロジェクトの途中で他の要件に挿入された人がいて、モジュールが時間通りに結合テストできなかった、テストの品質が悪かった。開発は新人で、時間通りにテストを開始できなかったなど）がテストノードに集中して発生しました。この教訓に基づき、レビューを実施し、このリンクでの今後の規範を設定しました。すなわち：

1. プロジェクトの結合テストリンクに入った後、結合テスト日報（PM が要約）を発行し、毎朝の朝会で結合テスト進捗を同期する必要があります。

担当者：PM

2. 原則：結合テスト前に、ドメイン内のセルフテストを完了する必要があります。

担当者：開発

3. 行き詰まり問題に遭遇した場合、インターフェース依存当事者が依存当事者に解決を積極的に推進します。依存当事者が時間通りに解決せず進捗に影響を与える場合、リスクを同期する必要があります。

担当者：アップストリーム開発

4. 結合テスト段階では、アップストリームのモック結合テストまたはリアルリンク結合テストがメッセージを送信し、相手側の開発とメッセージが正しいかどうかを確認し、確認プロセスを追加します。リアルリンク結合テストとモック結合テストのインターフェースに差異があってはなりません。

担当者：ダウンストリーム開発

5. テスト担当者はスモークテストケースを開発セルフテストに提供します。開発はスモークテストケースのすべてのシナリオを経る必要があります。その後、テストを開始できます。

担当者：開発実行、テスト監督

6. リリース前に、単体テストの増分カバレッジ率が 60% に達する必要があり、単体テスト合格率は 100% です。

担当者：開発実行、テスト監督

7. グループ内のコードレビューは 2 日前に完了する必要があります。

担当者：開発

セルフテストリンクでは、テストは開発セルフテストのために事前にスモークテストケースを提供します。

開発者はスモークテストケースのすべてのシナリオを経る必要があります。その後、テストを開始できます。現在、スモークテストケースは Yuque ドキュメントの形式で開発に提供されています。これはオフラインの方法であり、振り返りや標準化された推進には不利です。したがって、ICBU 品質チームは、aone と組み合わせた Fields プラットフォーム上でオンラインユースケース管理を提供しています。今後は Fields プラットフォームに基づいたオンラインスモークテストケースとスモーク状態管理を提供する予定です。

このリンクが適切かどうかを測定する指標は次のとおりです。

オンタイム率の向上
テスト合格率
セルフテスト検出可能なバグ率

6 機能プレビュー段階

機能プレビューが提案される前に、開発者が提案した機能がページを開くことすらできない、あるいはインターフェースが調整できないといった低品質の問題が頻繁に発生します。低品質のテストはテストを非常に受動的にします。この種類の問題を回避するために、チームで機能プレビューを提案しました。つまり、テスト開始前に、PM はテストと開発を引き連れてテストバージョンの機能プレビューを 1 ラウンド実施し、メインプロセスが通過できることを保証します。テスト前に非常に低レベルの問題を迅速に解決し、テスト担当者がシステムの異常フローをテストする時間をより多く確保できるようにし、プロジェクトのデリバリー品質を保証します。

機能プレビューが失敗した場合、テスト提案は差し戻されます。問題解決後、開発は再度機能プレビューを組織し、リリース時間を延期する必要があります。Fields プラットフォーム上に差し戻しの理由とリリース遅延の理由を記録し、定期的にデータをレビューし、複数の遅延現象をレビューし、改善計画を議論します。

過去には、多くのチームがテストに合格しなかったので差し戻しを行い、問題解決後にテストを再提出することは言及されていましたが、リリース時間を延期する必要があることは言及されていませんでした。これにより、テストのプレッシャーが非常に高くなり、以前の開発の責任をテストの残業に押し付けて底線をカバーしていました。さらに深刻なのは、多くのチームがテストの底線のロジックを認識していることです。この種類の考え方を修正するために、私たちは多くの努力をしました。延期されたプロジェクトのために、特別にプロジェクトレビュー会議を組織し、規範を設定しました。

1. ドメイン間結合テストはリハーサル前に完了する必要があります。

2. 機能リハーサルはテストが主導し、開発は出席する必要があります。メインリンクが行き詰まった場合、開発は次のリハーサルの時間を提供し、リリース時間を延期し、プロジェクトチームに知らせる必要があります。
担当者：リハーサル・テスト、調査・開発

3. 機能リハーサルの問題がバグ問題の場合、開発者自身が解決する必要があります。データ問題の場合、テストが推進する必要があります。

4. 環境問題は対処する必要があります。
担当者：アーキテクト

7 テスト段階

現在、テスト期間が 3 日を超えるプロジェクトでは、テスト担当者は日報を送信し、テスト進捗とリスクをタイムリーに同期し、同時にバグ開発を毎日クローズすることを要求しています。日報テンプレート：

1. プロジェクトマイルストーン
2. 進捗と問題
3. リスク
4. 明日の計画

例えば、請求書プラットフォームの日報：

1. プロジェクトマイルストーン

11.9-12.28：設計・開発・結合テスト、完了
12.21：請求書設定背景機能プレビュー、完了
12.30：請求プロセス最適化機能のリハーサルが完了（6.5 営業日遅延）
12.22-1.6：オフラインテスト、完了
1.8-1.12：リリース前リグレッションテスト、進行中（リリースが 2 営業日延期、当初計画は 1.5 日）
1.13：リリース（5 営業日遅延、理由：開発者が他のプロジェクトに占有され、このプロジェクトに遅れて参加）

2. 進捗と問題

オフラインテスト進捗：100%
リリース前テスト進捗：

請求書設定背景テスト進捗：100%
請求プロセス最適化テスト進捗：90%

3. リスク

プロジェクト延長：プロジェクトは 2022.1.13 に 5 営業日延期されます。理由：①開発者が他のプロジェクトに占有され遅れて参加、②開発者が初期段階でワークロードを実際より少なく見積もった、③xxx プロジェクトが緊急に挿入され、フロントエンド担当者が 1 日を要する必要がある、④欠陥修正の完了時間が期待通りでなく、リリース前とテスト時間が 2 日延期。
バグ修正

4. 明日の計画

新請求機能の残りの欠陥のリグレッション検証
埋め込み請求プロセスのリターン
元の請求プロセスのリターン

プロジェクトチームのすべての学生（開発、プロダクト、ビジネス、テストを含む）と毎日連絡を取ることで、現在のテスト進捗と問題を明確に理解できます。同時に、プロジェクトにリスクがあり遅延が必要な場合、タイムリーにプロダクトとビジネスに通知でき、全員の期待を一致させやすくなります。現在、全員が日報に同意しており、今後もこの規範を遵守します。

8 リリース計画レビュー

多くの学生がこのような状況に遭遇したことがあると思います。プレリリース受け入れ中に問題がない多くのシナリオでも、オンラインに送信されると、これらのシナリオが機能しなくなります。調査後、理由が見つかります：インターフェースが十分に登録されていない、metaq トピックが設定されていない、スイッチまたは diamond スイッチが適切に設定されていない、dts 予定タスクが有効化されていないなどの設定問題です。この種類の問題が再び発生するのを防ぐために、以下を要求します。

大規模プロジェクトのリリース前に、リリース計画のレビューが必要であり、リリース前にプロジェクトチーム内で準備作業を同期し、その後リリースします。

担当者：プロジェクト PM

テンプレートは以下のとおりです。

1. リリース範囲
a. 適用範囲
b. リリース順序

2. リソース整理
a. HSF インターフェース
b. データベースリソース
c. メッセージリソース（metaq）
d. スケジュールリソース（dts）
e. 設定リソース（diamond、スイッチ、antx）

3. グレーリリース計画

4. リリースプロセス
a. プレリリースリリースプロセス
b. オンライン公開プロセス

5. ロールバック計画

6. 追跡計画
a. チェック
b. システムモニタリング
c. サービスモニタリング

7. リスク管理と注意事項
a. 過去データの互換性
b. 冪等ロジックの確認
c. グレーリリース方案
d. 緊急スイッチ

このリンクが適切かどうかを測定する指標は次のとおりです。

オンラインバグ率

9 リリースとリリース後

公開はグループの安全レッドラインに従います。

最低 1 時間のベータテスト、ロールバック可能
ビジネス面ではグレーリリース 가능하며、グレーリリースで問題がなければ全ユーザーにリリースします。
機能リリース後のシステム追跡については、主にシステムモニタリング、サービスモニタリング、チェックによってカバーされます。例外が発生した場合、開発とテストが原因に注意を払い、できるだけ早く問題を解決します。

機能リリース後のユーザー体験追跡については、主にグレーリリース顧客のフィードバックと完全リリース後の作業指示の分析を通じて行われます。

最近どのビジネスモジュールに作業指示が多いかを確認でき、ターゲットを絞った最適化を実施できます。現在、この部分は主に開発が追跡・対応しています。

10 プロジェクトレビュー

大規模プロジェクトがリリースされた後、プロジェクトプロセスに問題があった場合、通常プロジェクトレビュー会議を組織してプロジェクトの問題をレビューし、その後のメカニズムと規範を議論することで、後続のプロジェクトが同じ罠を踏むのを回避します。

このようにして、私たちのチームの研究開発プロセスの規範を継続的に改善し、現在の問題をタイムリーに解決できます。

11 Fields 公開プラットフォームとの組み合わせ

Fields プラットフォームは、リリース管理と品質管理のプラットフォームとして位置づけられており、セルフテスト開発へのより多くの投入と支援でもあります。

セルフテスト要件と Fields プラットフォームの実践

現在、Fields プラットフォームは aone カードポイントと接続されています。セルフテスト要件については、開発者はリリース前に開発セルフテストを完了し、プラットフォーム上でセルフテストフィードバックを提供してからオンラインにリリースする必要があります。

セルフテストプロセスをオンライン化することで、セルフテスト開発により多くの支援を提供することを目指しています。

メインケースライブラリを構築し、各シナリオに詳細な操作步骤を提供し、ワンクリックでインターフェース自動化をトリガー
セルフテスト要件については、テストが Fields プラットフォーム上でリターンが必要な骨格ユースケースを囲み、開発と実行に提供します
多くの開発者が業務の一部しか理解していない、またはバックエンドビジネスロジックの一部しか知らないことがわかりました。時には自分自身の変更の影響を評価するのが難しい場合や、特定のビジネスにリターンしたいが操作方法がわからない場合があります。これらの問題を解決するために、現在、国際決済ビジネスの骨格ユースケースライブラリを構築しており、開発者が関連ビジネスに慣れていない場合でも、私たちのユースケースにリターンして「愚か者のような操作」を行うことで、セルフテスト開発の課題を解決できます。

テスト引き取り要件と Fields プラットフォームの実践

一般的に、テスト引き取りクラスの要件は比較的大きく、開発サイクルが比較的長く、参加者が多くなります。現在、このような要件に対して Fields プラットフォームが提供する機能は次のとおりです。

スモークプロセスがオンライン化され、テストはプラットフォーム上でスモークテストケースを追加でき、開発はスモーク状態をマークします。これにより、スモーク合格率を統計できます。
テストプロセスがオンライン化され、プラットフォーム上でリターンテストが可能です。これにより、テスト合格率を統計でき、現在の開発とテストの品質を測定し、ターゲットを絞ったレビューを実施できます。
しかし、テストリンクのテストレポート、リスク同期、リリース計画などの後続プロセスについては、プラットフォームが提供できる機能はまだ議論中です。今後の展開に期待しています。

4 まとめ

これまで、国際決済チームの品質標準化に関する合意事項と、多くの過去のプロジェクトをレビューしてまとめられた規範と基準について説明しました。これらの規範と基準が確定した後でも、テストと開発の学生が後続のプロジェクトで操作、実装、改善、継続的な最適化を行う必要があります。研究開発プロセス全体をオンラインで操作できるかどうかについても考えています。現在、良いソリューションはなく、まだ人が分析と推進を行うことに依存しています。