Download to read offline
アプリ開発へのOdc分析導入の取り組み
- 1. アプリ開発へのODC分析導入の取組み 柏倉直樹 システム本部 品質統括部 品質管理部QC第２グループ 株式会社ディー・エヌ・エー @ DeNA Co.,Ltd.
- 2. 2 自己紹介 柏倉 直樹 カーナビの第三者検証、企業向けルーターのQAを経験し、2018年2 月DeNAに入社。 担当サービスはtoCエンターテイメントサービス、 ECサービス。現在はQAリーダーとして各種管理、QA技術向上、 サービス品質向上に向けた取り組みに従事しています。 グループ活動 開発初期からの品質向上・CX推進 社外活動 ソフトウェア品質シンポジウム(SQiP)委員 2020〜 DeNA 品質統括部 品質管理部 QC2G @Gurarinq
- 3.
- 4.
- 5. 5 背景 ● サービス規模の拡大にともない市場障害が増加傾向にあった ● チームの弱点傾向を定量的に可視化し、優先度をデータを元に判断してシ ューティングしていきたい！という開発チーム要請 ●これまでのバグ分析では弱点傾向を可視化はできない ○ ex)「仕様書不備が多い」までは分析できても、どの工程で仕様書不備が埋め込まれているかまでは可視化できない 1 「やり方の質」が良くない工程を重点的にシューティングしていく！ 開発工程の「やり方の質」を可視化する手法であるODC分析を採用
- 6. 6 ODC概要（１） ● Orthogonal DefectClassification = 直交欠陥分類 ● 独立した4つの属性ラベルを不具合票に付与し傾向分析する手法 ○ 直交 = 互いに相容れない・依存しない （ソフトウェア不具合改善手法 ODC分析 工程の「質」を可視化する 杉崎眞弘・佐々木方規 日科技連出版社 2020/8/29 P.12） 1 統計的分析 原因分析(RCA) ODC 分析手法 ● 履歴データモデルとの比較 ● 成長曲線モデル ● 限定、特定不具合の調査 是正処置に直結しない 不具合固有の原因追求 時間とコストがかかる 個々の不具合の意味論を定量的 に捉え、プロセスの進歩と品質 成熟への橋渡し
- 7. 7 ODC概要（２） ・下表に示す４つの属性ごとにラベルを付与する ・タイプ属性はさらに「誤り」と「欠如」の2パターンに分類する（タイプ属性限定子） 1 属性 属性の概要 例 タイプ属性不具合の原因 ・条件分岐を見落とした ・処理順序を誤った トリガー属性 不具合が表面化あるいは発見された行 為または条件 ・境界値テストで発見 ・機能の実行順によって発生 ソース属性 不具合が発見・修正された箇所のソー スコードの開発履歴に関わる観点のラ ベル ・新規に追加したソースコード ・既存ライブラリ インパクト属性 お客様 (ユーザー) にどのような影響を 与えている ・ユーザビリティ ・性能 属性ごとのラベル一覧を参考までに次ページに掲載
- 8. 8 タイプ属性 トリガー属性 (静的テスト) トリガー属性 (単体・結合テスト) トリガー属性 (システムテスト) ソース属性 インパクト属性 値の設定設計の合致 単純パスのカバレージ 負荷テスト/ストレステスト 再利用 使用性 条件分岐 レアケース 組合せパスのカバレージ 正常系テスト 書き直し 性能 アルゴリズム 詳細の理解 テスト項目のカバレージ 復旧テスト / 例外テスト 修正 信頼性 タイミング・順序 前バージョンとの互換性 テスト実行順 起動時 / 再起動時テスト 外部作成 導入容易性 インターフェース 水平互換性 相互間でのテスト ハードウェア組合せテスト 旧機能 as is 移行容易性 機能性 言語依存性 テストの多様性 ソフトウェア組合せテスト 新規 保守性 ビルド・パッケージ・結合 ドキュメント記述 縁バグ Temporally 記述性 開発関連ドキュメント 可用性 保全性・セキュリティ 標準化 機能性 表 属性ごとのラベル一覧 実際には下表のラベルだけでなく現場で運用されてきたラベルと組み合わせて分析されることが多い 今回の取り組みでも、従来運用されてきた分析ラベルと併用した（Appendix1） 参考 “ソフトウェア不具合改善手法 ODC分析 工程の「質」を可視化する 杉崎眞弘・佐々木方規 日科技連出版社 2020/8/29”
- 9. 9 表 開発プロセスとタイプ属性の関係 基本設計 詳細設計実装 単体テスト 機能テスト 結合テスト システム テスト 値の設定 X X 条件分岐 X X X アルゴリズム X X X タイミング・順序 X X インターフェース X X X X X 機能性 X X タイプ属性にはそれぞれに検出されて然るべき工程がある
- 10. 10 図 開発プロセスとタイプ属性限定子の関係 タイプ属性限定子＝「誤り」or「欠如」のどちらが原因で不具合を埋め込んだかを示すラベル 要件定義 基本設計 詳細設計 実装 機能、クラスの欠如 I/F、メッセージの欠如 同期、直列化の欠如 関連付けの欠如 機能、クラスの誤り I/F、メッセージの誤り 同期、直列化の誤り 関連付けの誤り アルゴリズムの欠如 検証の欠如 アルゴリズムの誤り 代入、初期化の欠如 検証の誤り 代入、初期化の誤り 誤り 欠如要求の具体化を検討してい る段階では要求の抽出漏れ や考慮不足のため「欠如」 が多い傾向 工程が進むにつれ設計の詳 細化やレビューが進むと当 初設計したことの誤りに気 づくことが多くなり「誤 り」が増える 実装段階の「欠如」は単純 に実装漏れ、「誤り」はタ イポ・仕様誤解などが考え られる 参考 “ソフトウェア不具合改善手法 ODC分析 工程の「質」を可視化する 杉崎眞弘・佐々木方規 日科技連出版社 2020/8/29”
- 11.
- 12.
- 13. 13 取り組み３ステップ 1. ODC分析の学習と導入準備 2. 機能・システムテストでの検出不具合を対象にラベル付け 3.分析 次ページ以降でそれぞれを詳しく紹介します 2
- 14. 14 1. ODC分析の学習と導入準備 1. 市販の書籍(※1）とネットで見つかる研究事例から学習（3名×1ヶ月） 2.導入対象プロジェクトのQAメンバーを交えて議論（5名×1h×3回） ○ ラベルどうする？（現場で伝わりやすいネーミング、分類基準） ○ 従来の分析用ラベルと競合しないか ○ 用意したラベルで目的（弱点可視化）が果たせるか ■ どのラベルとどのラベルを組み合わせるとどんな示唆が得られそうか ○ 適用範囲（最初からレビューやUTへの適用は難しい） 3. ラベル分類ルール表を作成し開発チームへ周知（1名×15h） 2 ※１：ソフトウェア不具合改善手法 ODC分析 工程の「質」を可視化する 杉崎眞弘・佐々木方規 日科技連出版社 2020/8/29
- 15.
- 16. 16 3.分析 ● 集まった不具合データを実際に分析してみる ○ 準備の際に検討した分析方法の他にもいろいろとラベルを組み合わせ てグラフ化してみる（１名×15h） ○グラフをレビューし、こんなグラフがあると良い！をフィードバック するMTG（５名×1h×3回） 2 どんな示唆が得られたかを次章で紹介
- 17.
- 18. 18 分析から得られた示唆（１） 3 【sampleグラフ：修正ソース種別の分布】 既存コード・仕様の割合が多いため、 ・そもそもの仕様/コード品質が悪い ・過去のテストが不十分 ・既存仕様への影響調査が不十分 などの可能性がある 本取り組みでは書籍(※1)に定義してある”ソース属性”を、より現場で理解しやすいように”修正ソース種別”とい うラベルにアレンジして導入した 【修正ソース種別】 どのソースや仕様を修正した際に不具合を混入してしまったか 新規コード・仕様 今回新たに追加したコードや仕様に混入 改修コード・仕様 元々存在したコードや仕様に手を入れた際に混入 修正コード・仕様不具合対策する際に混入 既存コード・仕様 元々存在したコードや仕様に不具合が潜在していた ※1“ソフトウェア不具合改善手法 ODC分析 工程の「質」を可視化する 杉崎眞弘・佐々木方規 日科技連出版社 2020/8/29”
- 19.
- 20.
- 21. 21 今後の展望・課題 ● 展望 ○ 継続して分析を続ける中で、どのラベルを組み合わせるとどんな傾向 が見えるのか？のバリエーションがもっと拡充される見込み ●課題 ○ 分析の効率化（分析手順の整備・自動化など） ■ BQにデータを集めてDataStudioでグラフ化しているので、BTS以外のデ ータも分析に活用できるようになる ○ プロセスシグネチャを定義して不具合分布のズレを見つけること ■ 機能・システムテスト以外の全工程のデータが必要 ● 開発内レビュー指摘、テストチームレビュー指摘などが一元管理さ れていない 4 一緒に取り組む仲間を募集しています！！
- 22.
- 23.
- 24.
- 25.
- 26.
- 27.
- 28.
- 29.
- 30.
- 31.
- 32.
- 33.